Een AI-gegenereerde SBOM is een gok over uw build. Toezichthouders vragen om een vastlegging.

Waarom teams het proberen

De aantrekkingskracht is echt. U plakt een repository of lockfile in een codeassistent, vraagt om CycloneDX, en binnen enkele seconden komt er een correct opgebouwd document terug. Het kan zelfs velden invullen die scanners doorgaans leeg laten. Het leveranciersveld is het bekende voorbeeld: de meeste generatoren hebben daarvoor geen bron, dus het blijft leeg. Een model dat om een volledig document wordt gevraagd, kan in elk veld iets schrijven.

Dat laatste punt is het probleem in het klein. Een scanner die de leverancier niet kent, laat het veld leeg. Een model dat de leverancier niet kent, kan toch een aannemelijk antwoord geven. Het document ziet er vollediger uit en is minder betrouwbaar.

Wat het model werkelijk ziet

Een model dat een SBOM genereert, werkt op basis van de tekst die het voor zich heeft: manifests, lockfiles, misschien een Dockerfile. Het observeert de build niet. Het kan dus niet zien:

• welke versies de pakketbeheerder heeft gekozen als een repository geen lockfile commit,
• pakketten die uit een CI-cache zijn teruggezet,
• tools, OS-pakketten en binaries die een buildstap rechtstreeks downloadt,
• wat er in een gecompileerde binary zit die naast een bijna leeg manifest wordt geleverd.

Twee repositories laten zien hoe mager de bestanden kunnen zijn. expressjs/express 5.2.1 commit geen lockfile, dus de package.json vermeldt afhankelijkheden als versiebereiken en de werkelijke versies worden bij de installatie bepaald. De repository anthropics/claude-code op v2.1.259 heeft geen enkel afhankelijkheidsmanifest of lockfile, en het gepubliceerde npm-pakket declareert nul runtime-afhankelijkheden terwijl het een vooraf gebouwde native binary omhult. Een deterministische scanner die op die repository wordt gericht, heeft niets te lezen dat de binary beschrijft. Een model dat dezelfde bestanden krijgt, heeft hetzelfde gebrek aan informatie, en meer vrijheid om het gat op te vullen.

Hallucinatie is een gedocumenteerde foutmodus

Taalmodellen noemen pakketten die niet bestaan. Het best gemeten geval betreft het genereren van code en niet het schrijven van SBOM's, maar de fout die het laat zien, geldt net zo goed voor een lijst met componenten. Een studie op USENIX Security 2025 genereerde 576.000 codevoorbeelden met 16 modellen en vond een gemiddeld percentage gehallucineerde pakketten van ten minste 5,2% voor commerciële modellen en 21,7% voor open-sourcemodellen, met 205.474 unieke gehallucineerde pakketnamen. De eigen documentatie van GitHub voor Copilot Autofix waarschuwt dat het "may suggest fabricated dependencies published under statistically probable names."

Modellen geven ook niet twee keer hetzelfde antwoord. De documentatie van Anthropic stelt dat "even with temperature set to 0, the results will not be fully deterministic and identical inputs may produce different outputs across API calls." Twee SBOM's die uit dezelfde commit zijn gegenereerd, kunnen verschillen, en geen van beide zegt welke klopt.

In een SBOM is een gehallucineerde vermelding geen onschuldige typefout. Een pakket dat niet bestaat, of de verkeerde versie van een pakket dat wel bestaat, stuurt een zoekopdracht naar kwetsbaarheden naar de verkeerde plek, en het resultaat komt zelfverzekerd en fout terug.

Wat de standaarden van een SBOM verwachten

NTIA-minimumelementen (2021)

De NTIA-basislijn definieerde zeven gegevensvelden: naam van de leverancier, naam van het component, versie van het component, andere unieke identificaties, afhankelijkheidsrelatie, auteur van de SBOM-gegevens en tijdstempel. Daar horen automatiseringsondersteuning en een reeks werkwijzen en processen bij. Elk veld beschrijft een feit over de software, geen mening erover.

CISA-minimumelementen 2026

Op 29 juli 2026 publiceerden CISA, de NSA, de FBI en internationale partners bijgewerkte minimumelementen die de basislijn van 2021 vervangen. Aan verschillende toevoegingen is moeilijk te voldoen zonder de build te observeren:

• SBOM Generation Context: "the relative software lifecycle phase and data available at the time the SBOM author generated the SBOM," met "before build," "build," en "after build" als voorbeelden. Een model dat een repository leest, zit in het beste geval op before build.
• Component Hash Value: "the output generated from applying a cryptographic hash algorithm to an executable component artifact." Heeft de auteur het artefact niet, dan "the SBOM author should indicate the value is unknown." Een model dat het artefact nooit heeft aangeraakt, kan geen hash maken, alleen tekst in de vorm van een hash.
• SBOM Tool Name and Version: de tool waarmee de SBOM is gegenereerd, moet worden genoemd.
• 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: de auteur "should explicitly state whether the information is unknown." Een verzonnen waarde is daar het tegenovergestelde van.

De EU Cyber Resilience Act

De CRA maakt de SBOM tot een wettelijke verplichting voor fabrikanten van producten met digitale elementen. Bijlage I, deel II vereist dat zij kwetsbaarheden en componenten in die producten identificeren en documenteren, onder meer door een SBOM op te stellen in een gangbaar, machineleesbaar formaat dat "ten minste de afhankelijkheden op het hoogste niveau van de producten" dekt. Bijlage VII plaatst de SBOM in de technische documentatie, en een markttoezichtautoriteit kan die opvragen om de naleving van de essentiële eisen te controleren.

Geen van deze teksten verbiedt AI-tools. Wat ze vragen, zijn gegevens die het werkelijke product beschrijven, en eerlijke uitspraken over wat onbekend is. Een SBOM die op afleiding is gebaseerd, heeft met beide moeite.

Hoe CRACI de SBOM maakt

CRACI draait uw GitHub Actions-jobs op eigen runners. U wijzigt runs-on in craci, en runs verschijnen nog steeds in GitHub. Terwijl de job draait, observeert een proxy die pakketten herkent het verkeer naar pakketbronnen, zodat de SBOM vastlegt wat de build werkelijk heeft opgehaald, inclusief transitieve afhankelijkheden. Het bewijs van afhankelijkheden reist mee met CI-caches, dus een pakket dat uit een cache is teruggezet, blijft in de vastlegging staan.

• Ecosystemen: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk en Git-bronnen, plus downloadpresets.
• Volledigheid: elke job en cache wordt gemarkeerd als Complete, Complete with connections, Incomplete, Unavailable of Not recorded, zodat onbekende gegevens worden vermeld in plaats van ingevuld.
• Formaten: CycloneDX en SPDX, met gedeclareerde licentiemetadata in de export.
• Herkomst: de API levert SBOM's, netwerktraces en herkomstgegevens.

CRACI automatiseert een aanzienlijk deel van het inzicht in de softwareketen en het bewijs dat een breder CRA-nalevingsproces nodig heeft. Het maakt een product niet op eigen kracht compliant. SBOM-generatie tijdens de build gaat in op de details, en ons CRA-overzicht op de tijdlijn.

Waar AI wel helpt bij SBOM's

Hebt u eenmaal een vastgelegde SBOM, dan kan een model daar goed mee werken: samenvatten welke componenten risico dragen, een advisory in begrijpelijke taal uitleggen, of de documentatie eromheen opstellen zodat een mens die kan beoordelen. De regel is simpel. Laat de build de vastlegging maken, en laat het model die lezen.