Un SBOM (Software Bill of Materials) est la « liste d’ingrédients » de votre logiciel : l’inventaire complet des paquets, bibliothèques, versions et dépendances que contient une image. Comme une étiquette nutritionnelle, il vous dit exactement ce qu’il y a dedans.
Sa valeur saute aux yeux le jour d’une vulnérabilité critique : au lieu de fouiller des dizaines d’images à la main, vous interrogez le SBOM et savez en quelques secondes quelles images contiennent le composant touché, et dans quelle version.
Pourquoi il compte pour vos images
- Réponse rapide aux CVE : vous identifiez à l’instant si une nouvelle vulnérabilité vous concerne.
- Sécurité de la chaîne d’approvisionnement : vous savez d’où vient chaque composant.
- Conformité : de plus en plus de référentiels et de clients le demandent comme preuve.
- Transparence : si vous publiez des images, un SBOM inspire confiance à ceux qui les utilisent.
Formats standards
| Format | Origine | Notes |
|---|---|---|
| SPDX | Linux Foundation / ISO | Standard ISO, très utilisé en conformité |
| CycloneDX | OWASP | Orienté sécurité, riche pour l’analyse de vulnérabilités |
Les deux formats SBOM dominants ; beaucoup d’outils exportent vers les deux.
Comment générer le SBOM d’une image, étape par étape
- Choisissez l’outil : Syft, d’Anchore, est un standard de fait pour générer des SBOM d’images et de systèmes de fichiers ; il existe aussi des options natives du cloud.
- Générez-le dans le pipeline : pendant le build de l’AMI, analysez le système de fichiers et produisez le SBOM, par exemple en CycloneDX et SPDX.
- Analysez les vulnérabilités : passez le SBOM dans Grype ou Trivy pour le croiser avec les bases de CVE.
- Signez et archivez : signez le SBOM —avec cosign par exemple— et conservez-le comme artefact associé à la version de l’image.
- Consultez-le au besoin : face à une nouvelle CVE, examinez vos SBOM archivés pour connaître la portée.
Le contexte réglementaire de 2026
Le SBOM gagne du poids depuis des années comme bonne pratique de sécurité de la chaîne d’approvisionnement. Le paysage réglementaire est cependant nuancé : aux États-Unis, l’administration a révisé en 2026 les mandats hérités d’attestation logicielle vers une approche davantage fondée sur le risque, tandis que dans l’Union européenne des textes comme le Cyber Resilience Act poussent la transparence logicielle et l’inventaire des composants. Conclusion pratique : indépendamment des allers-retours réglementaires, disposer de SBOM est un avantage défensif et commercial qu’il vaut mieux adopter.
Bonnes pratiques
- Générez le SBOM automatiquement à chaque build, pas à la main.
- Conservez-le versionné aux côtés de l’image correspondante.
- Combinez-le à une analyse de vulnérabilités pour qu’il soit actionnable.
- Signez-le pour garantir son intégrité et sa provenance.
Questions fréquentes
Un SBOM, est-ce la même chose qu’une analyse de vulnérabilités ?
Non. Le SBOM est l’inventaire des composants ; l’analyse croise cet inventaire avec les bases de CVE pour détecter les vulnérabilités. Ils se complètent : d’abord vous savez ce que vous avez, ensuite s’il est vulnérable.
SPDX ou CycloneDX ?
SPDX est un standard ISO très utilisé en conformité ; CycloneDX est plus orienté sécurité. Beaucoup d’outils exportent vers les deux, vous n’êtes donc pas obligé de choisir.
Ai-je besoin d’un SBOM si je ne fais que consommer des images tierces ?
Oui. Demander ou générer le SBOM des images que vous utilisez vous permet d’évaluer leur risque et de réagir vite face aux vulnérabilités, même si vous ne les avez pas construites.
Chez imaxe.cloud, nous misons sur la traçabilité : inventorier et documenter le logiciel de nos images fait partie de bien les construire.
