Checklist qualité SBOM : comment valider les SBOM envoyées par vos fournisseurs

Les trois couches de la qualité d'une SBOM

Couche	Question	Ce qui la vérifie	Ce qu'elle ne peut pas vous dire
Valide	Le fichier se lit-il, et respecte-t-il le schéma du format et de la version qu'il déclare ?	Les validateurs de schéma	Si un champ contient quoi que ce soit d'utile
Exploitable	Les champs dont vous avez besoin sont-ils présents, et un outil peut-il s'en servir : identifiants qui correspondent aux avis de sécurité, licences, hashes, relations ?	Contrôles de champs, profils de conformité et scores de qualité	Ce qui manque dans le fichier
Complète	Liste-t-elle tout ce que contient le logiciel que vous avez reçu ?	La comparaison avec le build, ou avec une analyse du binaire livré	Rien de ce qui lit uniquement la SBOM ne peut répondre à cette question

La plupart des équipes qui reçoivent des SBOM s'arrêtent à la première couche. « Le fichier est valide » marque le début du contrôle, pas son résultat. La troisième couche, c'est la complétude de la SBOM.

Les référentiels en une minute

Citez le référentiel dans chaque demande et chaque retour : le niveau d'exigence est alors un niveau publié, pas votre opinion.

• NTIA, The Minimum Elements for a Software Bill of Materials (12 juillet 2021). Sept champs de données (nom du fournisseur, nom du composant, version, autres identifiants uniques, relation de dépendance, auteur des données de la SBOM, horodatage), la prise en charge de l'automatisation en SPDX, CycloneDX ou balises SWID, et des pratiques : fréquence, profondeur, inconnues connues, distribution et livraison, contrôle d'accès, tolérance aux erreurs. Les hashes, les licences, la phase du cycle de vie et les signatures y sont recommandés, au-delà du minimum.
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29 juillet 2026, après un projet publié le 22 août 2025). Remplace les éléments de la NTIA. Rédigé par 18 organisations de 14 pays, dont la CISA, la NSA, le FBI, le BSI allemand ainsi que le METI et le NCO japonais. Il compte 17 champs de données, dont dix nouveaux : signature de l'auteur de la SBOM, nom du format de données, version du format de données, contexte de génération, nom de l'outil, version de l'outil, version de la SBOM, valeur du hash du composant, algorithme du hash du composant et licence du composant. « Supplier name » devient « Component Producer ». Ses pratiques sont la couverture, l'identification explicite des informations inconnues, des données lisibles par machine, la prise en compte des mises à jour, la fréquence, ainsi que la distribution et la livraison. Le document formule chaque élément avec « should » (devrait) et précise qu'il ne crée pas de nouvelles exigences : ce sont les acheteurs qui le rendent contraignant en l'inscrivant dans leurs contrats.
• BSI, TR-03183-2 version 2.1.0 (20 août 2025), Allemagne. La plus stricte des trois, rédigée avec MUST (doit) : JSON ou XML, CycloneDX 1.6 ou ultérieur ou SPDX 3.0.1 ou ultérieur, une SBOM par version du logiciel, résolution récursive des dépendances avec la complétude de chaque liste de dépendances indiquée, un hash SHA-512 de chaque composant déployable, le nom de fichier du composant, les licences de distribution sous forme d'identifiants SPDX, et une package URL ou un CPE « if it exists » (s'il existe). Elle précise aussi qu'une SBOM ne doit pas contenir d'informations sur les vulnérabilités : celles-ci ont leur place dans un document VEX ou un avis de sécurité.
• Alignement international. A Shared Vision of SBOM for Cybersecurity (3 septembre 2025) est signé par 18 organisations de 15 pays. Les travaux du G7 sur les SBOM portent sur les systèmes d'IA (« A shared G7 vision on SBOM for AI », 2025, et « SBOM for AI – Minimum Elements », mai 2026) et ne fixent aucune exigence pour les SBOM des fournisseurs de systèmes embarqués.
• Automobile. L'Auto-ISAC a publié un SBOM Informational Report le 11 février 2025.

La checklist

Comment lire les cellules : Obligatoire signifie que le document emploie « doit ». Élément minimal signifie que l'élément figure dans la liste minimale du document (le socle de la NTIA, ou les éléments « should » de la CISA). Recommandé signifie que le document le cite au-delà du minimum. Non mentionné signifie que le document ne le demande pas. La manière de tester chaque contrôle, et le message de retour à envoyer, figurent dans la section suivante.

Contrôles au niveau de la SBOM

Contrôle	Pourquoi c'est important	NTIA 2021	CISA 2026	BSI TR-03183-2
1. Se lit et est valide selon le schéma qu'elle déclare	Un fichier que vos outils ne peuvent pas lire n'est pas une SBOM	Obligatoire : SPDX, CycloneDX ou balises SWID	Pratique : SPDX ou CycloneDX lisible par machine	Obligatoire : JSON ou XML
2. La version de la spécification atteint votre seuil	Les anciennes versions ne peuvent pas porter les champs dont vous avez besoin	Non mentionné	Élément minimal : nom et version du format de données ; éviter les versions obsolètes	Obligatoire : CycloneDX 1.6+ ou SPDX 3.0.1+
3. Auteur de la SBOM	Quelqu'un répond du contenu	Élément minimal : « Author of SBOM Data »	Élément minimal : « SBOM Author », l'organisation, pas l'outil	Obligatoire : « Creator of the SBOM », e-mail ou URL
4. Horodatage	Indique quelle SBOM est la plus récente	Élément minimal	Élément minimal	Obligatoire ; UTC recommandé
5. Nom et version de l'outil	Indique ce que la SBOM peut couvrir de façon fiable	Non mentionné	Élément minimal	Non mentionné
6. Contexte de génération	Un scan des sources et un enregistrement du build d'une même release diffèrent	Recommandé : phase du cycle de vie (« source », « build », « post-build »)	Élément minimal : « before build », « build » ou « after build »	Pas de champ ; le contenu doit correspondre à ce qui était disponible pendant le build
7. Version ou numéro de série de la SBOM	Distingue une correction de l'original	Non mentionné	Élément minimal : « SBOM Version »	Obligatoire si le format en prévoit un : « SBOM-URI »
8. Signature de l'auteur	Montre que le fichier vient du fournisseur, sans modification	Recommandé : la signature est encouragée	Élément minimal : « SBOM Author Signature »	Informatif uniquement : « ideally » (idéalement) signée
9. Le composant de premier niveau correspond à ce que vous avez reçu	La SBOM de la mauvaise release est pire que pas de SBOM du tout	Élément minimal : composants principaux	Élément minimal : le composant cible	Obligatoire : le composant principal, racine de l'arbre

Contrôles au niveau des composants

Contrôle	Pourquoi c'est important	NTIA 2021	CISA 2026	BSI TR-03183-2
10. Nom du composant	La première chose qu'utilise toute correspondance	Élément minimal	Élément minimal	Obligatoire ; le nom de fichier en l'absence de nom
11. Version : pas de valeurs latest, unknown ou vides	Les avis de sécurité s'appliquent à des plages de versions	Élément minimal	Élément minimal ; l'indiquer si elle est inconnue	Obligatoire ; la date du fichier en l'absence de version
12. Producteur ou fournisseur	Distingue deux composants portant le même nom, et indique qui corrige	Élément minimal : « Supplier Name »	Élément minimal : « Component Producer »	Obligatoire : « Component creator », e-mail ou URL
13. Une package URL partout où l'écosystème en a une, un CPE sinon ; les deux bien formés	Sans identifiant (package URL, CPE), rien ne peut être rapproché d'une base de vulnérabilités	Élément minimal : « Other Unique Identifiers », comme CPE, SWID ou PURL, s'ils existent	Élément minimal : au moins un identifiant, comme CPE ou PURL ; les inclure tous	Obligatoire s'il existe : CPE ou purl
14. Valeur et algorithme du hash, correspondant au fichier reçu	Prouve que cette SBOM décrit ce binaire	Recommandé	Élément minimal : hash de l'artefact exécutable, avec un algorithme approuvé par une autorité comme le NIST	Obligatoire : SHA-512 du composant déployable
15. Licence sous forme d'identifiants ou d'expressions SPDX, sans NOASSERTION généralisé	C'est à partir de cette information que votre spécialiste des licences évalue le copyleft et les autres obligations	Recommandé	Élément minimal ; identifiants SPDX si possible	Obligatoire : licences de distribution, identifiants SPDX en priorité
16. Relations de dépendance, et si la liste est complète	Montre ce qui a apporté un paquet vulnérable, et si l'on peut se fier aux lacunes	Élément minimal ; indiquer quand les dépendances directes sont listées en totalité	Élément minimal	Obligatoire, avec la complétude de chaque liste indiquée
17. Nom de fichier	Relie l'entrée à un fichier sur l'appareil	Non mentionné	Non mentionné	Obligatoire
18. Propriétés exécutable, archive et structuré	Indique de quel type de fichier il s'agit pour chaque composant	Non mentionné	Non mentionné	Obligatoire

Contrôles de couverture

Contrôle	Pourquoi c'est important	NTIA 2021	CISA 2026	BSI TR-03183-2
19. Profondeur transitive, pas seulement le premier niveau	L'essentiel du code vulnérable arrive de façon indirecte	Premier niveau obligatoire ; transitives recommandées	Pratique de couverture : inclure les dépendances transitives ; pas de profondeur minimale	Obligatoire : résolution récursive
20. Inconnues connues déclarées	Une SBOM qui déclare ses lacunes est fiable pour ce qu'elle liste	Pratique obligatoire	Pratique : informations inconnues et non divulguées signalées	Obligatoire, via la déclaration de complétude
21. Une SBOM par version de logiciel livrée	C'est la version que vous exploitez qui compte	Obligatoire : une nouvelle SBOM pour chaque build ou release	Pratique : fréquence	Obligatoire
22. Corrections envoyées sous forme de nouvelle SBOM	Une erreur corrigée en silence ne peut pas être tracée	Pratique : tolérance aux erreurs	Pratique : prise en compte des mises à jour	Obligatoire : une SBOM mise à jour lorsque des erreurs sont corrigées
23. Plausibilité : pas de doublons, un nombre de composants cohérent avec le produit, des paquets du système d'exploitation présents pour un appareil sous Linux	Le test de complétude le moins coûteux	Non mentionné	Pratique de couverture : instances multiples listées séparément	Les instances multiples doivent être listées séparément

Comment tester chaque contrôle, et quoi dire au fournisseur

Contrôle	Comment le tester automatiquement	Message de retour pour le fournisseur
1, 2. Schéma et version de la spécification	Un validateur de schéma pour le format et la version déclarés ; puis comparer specVersion (CycloneDX) ou la version SPDX avec votre seuil	« Le fichier échoue à la validation du schéma CycloneDX 1.6 aux chemins indiqués. Merci de le régénérer avec un générateur et de le valider avant de l'envoyer. »
3 à 7. Auteur, horodatage, outil, contexte, version	Présence des métadonnées requises : en CycloneDX metadata.authors, metadata.timestamp, metadata.tools, metadata.lifecycles, serialNumber et version ; en SPDX, les informations de création	« La SBOM n'indique ni l'outil qui l'a produite ni le contexte de génération. Ce sont deux CISA 2026 Minimum Elements. »
8. Signature	Une signature est présente et se vérifie avec la clé publiée par le fournisseur	« Merci de signer la SBOM, ou d'envoyer une signature détachée, comme le décrit l'élément CISA 2026 SBOM Author Signature. »
9. Composant de premier niveau	Le nom et la version de metadata.component (CycloneDX) ou de l'élément racine décrit (SPDX) correspondent à la référence et à la version logicielle reçues	« Cette SBOM décrit la version 5.2.0 ; nous avons reçu la 5.3.0. Merci d'envoyer la SBOM de la 5.3.0. »
10, 11. Nom et version	Aucun nom vide ; aucune version vide, latest ou unknown, sauf si elle est déclarée inconnue	« 14 composants n'ont pas de version. Merci d'indiquer la version exacte, ou de la signaler comme inconnue. »
12. Producteur	Un fournisseur, un fabricant ou un auteur sur chaque composant	« Des composants n'ont pas de producteur, ce que demande l'élément CISA 2026 Component Producer. »
13. Identifiants	Chaque purl est analysée sans erreur par une bibliothèque package URL conforme à ECMA-427 ; chaque CPE respecte la syntaxe CPE 2.3 et figure dans le dictionnaire CPE de la NVD	« Aucun composant n'a de package URL ni de CPE : aucun ne peut donc être rapproché des bases de vulnérabilités. Merci d'ajouter une purl pour chaque paquet issu d'un gestionnaire de paquets. »
14. Hashes	Une entrée SHA-512 sur chaque composant déployable ; calculer le sha512sum du fichier reçu et comparer	« La SBOM ne contient aucun hash. BSI TR-03183-2 demande le SHA-512 de chaque composant déployable. »
15. Licences	Des identifiants ou expressions de licence qui se résolvent dans la liste des licences SPDX ; compter les valeurs NOASSERTION et vides	« 92 % des composants portent NOASSERTION comme licence. Merci d'indiquer des identifiants de licence SPDX. »
16. Dépendances	Un graphe dependencies (CycloneDX) ou des relations de dépendance (SPDX) ; une déclaration de complétude, comme les compositions CycloneDX avec une valeur aggregate	« La SBOM est une liste à plat. Merci d'inclure les relations de dépendance et d'indiquer si chaque liste est complète. »
17, 18. Nom de fichier et propriétés de fichier	Les propriétés que BSI TR-03183-2 définit pour chaque format sont présentes	« Merci d'ajouter le nom de fichier et les propriétés exécutable, archive et structuré, comme l'exige BSI TR-03183-2 v2.1.0. »
19 à 23. Couverture	Profondeur du graphe de dépendances, détection des doublons, nombre de composants comparé à celui de produits similaires, composants attendus selon le type de produit	« La SBOM ne liste ni noyau, ni bootloader, ni paquets du système de base pour un écran sous Linux. Merci d'envoyer la SBOM de l'image complète. »

Les pourcentages et les nombres des messages de retour sont des exemples. Indiquez les vrais chiffres, et citez le référentiel et sa version à chaque fois.

Ce qu'un bon score laisse encore passer

Un fichier peut être valide, obtenir 9 sur 10 et manquer pourtant la moitié du produit. Les scores de qualité lisent les champs présents ; ils ne voient pas les composants absents.

Exemple concret. Un fournisseur envoie la SBOM d'un écran sous Linux. C'est du CycloneDX 1.6 valide, chaque composant a une version, une package URL, une licence et un hash SHA-512, et le graphe de dépendances est bien formé. Elle liste l'application d'affichage et 40 bibliothèques. Elle ne liste ni le noyau Linux, ni le bootloader, ni aucun paquet du système de base. Tous les contrôles de champs passent. La SBOM est inutile pour les CVE du noyau, qu'un appareil Linux doit surveiller, parce que le noyau n'y figure pas.

Comment une équipe destinataire peut tester la complétude :

• Comparer avec une analyse binaire du firmware livré. Certains OEM s'en servent comme SBOM de substitution tant que celle du fournisseur n'est pas assez bonne, puis comme contre-vérification.
• Vérifier la présence des composants attendus selon le type de produit. Une image Linux contient un noyau, une bibliothèque C et un système d'init ; un contrôleur industriel, ses piles de protocoles.
• Demander le contexte de génération et l'outil. Un scan des sources ne voit pas ce que le build a récupéré.
• Demander si la SBOM provient du build qui a produit le logiciel reçu. C'est la question qui tranche la troisième couche.

Une petite SBOM peut être légitime. Un ECU bare-metal doté d'un firmware propriétaire et d'une calibration fournisseur peut honnêtement ne compter que deux composants. Acceptez-le lorsque la SBOM le dit et déclare ses inconnues connues, plutôt que de la pénaliser pour sa taille.

Les outils qui automatisent les contrôles

Vérifiés sur GitHub le 11 novembre 2026. Aucun de ces dépôts n'est archivé.

Outil	Ce qu'il vérifie	Ce qu'il ne fait pas	Statut
CycloneDX CLI	Validation de schéma de CycloneDX 1.0 à 1.7, JSON ou XML ; --fail-on-errors pour la CI	SPDX, qualité des champs, profils de référentiels	v0.33.1, juillet 2026
sbom-utility	Validation de schéma de CycloneDX 1.2 à 1.7 et SPDX 2.1 à 2.3 en JSON, avec des variantes de schéma personnalisées	SPDX 3, XML, profils de référentiels	v0.19.2, juin 2026
SPDX tools-java	Verify pour SPDX 2.0 à 2.3 et 3.0.1	CycloneDX, profils de référentiels	v2.0.7, juin 2026
SPDX tools-python	pyspdxtools -i : validation complète de SPDX 2.2 et 2.3	La lecture de SPDX 3, dont la prise en charge est expérimentale	v0.8.5, mars 2026
SPDX NTIA Conformance Checker	SPDX 2.2, 2.3 et 3.0 par rapport à NTIA 2021, CISA FSCT3 et BSI TR-03183-2 v2.1.0 ; existe aussi en version web	CycloneDX ; CISA 2026 fait l'objet d'une demande ouverte	v6.0.0, octobre 2026
sbomqs	Un score de 0 à 10 portant sur l'identification, la provenance, l'intégrité, la complétude, les licences, les vulnérabilités et la structure ; des profils compliance pour CISA 2026, NTIA 2021, BSI TR-03183-2 v1.1 à v2.1.0, FSCT v3 et OpenChain Telco	Voir les composants manquants	v2.1.3, octobre 2026 ; profil CISA 2026 depuis la v2.1.0, corrigé dans la v2.1.2
sbom-scorecard	Un score pondéré de la conformité à la spécification, des informations de génération, et des identifiants, versions et licences des paquets	Profils de référentiels	0.0.7, avril 2023, la dernière release

Pour l'instant, seul sbomqs vérifie les CISA 2026 Minimum Elements. Consultez les notes de version de chaque outil avant de vous fier à un profil : dans sbomqs 2.1.1, l'option CISA 2026 exécutait par erreur le contrôle de 2021. Pour BSI TR-03183-2 v2.1.0 dans sbomqs, utilisez --bsi-v21 ou --bsi ; --bsi-v2 vérifie la v2.0.0.

Une étape de réception minimale pour la SBOM CycloneDX d'un fournisseur :

# 1. Valid: fail the intake on schema errors
cyclonedx-cli validate --input-file supplier-sbom.json --input-format json --fail-on-errors

# 2. Usable: run the profile your requirement names
sbomqs compliance --bsi-v21 supplier-sbom.json
sbomqs compliance --ntia supplier-sbom.json   # CISA 2026 Minimum Elements

# 3. Track field quality over time
sbomqs score supplier-sbom.json

# 4. The hash in the SBOM matches the file you received
sha512sum firmware-5.3.0.bin

Pour SPDX, utilisez sbomcheck -s spdx3 -c bsi supplier-sbom.json du NTIA Conformance Checker. Lisez le rapport de conformité et rejetez le fichier sur les contrôles que votre exigence rend obligatoires ; renvoyez-le au fournisseur avec les messages de retour ci-dessus.

L'inscrire dans les exigences fournisseurs

Une checklist que le fournisseur n'a jamais vue n'est pas une exigence. Inscrivez-la dans l'annexe du contrat :

• Le référentiel et sa version : par exemple « BSI TR-03183-2 v2.1.0 » ou « CISA 2026 Minimum Elements ». Nommez-en un ; n'écrivez pas « standard du secteur ».
• Le format et la version minimale de la spécification : par exemple CycloneDX 1.6 ou ultérieur, ou SPDX 3.0.1 ou ultérieur, en JSON.
• Les champs que vous ajoutez en plus, comme des hashes SHA-512 ou des package URL pour chaque paquet.
• La livraison : une SBOM par version de logiciel livrée, avant ou avec le logiciel.
• La validation que le fournisseur effectue avant l'envoi, avec l'outil et le profil nommés.
• La boucle de retour : qui reçoit les retours, et dans quel délai une SBOM corrigée est attendue.

Le côté fournisseur du même accord se trouve dans le guide SBOM pour les fournisseurs. Pour un éditeur de logiciels qui répond à une demande ponctuelle, voir les demandes de SBOM des clients.

Corriger une SBOM refusée (pour les fournisseurs)

• Fichiers écrits à la main. Utilisez un générateur ou une bibliothèque SBOM, jamais un éditeur de texte.
• Package URL manquantes. Générez-les depuis le gestionnaire de paquets ou le build, pas à la main. Une purl saisie à la main est une purl devinée.
• Licences manquantes. Reprenez la licence déclarée dans les métadonnées du paquet, sous forme d'identifiant SPDX.
• Pas de hashes. Calculez-les sur les fichiers que vous livrez réellement, à la fin du build.
• La mauvaise release. Générez la SBOM dans le build de release, et nommez-la d'après la version.
• Premier niveau uniquement. Utilisez une méthode qui résout les dépendances transitives.

La façon la plus fiable de corriger à la fois la complétude et les identifiants est de générer la SBOM à partir du build qui a produit le logiciel livré. Voir les SBOM générées au build et les bonnes pratiques SBOM.

D'où viennent les bonnes SBOM, et la place de CRACI

Pour les fournisseurs qui buildent sur GitHub Actions, CRACI remplace les runners hébergés par GitHub et enregistre la SBOM pendant le build : elle liste donc ce que le build a réellement récupéré.

• Chaque paquet avec une package URL, et chaque composant avec sa licence déclarée.
• Les dépendances transitives, à tous les niveaux de profondeur atteints par le build.
• Un état de complétude pour chaque job, qui répond à la question des inconnues connues build par build : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.
• Export en CycloneDX ou SPDX ; l'API SBOM renvoie du CycloneDX 1.7 JSON.

Pour toute une organisation d'ingénierie, voir standardiser la génération de SBOM, et pour Linux embarqué, pourquoi les scanners manquent ce que contiennent les builds Yocto.

Pour les OEM, des SBOM tierces peuvent être ajoutées à CRACI : les composants que vous achetez sont ainsi surveillés pour les nouvelles vulnérabilités, aux côtés de vos propres builds. Voir les outils de gestion des SBOM pour la comparaison.

Quand CRACI n'est pas la réponse

• Valider et noter les SBOM que vous recevez. CRACI ne propose ni validateur de SBOM ni score de qualité. Utilisez les outils ci-dessus.
• Les fournisseurs sans CI, ou dont le code est généré par des outils à base de modèles, sans récupération de paquets. Un enregistreur de build apporte peu ; une SBOM validée issue d'une bibliothèque de génération est la réponse réaliste.
• Le firmware que vous ne recevez que sous forme binaire. L'analyse binaire répond à ce cas.
• Les SBOM signées, la signature de l'auteur de CISA 2026. CRACI ne signe pas les SBOM.

Qualité et validation des SBOM : questions fréquentes

Comment vérifier la qualité d'une SBOM envoyée par un fournisseur ?

Testez trois couches. Validez le fichier par rapport à son schéma, contrôlez les champs selon un référentiel nommé comme BSI TR-03183-2 ou les CISA 2026 Minimum Elements, puis testez la complétude : comparez-la avec une analyse binaire de ce que vous avez reçu et vérifiez la présence des composants que le type de produit doit contenir.

Quels champs une SBOM doit-elle contenir ?

Cela dépend du référentiel que vous citez. Les 2026 Minimum Elements de la CISA listent 17 champs, dont l'auteur, l'horodatage, l'outil, le contexte de génération et, pour chaque composant, le nom, la version, le producteur, les identifiants, le hash et la licence. BSI TR-03183-2 ajoute un hash SHA-512, le nom de fichier et les propriétés de fichier, et les rend obligatoires.

Qu'est-ce qui a changé entre les éléments minimaux de la NTIA et les 2026 Minimum Elements de la CISA ?

La liste 2026 de la CISA remplace les sept champs de la NTIA par 17. Sont nouveaux la signature de l'auteur, le nom et la version du format de données, le contexte de génération, le nom et la version de l'outil, la version de la SBOM, la valeur et l'algorithme du hash du composant, et la licence du composant. Supplier name est devenu Component Producer, et la profondeur est devenue la couverture.

Qu'exige BSI TR-03183-2 dans une SBOM ?

La version 2.1.0 exige CycloneDX 1.6+ ou SPDX 3.0.1+ en JSON ou XML, une SBOM par version du logiciel, des dépendances récursives avec leur complétude indiquée et, pour chaque composant, le créateur, le nom, la version, le nom de fichier, les licences, le hash SHA-512 et les propriétés de fichier, avec une package URL ou un CPE s'il en existe un.

Une SBOM a-t-elle besoin de hashes ? Avec quel algorithme ?

La NTIA les recommandait ; CISA 2026 fait du hash un élément minimal, avec un algorithme approuvé par une autorité comme le NIST ; BSI TR-03183-2 exige le SHA-512 de chaque composant déployable. Demandez du SHA-512 et comparez-le avec le fichier reçu.

Faut-il à la fois un CPE et une PURL ?

Pas toujours. Demandez une package URL partout où l'écosystème en a une, et un CPE là où il n'en a pas, comme pour de nombreux composants commerciaux ou embarqués. CISA 2026 demande au moins un identifiant et tous ceux qui sont connus ; le BSI exige chacun d'eux s'il existe.

Comment valider un fichier CycloneDX ou SPDX ?

Pour CycloneDX, cyclonedx-cli validate avec --fail-on-errors, ou sbom-utility. Pour SPDX, la commande Verify de SPDX tools-java, ou pyspdxtools pour SPDX 2.2 et 2.3. Exécutez ensuite un profil de référentiel avec sbomqs ou le SPDX NTIA Conformance Checker.

Qu'est-ce qu'un bon score de qualité de SBOM ?

Il n'existe pas de seuil standard, ni de benchmark que nous citerions. Un score mesure les champs présents, pas la complétude : un fichier peut obtenir 9 sur 10 et manquer la moitié du produit. Fixez plutôt des critères de réussite par contrôle dans votre exigence fournisseur, et suivez le score comme une tendance.