Une SBOM générée par IA est une supposition sur votre build. Les régulateurs demandent un enregistrement.

Pourquoi les équipes essaient

L'attrait est réel. Vous collez un dépôt ou un lockfile dans un assistant de codage, vous demandez du CycloneDX, et un document bien formé revient en quelques secondes. Il peut même remplir des champs que les scanners laissent habituellement vides. Le champ fournisseur est l'exemple classique : la plupart des générateurs n'ont aucune source pour le renseigner, il reste donc vide. Un modèle à qui l'on demande un document complet peut écrire quelque chose dans chaque champ.

Ce dernier point résume le problème. Un scanner qui ne connaît pas le fournisseur laisse le champ vide. Un modèle qui ne le connaît pas peut tout de même produire une réponse plausible. Le document paraît plus complet et il est moins fiable.

Ce que le modèle voit réellement

Un modèle qui génère une SBOM travaille à partir du texte qu'il a sous les yeux : manifestes, lockfiles, éventuellement un Dockerfile. Il n'observe pas le build. Il ne peut donc pas voir :

• quelles versions le gestionnaire de paquets a résolues lorsqu'un dépôt ne versionne aucun lockfile,
• les paquets restaurés depuis un cache CI,
• les outils, paquets du système et binaires qu'une étape de build télécharge directement,
• ce qui est entré dans un binaire compilé livré avec un manifeste presque vide.

Deux dépôts montrent à quel point les fichiers peuvent être maigres. expressjs/express 5.2.1 ne versionne aucun lockfile : son package.json liste donc les dépendances sous forme de plages de versions, et les versions réelles sont décidées à l'installation. Le dépôt anthropics/claude-code en v2.1.259 ne contient aucun manifeste de dépendances ni aucun lockfile, et son paquet npm publié déclare zéro dépendance d'exécution tout en encapsulant un binaire natif précompilé. Un scanner déterministe appliqué à ce dépôt n'a rien à lire qui décrive le binaire. Un modèle à qui l'on donne les mêmes fichiers manque des mêmes informations, et il a plus de liberté pour combler le vide.

L'hallucination est un mode de défaillance documenté

Les modèles de langage citent des paquets qui n'existent pas. Le cas le mieux mesuré concerne la génération de code plutôt que la rédaction de SBOM, mais la défaillance qu'il montre s'applique tout autant à une liste de composants. Une étude USENIX Security 2025 a généré 576 000 échantillons de code avec 16 modèles et a relevé un taux moyen de paquets hallucinés d'au moins 5,2 % pour les modèles commerciaux et de 21,7 % pour les modèles open source, avec 205 474 noms de paquets hallucinés uniques. La documentation de GitHub sur Copilot Autofix prévient qu'il « may suggest fabricated dependencies published under statistically probable names ».

Les modèles ne donnent pas non plus deux fois la même réponse. La documentation d'Anthropic indique : « even with temperature set to 0, the results will not be fully deterministic and identical inputs may produce different outputs across API calls ». Deux SBOM générées à partir du même commit peuvent différer, et aucune n'indique laquelle est juste.

Dans une SBOM, une entrée hallucinée n'est pas une coquille sans conséquence. Un paquet qui n'existe pas, ou la mauvaise version d'un paquet qui existe, envoie la recherche de vulnérabilités au mauvais endroit, et le résultat revient, assuré et faux.

Ce que les normes attendent d'une SBOM

Éléments minimaux de la NTIA (2021)

La base de référence de la NTIA a défini sept champs de données : nom du fournisseur, nom du composant, version du composant, autres identifiants uniques, relation de dépendance, auteur des données de la SBOM et horodatage. Elle les a associés à la prise en charge de l'automatisation et à un ensemble de pratiques et de processus. Chaque champ décrit un fait sur le logiciel, pas une opinion à son sujet.

Éléments minimaux de la CISA de 2026

Le 29 juillet 2026, la CISA, la NSA, le FBI et des partenaires internationaux ont publié des éléments minimaux mis à jour qui remplacent la base de référence de 2021. Plusieurs ajouts sont difficiles à satisfaire sans observer le build :

• SBOM Generation Context : « the relative software lifecycle phase and data available at the time the SBOM author generated the SBOM », avec « before build », « build » et « after build » comme exemples. Un modèle qui lit un dépôt se situe, au mieux, à « before build ».
• Component Hash Value : « the output generated from applying a cryptographic hash algorithm to an executable component artifact ». Si l'auteur ne dispose pas de l'artefact, « the SBOM author should indicate the value is unknown ». Un modèle qui n'a jamais touché l'artefact ne peut pas produire une empreinte, seulement du texte qui y ressemble.
• SBOM Tool Name and Version : l'outil utilisé pour générer la SBOM doit être nommé.
• Coverage : « An SBOM should include information for all components that make up the target software, including transitive dependencies. There is no minimum depth. »
• Explicitly identifying unknown information : l'auteur « should explicitly state whether the information is unknown ». Une valeur inventée est tout le contraire.

Le Cyber Resilience Act de l'UE

Le CRA fait de la SBOM une obligation légale pour les fabricants de produits comportant des éléments numériques. L'annexe I, partie II, leur demande d'identifier et de documenter les vulnérabilités et les composants de ces produits, notamment en établissant une nomenclature logicielle dans un format courant et lisible par machine, couvrant au moins les dépendances de premier niveau. L'annexe VII place la SBOM dans la documentation technique, et une autorité de surveillance du marché peut la demander pour vérifier le respect des exigences essentielles.

Aucun de ces textes n'interdit les outils d'IA. Ce qu'ils demandent, ce sont des données qui décrivent le produit réel, et des déclarations honnêtes sur ce qui est inconnu. Une SBOM rédigée par déduction peine sur ces deux points.

Comment CRACI produit la SBOM

CRACI exécute vos jobs GitHub Actions sur ses propres runners. Vous remplacez runs-on par craci, et les exécutions apparaissent toujours dans GitHub. Pendant l'exécution du job, un proxy qui comprend les paquets observe le trafic vers les sources de paquets : la SBOM enregistre donc ce que le build a réellement récupéré, dépendances transitives comprises. Les preuves de dépendances suivent les caches CI : un paquet restauré depuis un cache reste donc dans l'enregistrement.

• Écosystèmes : sources npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, plus des presets de téléchargement.
• Complétude : chaque job et chaque cache est marqué Complete, Complete with connections, Incomplete, Unavailable ou Not recorded : les inconnues sont indiquées plutôt que remplies.
• Formats : CycloneDX et SPDX, avec les métadonnées de licence déclarées incluses dans l'export.
• Provenance : l'API renvoie les SBOM, les traces réseau et la provenance.

CRACI automatise une part importante de la visibilité et des preuves sur la chaîne d'approvisionnement dont a besoin une démarche plus large de conformité au CRA. Il ne rend pas à lui seul un produit conforme. La génération de SBOM au moment du build détaille le fonctionnement, et notre présentation du CRA couvre le calendrier.

Là où l'IA aide vraiment avec les SBOM

Une fois que vous disposez d'une SBOM enregistrée, un modèle sait bien l'exploiter : résumer quels composants présentent un risque, expliquer un avis de sécurité en langage clair ou rédiger la documentation associée, pour relecture humaine. La règle est simple. Laissez le build produire l'enregistrement, et laissez le modèle le lire.