SBOM pour Docker et les images de conteneur pour le CRA
Sur cette page
Le Cyber Resilience Act demande à chaque fabricant de tenir une nomenclature des logiciels « dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits » (annexe I, partie II, point 1). Quand vous livrez votre logiciel sous forme d’image de conteneur, c’est l’image que le client fait tourner. Tout ce qu’elle contient fait partie de ce que vous mettez sur le marché : votre code et ses bibliothèques, mais aussi les paquets système de l’image de base, l’environnement d’exécution du langage et tout binaire ajouté au passage.
Pour le règlement lui-même, voir Le SBOM pour le Cyber Resilience Act.
Quand l’image fait partie du produit
- Vous livrez l’image à vos clients, qui la font tourner sur leurs propres serveurs ou clusters (logiciel auto-hébergé, édition sur site, appliance, chart Helm qui récupère vos images). L’image est le produit, ou une partie du produit, et son SBOM doit tout couvrir.
- Vous faites tourner l’image vous-même pour rendre un service. Un SaaS pur échappe en général au CRA, sauf s’il assure le traitement à distance des données d’un produit (voir Le CRA et le SaaS). Le SBOM de l’image reste une bonne pratique, mais ce n’est pas un document du CRA.
- Un appareil fait tourner des conteneurs. Sur une passerelle ou un PC industriel, les images font partie du micrologiciel et ont leur place dans le SBOM de l’appareil.
Deux SBOM, et pourquoi il vous faut les deux
Un SBOM des sources, établi à partir de vos fichiers de verrouillage (voir les guides pour npm, Python, Java, Rust, Go et .NET), connaît vos dépendances directes et le graphe des dépendances. Il ignore l’image de base.
Un SBOM de l’image, établi en analysant l’image terminée, voit ce qui est réellement installé : paquets Debian, Alpine ou Red Hat, environnement d’exécution Python ou Java, paquets des langages d’après leurs métadonnées installées, binaires Go d’après leurs informations de build. Il ignore lesquels votre code a demandés, et il peut manquer ce qui ne laisse pas de métadonnées, comme une bibliothèque C compilée à partir des sources ou un binaire téléchargé avec curl dans le Dockerfile.
Gardez les deux pour chaque version. Le SBOM de l’image répond à « cet OpenSSL vulnérable est-il dans ce que nous livrons ? » ; le SBOM des sources répond à « est-ce le nôtre, et pourquoi est-il là ? ».
Produire le SBOM de l’image
Syft, d’Anchore, analyse une image depuis un registre, le démon Docker local ou une archive :
syft registry.example.com/acme/gateway:2.4.0 -o cyclonedx-json=sbom.cdx.json
Trivy, d’Aqua Security, fait de même :
trivy image --format cyclonedx --output sbom.cdx.json registry.example.com/acme/gateway:2.4.0
Ou laissez BuildKit écrire le SBOM pendant le build et l’attacher à l’image comme attestation (en SPDX, produit par un analyseur fondé sur Syft) :
docker buildx build --sbom=true -t registry.example.com/acme/gateway:2.4.0 --push .
Les attestations demandent un constructeur (builder) qui les prend en charge (le pilote docker-container, ou le stockage d’images containerd de Docker). Elles voyagent avec l’image dans le registre, et docker buildx imagetools inspect les relit. Pour obtenir un simple fichier SPDX, celui qu’attendent les autres outils :
docker buildx imagetools inspect registry.example.com/acme/gateway:2.4.0 --format '{{ json .SBOM.SPDX }}' > sbom.spdx.json
Quel que soit l’outil, décrivez l’image exacte que vous publiez, par son empreinte (digest), et non par une étiquette qui désignera plus tard une autre image.
Les images de base et ce qu’elles apportent
- Chaque paquet de l’image de base est à votre charge. Une base Debian ajoute une centaine de paquets, dont la plupart ne servent jamais à votre application. Chacun peut porter une vulnérabilité, et beaucoup de scanners l’imputeront à votre produit.
- Plus petit, plus simple. Les images distroless, Chainguard, Alpine ou
scratchpour les binaires statiques contiennent bien moins de composants, donc moins de vulnérabilités à évaluer et moins de questions des clients. - Reconstruisez régulièrement. Une étiquette d’image de base comme
debian:12-slimreçoit des correctifs ; votre image, non, tant que vous ne la reconstruisez pas. Reconstruisez selon un calendrier, et quand une vulnérabilité exploitée touche l’image de base, pas seulement quand votre code change. - Fixez l’image de base par son empreinte dans le Dockerfile, pour que chaque SBOM corresponde à ce qui a été construit.
- Les builds en plusieurs étapes aident. Compilateurs et outils de build restent dans l’étape de build et n’arrivent ni dans l’image finale ni dans son SBOM.
Du SBOM aux vulnérabilités
Grype lit les SBOM de Syft, et trivy sbom sbom.cdx.json compare un SBOM conservé aux avis du jour sans retélécharger l’image. Attendez-vous à beaucoup de résultats sur des paquets système que votre application n’appelle jamais. Regardez d’abord les vulnérabilités exploitées, qui peuvent déclencher le délai de signalement, et consignez dans une déclaration VEX pourquoi les autres ne touchent pas le produit. Les distributions publient aussi leurs propres évaluations, comme les décisions « non concerné » ou « ne sera pas corrigé » de Debian et de Red Hat, qu’il vaut la peine de consulter avant d’écrire les vôtres.
Ce que fait Provetry
Envoyez le SBOM de l’image produit par Syft, Trivy ou BuildKit (CycloneDX ou SPDX en JSON, SPDX 3 compris ; pour BuildKit, le fichier extrait comme ci-dessus), ou laissez l’étape de CI de Provetry lire l’image elle-même (son entrée image prend un nom d’image ou une archive docker save ; provetry sbom gateway.tar fait de même en local) : paquets Debian, Ubuntu et Alpine avec leur version de distribution, paquets Wolfi et Chainguard, paquets opkg, et paquets Python et Node.js installés dans l’image. Les images à base de RPM ne sont pas encore lues : le SBOM le signale. Syft et Trivy listent leurs paquets RPM (image-tool: syft fait utiliser Syft à l’étape de CI), mais Provetry ne recherche pas encore les paquets RPM, ni les paquets opkg, ni ceux d’une version qu’aucune base publique d’avis ne couvre (Debian testing, Alpine edge) ; une distribution dérivée comme Raspberry Pi OS n’est recherchée que de façon approchée, comme la version qu’elle suit. La version indique quels composants ne sont pas surveillés. Une version porte un seul SBOM : quand il décrit l’image, il couvre aussi les paquets des langages qui y sont installés, mais l’analyse d’atteignabilité n’est pas faite ; gardez donc le SBOM de vos fichiers de verrouillage avec les artefacts de votre build. Provetry garde le SBOM de chaque version, surveille chaque jour avec les offres payantes et chaque semaine avec l’offre gratuite chaque composant qu’il sait rechercher, paquets système compris, pour les vulnérabilités nouvelles et exploitées, et, avec les offres Pro et Consultant, une fois la fin de votre période d’assistance indiquée dans la fiche du produit, signale les composants dont le support s’arrête avant le vôtre, pour ceux que connaît endoflife.date (surtout des environnements d’exécution, des frameworks et des bases de données). Son analyse d’atteignabilité lit le code source : elle ne couvre donc pas les autres binaires d’une image. Pour ceux-là, votre propre évaluation est enregistrée sous forme de déclaration VEX.