SBOM : comprendre le Software Bill of Materials

« Est-ce qu'on utilise ce composant ? », Combien de fois ai-je entendu cette question en urgence, après l'annonce d'une CVE critique ? À chaque incident supply chain, c'est la même course : fouiller les package.json, les requirements.txt, les images Docker… sans jamais être certain d'avoir tout couvert.

Le SBOM (Software Bill of Materials) répond à ce problème. C'est un inventaire lisible par une machine de ce qui compose un logiciel : bibliothèques, paquets système, dépendances transitives, versions, licences. En clair : si on ne sait pas ce qu'on exécute, on ne peut ni corriger vite, ni prouver ce qu'on livre.

Le mot « exhaustif » est un piège, et cette page le mesure plus bas : la couverture d'un SBOM dépend de la source scannée, de l'outil et du moment de la génération. Le document de référence de 2026 en a d'ailleurs tiré la conséquence en remplaçant l'élément Depth par Coverage.

Cet inventaire est une exigence centrale du référentiel Socle DevSecOps, qui en fait un prérequis traçable de la sécurité de la chaîne logicielle, du code au cloud.

Ce que vous allez apprendre

Distinguer les deux formats normalisés, et savoir lequel votre outil écrit réellement, qui n'est pas toujours la dernière version publiée.
Générer un SBOM avec Syft depuis l'artefact que vous livrez, épinglé par empreinte.
Mesurer la couverture de votre SBOM face aux dix-sept champs exigés en 2026, plutôt que de la supposer.
Exploiter l'inventaire pour répondre à une CVE avec Grype, Trivy ou Dependency-Track, et réduire le bruit avec un VEX.
Distribuer le SBOM en attestation signée attachée à l'image.
Prouver les exigences SOCLE-PKG-GEN-1 et SOCLE-PKG-SBM-1 à -3 du référentiel Socle DevSecOps, dont la première impose un SBOM par artefact et la deuxième qu'il porte licences et empreintes.

Cycle de vie du SBOM : Générer, Distribuer, Scanner, Réagir — Les 4 étapes du cycle de vie d'un SBOM

C’est quoi un SBOM, exactement ?

Un SBOM, c’est un document qui décrit :

Les composants (nom, version, fournisseur/éditeur quand possible)
Des identifiants stables (ex. purl, parfois CPE)
Les relations (dépendances directes/transitives)
Des métadonnées utiles (licences, hashes, emplacements, type de composant…)

L’objectif n’est pas « faire un fichier pour la conformité ». L’objectif est d’avoir un SBOM actionnable : chercher, corréler, prouver, automatiser.

Ce que le SBOM n’est pas

Ce n’est pas un scan de vulnérabilités.
Ce n’est pas une preuve d’intégrité (ça, c’est la signature/attestation).
Ce n’est pas une garantie d’exploitabilité (ça, c’est plutôt le rôle d’un VEX).
Ce n’est pas un inventaire exhaustif. Un SBOM est un inventaire lisible par une machine, dont la couverture dépend de la source scannée, de l'outil et du moment de la génération. La suite de cette page le mesure.

Que demandent les « Minimum Elements » de 2026 ?

Le document de référence a changé de nom, de version et d'auteurs le 29 juillet 2026. Ce qu'on citait sous « NTIA 2021 » est désormais les 2026 Minimum Elements for a Software Bill of Materials, en version 2.1, publié par la CISA avec la NSA, le FBI et quinze partenaires internationaux, dont l'ANSSI pour la France.

Son historique tient en trois lignes, et il évite de citer un brouillon pour une norme :

Version	Date	Ce que c'est
1.0	12 juillet 2021	les minimum elements de la NTIA
2.0	22 août 2025	un brouillon soumis à commentaires
2.1	29 juillet 2026	la version finale, celle qu'on cite

Elle définit dix-sept champs de données, contre sept en 2021 :

Champ	Ce qu'il porte
Component Name, Component Version	le composant et sa version
Component Producer	qui le produit
Component License	nouveau : sous quelle licence
Component Identifiers	purl, CPE, clés de recherche
Component Hash Algorithm, Component Hash Value	nouveaux : l'empreinte, et l'algorithme qui l'a produite
Component Dependency Relationship	qui dépend de qui
SBOM Author, SBOM Author Signature	qui a produit le SBOM, et sa signature
SBOM Data Format Name, SBOM Data Format Version	le format et sa version
SBOM Generation Context	nouveau : à quelle phase du cycle de vie
SBOM Timestamp, SBOM Version	quand, et quelle révision
SBOM Tool Name, SBOM Tool Version	avec quoi

Un changement compte plus que les autres, et il est structurant : l'élément Depth de 2021 est remplacé par Coverage. La justification officielle vaut d'être lue, parce qu'elle décrit exactement le piège de la section suivante : « The Depth element was previously defined as capturing software component information for top-level dependencies only. This definition reflected the capabilities of SBOM tooling at the time rather than the depth of information needed to make informed security decisions. »

Combien de ces dix-sept champs votre SBOM porte-t-il vraiment ?

Un SBOM généré par la commande la plus courante en couvre neuf sur dix-sept. Mesuré le 20 septembre 2026 sur Debian 13 avec Syft 1.52.0, en scannant un simple requirements.txt :

Présents	Absents
Name, Version, Identifiers	Producer, License
Data Format Name et Version	Hash Algorithm, Hash Value
Timestamp, Tool Name, Tool Version, SBOM Version	Dependency Relationship, Author, Author Signature

Ce n'est pas un défaut de l'outil : un fichier de déclarations ne porte ni licence, ni empreinte. L'outil ne peut pas inventer ce que la source ne contient pas, et c'est précisément ce que Coverage demande de déclarer.

La couverture dépend de ce que vous scannez, pas de la commande

La démonstration tient en trois lignes, même machine, même commande syft, trois sources différentes :

Source scannée	Composants	Licence	Empreinte	Producteur
un `requirements.txt`	4	0 %	25 %	0 %
un environnement réellement installé	22	27 %	72 %	27 %
la base de paquets du système	1 296	0 %	73 %	26 %

De 4 à 1 296 composants selon ce qu'on pointe. Un SBOM produit depuis un fichier de déclarations décrit ce que le projet demande ; un SBOM produit depuis un artefact installé décrit ce qu'il contient. Les deux sont légitimes, ils ne répondent simplement pas à la même question, et c'est pour cela que SBOM Generation Context est devenu un champ obligatoire.

La conséquence pratique est nette : générez le SBOM depuis l'artefact que vous livrez, image ou paquet, et pas depuis le dépôt de code. La comparaison des deux est d'ailleurs un contrôle utile en soi, un écart important signalant une dépendance qui entre par la construction sans figurer dans le code.

Pourquoi le SBOM devient incontournable ?

Le problème : réagir à l'aveugle

Quand une CVE critique tombe (Log4Shell, XZ Utils, Polyfill.io…), la première question est toujours la même : « Est-ce qu'on est impactés ? ». Sans inventaire centralisé, on doit :

fouiller manuellement chaque package.json, requirements.txt, go.mod…
scanner toutes mes images Docker une par une
interroger chaque équipe pour savoir ce qu'elle utilise
espérer n'avoir rien oublié

Résultat : des heures (voire des jours) perdues à chercher, pendant que la vulnérabilité reste exploitable.

Les attaques supply chain : le contexte

Une attaque supply chain cible la chaîne d'approvisionnement logicielle : dépendances, outils de build, registres de paquets, pipelines CI/CD. L'attaquant comprommet un composant en amont pour toucher tous les projets qui en dépendent.

Pour comprendre les vecteurs d'attaque et les exemples récents (XZ Utils, Polyfill.io, tj-actions…), consulte mon guide complet sur la sécurité de la supply chain. Pour évaluer la posture sécurité d'un projet avant de l'adopter, utilise OpenSSF Scorecard.

Le point commun de ces incidents : sans inventaire fiable, on passe son temps à répondre à « est-ce qu'on est touchés ? » au lieu de corriger.

La réponse : un inventaire interrogeable

Avec un SBOM par artefact, on peut en quelques secondes :

# Rechercher un composant vulnérable dans tous mes SBOM
grep -l "xz-utils" *.sbom.json

Le SBOM transforme donc une question floue (« on utilise quoi ? ») en une requête précise sur des données structurées.

Formats standardisés : SPDX ou CycloneDX ?

Deux formats dominent l'écosystème SBOM. Chacun a son histoire, ses forces et son écosystème d'outils. Comprendre leurs différences permet de choisir le bon format selon le contexte.

CycloneDX (OWASP)

CycloneDX est un standard développé par l'OWASP (Open Web Application Security Project), conçu dès le départ pour la sécurité applicative et la supply chain logicielle.

Versions et évolution :

CycloneDX 1.4 (2022) : ajout du support VEX (Vulnerability Exploitability eXchange) pour qualifier l'exploitabilité des vulnérabilités
CycloneDX 1.5 (2023) : support des attestations de formulation (build environment, sources, configurations)
CycloneDX 1.6 (2024) : amélioration du support cryptographique (CBOM) et des services (SaaSBOM)
CycloneDX 1.7 (21 octobre 2025) : version courante, publiée comme norme ECMA-424 le 10 décembre 2025

Le passage par l'ECMA compte plus que le numéro : CycloneDX cesse d'être le format d'un projet OWASP pour devenir une norme publiée, ce qui pèse dans un appel d'offres ou une exigence contractuelle. C'est le terrain sur lequel SPDX avait l'avantage depuis son ISO/IEC 5962:2021.

Points forts :

Orienté sécurité : intégration native de VEX, hashes, signatures
Écosystème DevSecOps : support natif dans Trivy, Grype, Dependency Track, Snyk, GitHub
Léger et pragmatique : schéma JSON/XML simple, facile à parser
Évolution rapide : nouvelles fonctionnalités tous les 6-12 mois

Formats de sortie : JSON, XML, Protocol Buffers

# Syft écrit du CycloneDX 1.7 par défaut depuis la version 1.52.0
syft scan registry:order-service:2.1.0@sha256:<digest> \
  -o cyclonedx-json > sbom.cdx.json

# Forcer une version plus ancienne, si l'outil qui consomme le SBOM l'exige
syft scan registry:order-service:2.1.0@sha256:<digest> \
  -o cyclonedx-json@1.5 > sbom.cdx.json

Le suffixe @version reste accepté. Mesuré le 20 septembre 2026 avec Syft 1.52.0 : 1.4, 1.5, 1.6 et 1.7 passent, 2.0 est refusé, ce qui est cohérent avec une 2.0 qui n'est pas publiée comme stable.

SPDX (Linux Foundation / ISO)

SPDX (Software Package Data Exchange) est un standard de la Linux Foundation, devenu norme ISO/IEC 5962:2021. Il est historiquement très fort sur la conformité des licences et la traçabilité juridique.

Versions et évolution :

SPDX 2.2 (2020) : version largement adoptée, base de la norme ISO
SPDX 2.3 (2022) : ajout d'annotations, relations enrichies, meilleur support des conteneurs
SPDX 3.0 (2024) : refonte majeure avec profils modulaires (Core, Software, Security, Licensing, Build, AI/ML), support natif de VEX et des attestations

Points forts :

Standard ISO : reconnu internationalement, requis par certains gouvernements et industries réglementées
Licences exhaustives : liste SPDX des identifiants de licences (MIT, Apache-2.0, GPL-3.0…) utilisée universellement
Provenance détaillée : traçabilité complète de l'origine des composants
SPDX 3.0 : rattrape CycloneDX sur la sécurité avec les profils Security et Build

Formats de sortie : JSON, RDF/XML, Tag-Value (texte plat), YAML

# Syft écrit du SPDX 2.3 par défaut, PAS du 3.0
syft scan registry:order-service:2.1.0@sha256:<digest> \
  -o spdx-json > sbom.spdx.json

La version courante de la spécification n'est pas celle que l'outil produit. Mesuré le 20 septembre 2026 avec Syft 1.52.0 : spdx-json sans suffixe écrit du SPDX-2.3, et il faut demander spdx-json@3.0 explicitement pour obtenir la 3.0. C'est l'inverse de CycloneDX, où le défaut suit la dernière version. Vérifiez donc ce que vous produisez, plutôt que ce que vous croyez produire :

jq -r '.spdxVersion // "format SPDX 3, la clé spdxVersion n existe plus"' sbom.spdx.json

Tableau comparatif

Comparaison CycloneDX vs SPDX — CycloneDX (sécurité) vs SPDX (conformité ISO) : deux standards complémentaires

Critère	CycloneDX	SPDX
Organisme	OWASP	Linux Foundation
Version actuelle de la spécification	1.7 (octobre 2025)	3.0
Version écrite par défaut par Syft 1.52.0	1.7	2.3
Focus principal	Sécurité, supply chain	Licences, conformité
Support VEX	Natif depuis 1.4	Natif depuis 3.0
Norme publiée	ECMA-424 (décembre 2025)	ISO/IEC 5962:2021
Adoption DevSecOps	Très large	En croissance
Complexité	Simple	Plus verbeux

La troisième ligne est celle qu'on oublie : la version de la spécification et la version que votre outil écrit sont deux choses différentes, et l'écart est réel côté SPDX. La sixième a changé fin 2025 : l'argument « seul SPDX est une norme » ne tient plus depuis la publication d'ECMA-424.

Un choix pragmatique

En pratique, le choix dépend du contexte :

Sécurité et DevSecOps : CycloneDX est souvent plus « plug-and-play » avec les outils de scan (Trivy, Grype, Snyk, Dependency Track)
Conformité réglementaire : SPDX est requis par certains secteurs (défense, automobile, médical) et reconnu ISO
Licences open source : SPDX reste la référence pour l'audit de licences
Gouvernement US : les deux formats sont acceptés par la CISA et le NIST

Ma recommandation : génèrez les deux formats quand c'est possible. Syft et Trivy le font facilement, ce qui permet de répondre à tous les consommateurs (équipes sécurité, juridique, clients, autorités).

# Générer les deux formats depuis le MÊME artefact, épinglé par digest
IMAGE="order-service:2.1.0@sha256:<digest>"
syft scan "registry:$IMAGE" -o cyclonedx-json > sbom.cdx.json
syft scan "registry:$IMAGE" -o spdx-json     > sbom.spdx.json

L'image est référencée par digest, et ce n'est pas une coquetterie de rédaction : un SBOM qui dit « order-service:2.1.0 » sans empreinte ne permet pas de savoir quelle image il décrit le jour où le tag a été redéployé. Le SBOM devient alors un document sur rien.

Outils de génération de SBOM

Plusieurs outils permettent de générer des SBOM. Voici les principaux que j'utilise en production :

Outils de génération

Outil	Éditeur	Points forts	Formats
Syft	Anchore	Images conteneur, archives, filesystem. Très rapide	CycloneDX, SPDX
Trivy	Aqua Security	Scanner de vulnérabilités + génération SBOM intégrée	CycloneDX, SPDX
cdxgen	OWASP/CycloneDX	Officiel CycloneDX, excellent support multi-langages	CycloneDX
spdx-sbom-generator	SPDX Project	Officiel SPDX, focus conformité licences	SPDX

# Syft : image conteneur vers CycloneDX et SPDX
NGINX="nginx:1.29.3@sha256:<digest>"
syft scan "registry:$NGINX" -o cyclonedx-json > sbom.cdx.json
syft scan "registry:$NGINX" -o spdx-json      > sbom.spdx.json

# Trivy : génération SBOM intégrée
trivy image --format cyclonedx "$NGINX" > sbom.cdx.json

# cdxgen : projet source multi-langages
cdxgen -o sbom.json ./mon-projet

Outils d'analyse de SBOM

Une fois le SBOM généré, ces outils permettent de l'exploiter :

Outil	Fonction	Guide
Grype	Scan de vulnérabilités sur SBOM existant	Guide Grype
Trivy	Scan multi-cibles (SBOM, images, IaC, secrets)	Guide Trivy
Dependency-Track	Plateforme de gestion continue des SBOM	Guide Dependency-Track

# Grype : scanner un SBOM existant
grype sbom:./sbom.cdx.json

# Gate CI : échouer si vulnérabilité high+ avec correctif disponible
grype sbom:./sbom.cdx.json --only-fixed --fail-on high

Distribuer un SBOM

Générer un SBOM ne suffit pas. Un SBOM qui reste sur le poste du développeur ou dans un artefact CI oublié ne sert à rien le jour où une CVE critique tombe.

Pour qu'un SBOM soit utile, il doit être :

Accessible : les équipes sécurité, les clients, les auditeurs doivent pouvoir le récupérer sans demander à personne
Associé à l'artefact : savoir quel SBOM correspond à quelle version déployée (sinon, c'est le chaos)
Vérifiable : garantir que le SBOM n'a pas été modifié après sa génération

Sans distribution structurée, on se retrouve à chercher « c'est où le SBOM de la version 2.3.1 en prod ? » pendant qu'une vulnérabilité est activement exploitée.

Trois stratégies de distribution

Stratégie	Avantages	Inconvénients
Fichier à côté (CI, S3, release)	Simple à mettre en place	Dissocié de l'image, risque de désynchronisation
SBOM attaché OCI	Co-localisé avec l'image, même registry	Nécessite des outils compatibles OCI
Attestation signée	Intégrité garantie, traçabilité cryptographique	Setup plus complexe (clés, Sigstore)

Les 3 stratégies de distribution SBOM — De la plus simple (fichier CI) à la plus robuste (attestation signée)

Ma recommandation : démarrez avec un fichier artefact CI pour avoir quelque chose rapidement, puis évoluez vers OCI attach + attestation signée dès que votre pipeline est stable.

Attacher un SBOM à une image avec Cosign

L'attachement OCI place le SBOM dans la même registry que l'image, avec une référence liée. Quand on pull l'image, on peut récupérer son SBOM sans chercher ailleurs. Pour maîtriser Cosign, consulte mon guide sur la signature d'images conteneur.

# Générer un SBOM (ex: SPDX)
syft packages mon-registry/mon-image:1.0.0 -o spdx > sbom.spdx

# Attacher le SBOM à l'image dans la registry
cosign attach sbom --sbom sbom.spdx mon-registry/mon-image:1.0.0

# Vérifier que le SBOM est bien attaché
cosign download sbom mon-registry/mon-image:1.0.0

SBOM en attestation signée

L'attestation va plus loin : elle signe cryptographiquement le SBOM et l'associe à l'image. Impossible de le modifier sans casser la signature.

# Attestation CycloneDX JSON (keyless via **Sigstore**/**OIDC**)
syft attest --output cyclonedx-json mon-registry/mon-image:1.0.0

# Vérifier l'attestation
cosign verify-attestation mon-registry/mon-image:1.0.0

Pourquoi cette approche plutôt qu'un simple fichier ?

Parce qu'on crée un graphe d'artefacts vérifiable autour de l'image : SBOM, signatures, provenance SLSA… tout est au même endroit, lié cryptographiquement. Le jour où un client demande « prouvez-moi ce que contient cette image », on a une réponse immédiate et vérifiable.

Réagir vite à une CVE : rechercher dans les SBOM

Le scénario classique

Vendredi 17h, une CVE critique tombe sur un composant très répandu. Mon manager me demande : « On est impactés ? Combien de systèmes ? C'est quoi la priorité ? ». Sans SBOM, je passe mon week-end à fouiller des package-lock.json et des images Docker. Avec des SBOM centralisés, j'ai ma réponse en quelques minutes.

Étape 1 : identifier les artefacts impactés

La première question est : quels projets/images utilisent ce composant ?

# Rechercher un composant dans tous mes SBOM CycloneDX
for sbom in *.cdx.json; do
  if jq -e '.components[] | select(.name=="log4j-core")' "$sbom" > /dev/null 2>&1; then
    echo "⚠️  $sbom contient log4j-core"
  fi
done

Pour une recherche plus précise avec la version :

# Trouver les versions exactes de log4j-core dans chaque SBOM
for sbom in *.cdx.json; do
  jq -r --arg file "$sbom" '
    .components[]
    | select(.name=="log4j-core")
    | "\($file): \(.name) \(.version)"
  ' "$sbom" 2>/dev/null
done

Étape 2 : vérifier si la version est vulnérable

Une fois les artefacts identifiés, vérifiez si leurs versions sont dans la plage vulnérable. Pour Log4Shell (CVE-2021-44228), les versions 2.0-beta9 à 2.14.1 étaient impactées.

# Extraire composant + version + purl pour corrélation
jq -r '
  .components[]
  | select(.name=="log4j-core")
  | "\(.name) \(.version) \(.purl // "no-purl")"
' mon-app.cdx.json

# Résultat exemple :
# log4j-core 2.14.1 pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1

Le purl (Package URL) est particulièrement utile : il permet une corrélation directe avec les bases de vulnérabilités (OSV, NVD, GitHub Advisory).

Étape 3 : prioriser la remédiation

Tous les artefacts impactés ne sont pas égaux. On priorise selon les critères décrits dans mon guide CVE, CVSS et EPSS :

Critère	Priorité haute	Priorité basse
Exposition	Prod exposée Internet	Env de dev interne
Criticité métier	Service critique 24/7	Batch mensuel
Exploitabilité	CVE avec exploit public	CVE théorique
Effort de correction	Bump de version simple	Refactoring majeur

# Exemple : lister les images de prod contenant le composant vulnérable
for sbom in prod-*.cdx.json; do
  if jq -e '.components[] | select(.name=="log4j-core" and .version=="2.14.1")' "$sbom" > /dev/null 2>&1; then
    echo "🔴 CRITIQUE: $sbom (prod)"
  fi
done

Étape 4 : automatiser avec Dependency-Track

Pour une gestion à l'échelle, on centralise les SBOM dans Dependency-Track. La plateforme :

Ingère les SBOM automatiquement (API, CI/CD)
Corrèle avec les bases de vulnérabilités en continu
Alerte quand une nouvelle CVE impacte un composant existant
Historise l'évolution des vulnérabilités par projet

# Upload d'un SBOM vers Dependency-Track via API
curl -X POST "https://dtrack.example.com/api/v1/bom" \
  -H "X-Api-Key: $DTRACK_API_KEY" \
  -H "Content-Type: application/json" \
  -d @sbom.cdx.json

Exemple concret : réponse à Log4Shell

Prenons l'exemple de Log4Shell (CVE-2021-44228, score CVSS 10.0). Avec des SBOM centralisés, le workflow de réponse devient :

Identifier : rechercher log4j-core dans tous les SBOM pour lister les artefacts concernés
Filtrer : parmi ces artefacts, isoler ceux avec une version vulnérable (< 2.15.0)
Prioriser : distinguer les environnements de production exposés des environnements de développement internes
Corriger : déployer les patches en commençant par les services critiques

Sans SBOM, chaque étape nécessite des recherches manuelles dans les dépôts, les images et les configurations. Avec des SBOM à jour, on passe de plusieurs jours de recherche à quelques heures de traitement.

Réduire le bruit : SBOM + VEX

Le problème : l'alert fatigue

Un scan de vulnérabilités sur un SBOM complet peut remonter des centaines de CVE. En pratique, la majorité ne sont pas exploitables dans le contexte :

Dépendance présente mais jamais appelée : le code vulnérable existe dans l'image mais aucun chemin d'exécution ne l'atteint
Composant désactivé : une feature flag ou une configuration désactive la fonction concernée
Contexte d'exploitation absent : la CVE nécessite un accès réseau que mon conteneur n'a pas
Déjà mitigé : un WAF, un contrôle réseau ou une sandbox neutralise l'attaque

Sans moyen de qualifier ces vulnérabilités, mes équipes passent leur temps à trier du bruit au lieu de corriger les vrais problèmes. C'est l'alert fatigue : à force de faux positifs, on finit par ignorer les vraies alertes.

VEX : qualifier l'exploitabilité

Le VEX (Vulnerability Exploitability eXchange) est un format standardisé pour documenter l'état d'exploitabilité d'une vulnérabilité dans un contexte donné. C'est le compagnon indispensable du SBOM.

Un document VEX associe une CVE à un statut :

Statut	Signification
not_affected	Le produit n'est pas impacté (composant non utilisé, config désactivée…)
affected	Le produit est impacté et nécessite une action
fixed	La vulnérabilité a été corrigée dans cette version
under_investigation	L'analyse est en cours

Exemple concret

Imaginons que Grype remonte CVE-2024-1234 sur libxml2 dans une image. Après analyse, on constate que :

l'application n'appelle jamais les fonctions XML concernées
le binaire vulnérable est présent mais jamais exécuté

On peut créer un VEX pour documenter cette décision :

{
  "document": {
    "category": "vex",
    "title": "VEX pour mon-app:1.2.0"
  },
  "statements": [
    {
      "vulnerability": { "name": "CVE-2024-1234" },
      "products": ["pkg:oci/mon-app@1.2.0"],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "libxml2 est présent dans l'image de base mais notre application n'utilise aucune fonction de parsing XML."
    }
  ]
}

Formats VEX

Deux formats principaux existent :

OpenVEX : format léger porté par Chainguard et l'écosystème Sigstore
CycloneDX VEX : intégré nativement dans CycloneDX depuis la version 1.4
CSAF VEX : format OASIS utilisé par les grands éditeurs (Red Hat, Cisco…)

Intégrer VEX dans le workflow

# Générer un scan avec Grype
grype sbom:./sbom.cdx.json -o json > vulns.json

# Appliquer un VEX pour filtrer les faux positifs
grype sbom:./sbom.cdx.json --vex ./mon-app.vex.json

# Le scan ne remonte plus les CVE marquées not_affected

Conclusion

Un SBOM utile, ce n'est pas « un fichier JSON de plus ». C'est un levier d'automatisation qui transforme une question floue (« on utilise quoi ? ») en données structurées et interrogeables.

Les bénéfices sont concrets :

Visibilité : on sait exactement ce que contient chaque artefact
Réactivité : en quelques minutes, on identifie les systèmes impactés par une CVE
Traçabilité : on peut prouver ce qu'on livre à ses clients et auditeurs
Conformité : on répond aux exigences CRA, NIS2 et Executive Order 14028

Ma checklist minimale :

Générer un SBOM sur chaque artefact final (image, binaire)
Scanner automatiquement avec Grype ou Trivy en CI/CD
Distribuer le SBOM (artefact CI → OCI attach → attestation signée)
Centraliser dans Dependency-Track pour la gestion continue
Qualifier les faux positifs avec des documents VEX
Surveiller les nouvelles CVE sur mes composants existants

La question n'est plus « faut-il adopter les SBOM ? » mais « comment les rendre actionnables ? ». Ce guide t'a donné les bases, à toi de les adapter à ton contexte.

À retenir

Un SBOM n'est pas un inventaire exhaustif : sa couverture dépend de la source scannée, de l'outil et du moment. Le document de 2026 a remplacé l'élément Depth par Coverage pour cette raison précise.
De 4 à 1 296 composants selon ce qu'on pointe, avec la même commande sur la même machine. Générez donc le SBOM depuis l'artefact livré, pas depuis le dépôt de code.
Le document de référence est les 2026 Minimum Elements, version 2.1 du 29 juillet 2026, co-signé par l'ANSSI. Il remplace les minimum elements de la NTIA de 2021 et porte dix-sept champs au lieu de sept.
La version de la spécification n'est pas celle que l'outil écrit. Syft 1.52.0 produit du CycloneDX 1.7 mais du SPDX 2.3. Vérifiez la sortie, ne la supposez pas.
CycloneDX est devenu une norme publiée, ECMA-424, en décembre 2025 : l'argument « seul SPDX est normalisé » ne tient plus.
Un SBOM sans licences ni empreintes ne satisfait pas SOCLE-PKG-SBM-1, et un requirements.txt n'en fournit ni l'une ni les autres. C'est le geste, pas l'outil, qu'il faut corriger.
La preuve attendue par le référentiel est un SBOM complet par artefact, au format normalisé, attaché à l'artefact et conservé, récupérable par les consommateurs.

Ressources

Voici quelques ressources pour aller plus loin :

Références officielles (USA)

CISA et partenaires, 2026 Minimum Elements for SBOM (version 2.1, 29 juillet 2026)
- Le document de référence actuel, co-signé avec l'ANSSI. Il remplace les minimum elements de la NTIA de 2021.
- PDF officiel : https://www.cisa.gov/sites/default/files/2026-07/2026_cisa_sbom_minimum_elements_508c.pdf
- Page CISA (peut être bloquée par certains réseaux / anti-bot) : https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
Brouillon de 2025, à ne plus citer comme référence
- Il a été soumis à commentaires jusqu'au 3 octobre 2025, puis remplacé par la version 2.1. Le lien reste ici pour retrouver l'historique : https://www.federalregister.gov/d/2025-16147
NTIA, SBOM Minimum Éléments (2021) : https://www.ntia.gov/page/software-bill-materials
OMB, exigences côté fournisseurs (supply chain)
- OMB M-22-18 (2022) : https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf
- OMB M-23-16 (2023) : https://www.whitehouse.gov/wp-content/uploads/2023/06/M-23-16.pdf
NIST, référentiels proches SBOM / supply chain
- NIST SSDF (SP 800-218) : https://csrc.nist.gov/pubs/sp/800/218/final
- NIST C-SCRM (SP 800-161 Rev.1) : https://csrc.nist.gov/pubs/sp/800/161/r1/final

Standards et spécifications

CycloneDX, Specification (overview) : https://cyclonedx.org/specification/overview/
SPDX, Specification v2.3 : https://spdx.github.io/spdx-spec/v2.3/

Guides et bonnes pratiques

OWASP / CycloneDX, Authoritative Guide to SBOM (PDF) : https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-SBOM-en.pdf
CISA, Types of SBOM Documents
- Page CISA (peut être bloquée par certains réseaux / anti-bot) : https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom
- Lien de repli (OpenSSF SBOM Catalog, “Types of SBOM Documents”) : https://sbom-catalog.openssf.org/sbom-types.html
OpenSSF, SBOM Tools (page officielle) : https://openssf.org/technical-initiatives/sbom-tools/
OpenSSF, SBOM Everywhere (repo GitHub) : https://github.com/ossf/sbom-everywhere
OpenSSF, SBOM Everywhere Wiki (Getting started / bases)
- Wiki : https://sbom-catalog.openssf.org/
- Getting started : https://sbom-catalog.openssf.org/getting-started
- À propos : https://sbom-catalog.openssf.org/about-us.html* Open Source Malware, Base de données communautaire des packages malveillants (npm, PyPI, NuGet) : https://opensourcemalware.com/
SBOM “transfrontalier” / partenaires (PDF)
- Joint Guidance, A Shared Vision of SBOM for Cybersecurity (PDF) : https://media.defense.gov/2025/Sep/03/2003791481/-1/-1/0/JOINT-GUIDANCE-A-SHARED-VISION-OF-SOFTWARE-BILL-OF-MATERIALS-FOR-CYBERSECURITY.PDF

VEX (utile en complément SBOM)

Le SBOM dit « ce composant est présent ». Le VEX (Vulnerability Exploitability eXchange) dit « cette vulnérabilité est-elle exploitable dans mon contexte ? ».

Consultez le guide VEX complet pour :

Comprendre les 4 statuts VEX (not_affected, affected, fixed, under_investigation)
Créer un document VEX avec vexctl
Intégrer VEX dans votre workflow SBOM → Scan → VEX → Rapport filtré

Ressources externes :

NTIA, VEX one-page summary (PDF) : https://www.ntia.gov/sites/default/files/publications/vex_one-page_summary_0.pdf
CycloneDX, VEX capability (overview) : https://cyclonedx.org/capabilities/vex/
CSAF, specs (utile pour VEX/advisories structurés)
- Vue "specs" : https://www.csaf.io/specification/
- Spec OASIS CSAF v2.0 (HTML) : https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html

Signature et attestations SBOM

Un SBOM non signé peut être falsifié. Utilisez Cosign pour :

Attester le SBOM : le lier cryptographiquement à l'image avec une signature
Vérifier l'attestation avant déploiement
Automatiser la vérification dans Kubernetes avec Kyverno

Réglementation Européenne

EU Cyber Resilience Act (CRA) : https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act