En AI-generert SBOM er en gjetning om bygget ditt. Myndighetene ber om en registrering.

Hvorfor team prøver det

Fristelsen er reell. Du limer et repository eller en lockfile inn i en kodeassistent, ber om CycloneDX, og et velformet dokument kommer tilbake på sekunder. Det kan til og med fylle ut felter som skannere ofte lar stå tomme. Leverandørfeltet er det vanlige eksempelet: De fleste generatorer har ingen kilde til det, så det blir tomt. En modell som blir bedt om et fullstendig dokument, kan skrive noe i hvert felt.

Det siste punktet er problemet i miniatyr. En skanner som ikke vet hvem leverandøren er, lar feltet stå tomt. En modell som ikke vet det, kan likevel produsere et plausibelt svar. Dokumentet ser mer fullstendig ut og er mindre pålitelig.

Hva modellen faktisk ser

En modell som genererer en SBOM, jobber ut fra teksten foran seg: manifester, lockfiler, kanskje en Dockerfile. Den observerer ikke bygget. Derfor kan den ikke se:

• hvilke versjoner pakkebehandleren valgte når et repository ikke har committet noen lockfile,
• pakker gjenopprettet fra en CI-cache,
• verktøy, OS-pakker og binærfiler som et byggesteg laster ned direkte,
• hva som gikk inn i en kompilert binærfil som leveres sammen med et nesten tomt manifest.

To repositorier viser hvor tynne filene kan være. expressjs/express 5.2.1 har ingen committet lockfile, så package.json lister avhengigheter som versjonsområder, og de faktiske versjonene avgjøres ved installasjon. Repositoriet anthropics/claude-code i v2.1.259 har ikke noe avhengighetsmanifest eller noen lockfile i det hele tatt, og den publiserte npm-pakken oppgir null kjøretidsavhengigheter, samtidig som den pakker inn en forhåndsbygget native binærfil. En deterministisk skanner rettet mot det repositoriet har ingenting å lese som beskriver binærfilen. En modell som får de samme filene, har like lite informasjon, og større frihet til å fylle hullet.

Hallusinering er en dokumentert feilkilde

Språkmodeller navngir pakker som ikke finnes. Det best målte tilfellet gjelder kodegenerering snarere enn skriving av SBOM-er, men feilen det viser, gjelder like godt for en liste over komponenter. En studie fra USENIX Security 2025 genererte 576 000 kodeeksempler med 16 modeller og fant en gjennomsnittlig andel hallusinerte pakker på minst 5,2 % for kommersielle modeller og 21,7 % for modeller med åpen kildekode, med 205 474 unike hallusinerte pakkenavn. GitHubs egen dokumentasjon for Copilot Autofix advarer om at det "may suggest fabricated dependencies published under statistically probable names."

Modeller gir heller ikke samme svar to ganger. Anthropics dokumentasjon slår fast at "even with temperature set to 0, the results will not be fully deterministic and identical inputs may produce different outputs across API calls." To SBOM-er generert fra samme commit kan være forskjellige, og ingen av dem sier hvilken som er riktig.

I en SBOM er en hallusinert oppføring ikke en harmløs skrivefeil. En pakke som ikke finnes, eller feil versjon av en som finnes, sender et sårbarhetsoppslag til feil sted, og resultatet kommer tilbake selvsikkert og feil.

Hva standardene forventer at en SBOM skal inneholde

NTIA minimum elements (2021)

NTIA-grunnlinjen definerte sju datafelter: leverandørnavn, komponentnavn, komponentversjon, andre unike identifikatorer, avhengighetsforhold, forfatter av SBOM-dataene og tidsstempel. Den koblet dem med støtte for automatisering og et sett med praksiser og prosesser. Hvert felt beskriver et faktum om programvaren, ikke en mening om den.

CISA 2026 minimum elements

29. juli 2026 publiserte CISA, NSA, FBI og internasjonale partnere oppdaterte minimumselementer som erstatter grunnlinjen fra 2021. Flere av tilleggene er vanskelige å oppfylle uten å observere bygget:

• SBOM Generation Context: "the relative software lifecycle phase and data available at the time the SBOM author generated the SBOM," med "before build," "build," og "after build" som eksempler. En modell som leser et repository, er i beste fall på stadiet before build.
• Component Hash Value: "the output generated from applying a cryptographic hash algorithm to an executable component artifact." Hvis forfatteren ikke har artefaktet, "the SBOM author should indicate the value is unknown." En modell som aldri har vært borti artefaktet, kan ikke produsere en hash, bare tekst formet som en.
• SBOM Tool Name and Version: Verktøyet som ble brukt til å generere SBOM-en, må navngis.
• 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: Forfatteren "should explicitly state whether the information is unknown." En oppdiktet verdi er det motsatte av dette.

EUs Cyber Resilience Act

CRA gjør SBOM-en til en lovpålagt plikt for produsenter av produkter med digitale elementer. Vedlegg I del II krever at de identifiserer og dokumenterer sårbarheter og komponenter i produktene, blant annet med en programvarestykkliste i et alminnelig brukt, maskinlesbart format som minst dekker avhengighetene på øverste nivå. Vedlegg VII plasserer SBOM-en i den tekniske dokumentasjonen, og en markedstilsynsmyndighet kan be om den for å kontrollere samsvar med de grunnleggende kravene.

Ingen av disse tekstene forbyr AI-verktøy. Det de ber om, er data som beskriver det faktiske produktet, og ærlige opplysninger om hva som er ukjent. En SBOM skrevet ut fra utledning sliter med begge deler.

Slik lager CRACI SBOM-en

CRACI kjører GitHub Actions-jobbene dine på egne runnere. Du endrer runs-on til craci, og kjøringene vises fortsatt i GitHub. Mens jobben kjører, observerer en pakkebevisst proxy trafikken til pakkekilder, så SBOM-en registrerer hva bygget faktisk hentet, inkludert transitive avhengigheter. Dokumentasjonen av avhengigheter følger med CI-cacher, så en pakke som gjenopprettes fra en cache, blir værende i registreringen.

• Økosystemer: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder, pluss download-presets.
• Fullstendighet: Hver jobb og cache merkes Complete, Complete with connections, Incomplete, Unavailable eller Not recorded, så det som er ukjent, angis i stedet for å fylles ut.
• Formater: CycloneDX og SPDX, med deklarerte lisensmetadata inkludert i eksporten.
• Provenance: API-et returnerer SBOM-er, nettverksspor og provenance.

CRACI automatiserer en betydelig del av innsynet i leverandørkjeden og dokumentasjonen som en bredere CRA-samsvarsprosess trenger. Det sikrer ikke alene at et produkt er i samsvar. SBOM-generering under bygget dekker detaljene, og vår CRA-oversikt dekker tidslinjen.

Der AI faktisk hjelper med SBOM-er

Når du har en registrert SBOM, er en modell god til å jobbe med den: å oppsummere hvilke komponenter som bærer risiko, forklare et sikkerhetsvarsel på vanlig språk eller lage utkast til dokumentasjonen rundt den som et menneske gjennomgår. Regelen er enkel. La bygget lage registreringen, og la modellen lese den.