131% de CVE signalées en plus par jour en 2026 par rapport à l'an dernier.
← Retour au glossaire

Complétude de la SBOM

La complétude de la SBOM indique si une SBOM liste chaque composant entré dans le logiciel qu'elle décrit, à tous les niveaux, et pas seulement si le fichier est valide.

Dernière mise à jour : 11 novembre 2026

Une SBOM est complète lorsqu'elle liste chaque composant entré dans le logiciel qu'elle décrit, à tous les niveaux de l'arbre des dépendances, y compris les composants qu'aucun lockfile ni manifeste ne liste. La complétude de la SBOM est cette propriété. Les 2026 Minimum Elements de la CISA demandent aux auteurs de SBOM d'indiquer explicitement quand une information est inconnue, et notent que les destinataires peuvent considérer une SBOM comme incomplète si des données essentielles sur les composants sont retenues.

Complétude, validité et qualité sont différentes

QuestionCe que cela signifieCe qui le vérifieCe que cela ne peut pas dire
ValideLe fichier est conforme au schéma CycloneDX ou SPDXUn validateur de schémaS'il manque des composants
Qualité des champsChaque composant a un nom, une version, un fournisseur, un identifiant, une licence et un hashUn outil de notation de qualitéS'il manque des composants
ComplèteRien de ce qui est entré dans le logiciel ne manqueUne comparaison avec ce que le build a réellement reçuLes entrées que la comparaison n'a pas vues

L'identifiant de la deuxième ligne est en général une package URL ou un CPE. Un fichier peut réussir parfaitement les deux premiers contrôles et laisser quand même de côté la moitié du logiciel.

Pourquoi la complétude est difficile à mesurer après coup

Un scanner part des lockfiles, des manifestes ou de la sortie terminée. Il ne peut pas connaître un paquet qu'un script post-installation a téléchargé, une crate compilée dans un binaire, ou une couche d'image de base qu'on ne lui a jamais montrée. Chacun de ces éléments est une dépendance cachée.

Prenons un service Node.js dont le lockfile liste 400 paquets. L'un d'eux a un script postinstall qui télécharge un binaire précompilé pendant npm ci. Une SBOM générée à partir de package-lock.json est valide, chaque composant a une version et une package URL, et le binaire n'y figure pas. Aucun score de qualité ne le signalera, car rien dans le fichier n'indique ce qui manque.

Reconstruire plus tard ne règle pas non plus la question : à moins que le build soit un build reproductible, un second build peut recevoir autre chose que le premier.

Comment indiquer honnêtement la complétude

  • Indiquez le contexte de génération : si la SBOM a été produite à partir du code source avant le build, enregistrée pendant le build ou produite en analysant la sortie après coup.
  • Listez les lacunes connues : les parties du logiciel que l'outil n'a pas pu voir, comme du code vendorisé, des binaires précompilés ou des composants installés hors d'un gestionnaire de paquets.
  • Préférez un état motivé à un score. Un pourcentage de complétude suppose un total, et c'est justement ce que personne ne connaît. Une déclaration telle que « incomplète : le job a autorisé du trafic non surveillé » permet d'agir.

Les bonnes pratiques SBOM traitent plus largement de la façon d'indiquer ce qu'une SBOM n'a pas pu voir.

Les états de complétude dans CRACI

CRACI attribue un état de complétude à la SBOM de chaque job, et les caches en reçoivent un aussi. Les états, tels que la documentation de CRACI les définit :

  • Complete : « CRACI a observé des éléments complets pour le job, et chaque cache restauré était complet. »
  • Complete with connections : « Les exigences sont remplies, mais le job a utilisé une ou plusieurs connexions réseau personnalisées. »
  • Incomplete : « CRACI a identifié une condition susceptible de laisser des dépendances hors de la SBOM. »
  • Unavailable : « CRACI n'a pas pu terminer l'évaluation des éléments. »
  • Not recorded : « Le job est antérieur au suivi de la complétude. »

CRACI peut l'indiquer parce qu'il voit le trafic de chaque job vers les sources de paquets ; il sait donc quand quelque chose a pu passer à côté de lui : du trafic qu'il n'a pas surveillé, ou un cache restauré dont la propre SBOM était incomplète. Lorsqu'un job est incomplet, il en affiche la raison, par exemple « Unmonitored traffic was allowed ». Voir génération de SBOM.

Ces états s'appliquent aux builds qui s'exécutent sur des runners CRACI. Pour une SBOM venant d'un fournisseur, ou d'un pipeline qui ne tourne pas sur CRACI, utilisez les comparaisons et les règles ci-dessus.