En AI-genereret SBOM er et gæt om dit build. Myndighederne beder om en registrering.

Hvorfor teams prøver det

Tiltrækningen er reel. Du indsætter et repository eller en lockfile i en kodeassistent, beder om CycloneDX, og et velformet dokument kommer tilbage på få sekunder. Det kan endda udfylde felter, som scannere ofte lader stå tomme. Leverandørfeltet er det sædvanlige eksempel: De fleste generatorer har ingen kilde til det, så det ender tomt. En model, der bliver bedt om et komplet dokument, kan skrive noget i hvert felt.

Det sidste punkt er problemet i miniature. En scanner, der ikke kender leverandøren, lader feltet stå tomt. En model, der ikke kender den, kan alligevel producere et plausibelt svar. Dokumentet ser mere komplet ud og er mindre pålideligt.

Hvad modellen faktisk ser

En model, der genererer en SBOM, arbejder ud fra teksten foran den: manifester, lockfiles, måske en Dockerfile. Den observerer ikke buildet. Så den kan ikke se:

• hvilke versioner pakkehåndteringen valgte, når et repository ikke committer en lockfile,
• pakker gendannet fra en CI-cache,
• værktøjer, OS-pakker og binærfiler, som et build-trin downloader direkte,
• hvad der gik ind i en kompileret binærfil, der leveres sammen med et næsten tomt manifest.

To repositories viser, hvor tynde filerne kan være. expressjs/express 5.2.1 committer ingen lockfile, så dens package.json angiver afhængigheder som versionsintervaller, og de faktiske versioner afgøres ved installationen. Repositoriet anthropics/claude-code på v2.1.259 har hverken afhængighedsmanifest eller lockfile af nogen art, og dets offentliggjorte npm-pakke deklarerer nul runtime-afhængigheder, mens den pakker en færdigbygget native binærfil ind. En deterministisk scanner, der peges mod det repository, har intet at læse, der beskriver binærfilen. En model, der får de samme filer, mangler de samme oplysninger og har større frihed til at udfylde hullet.

Hallucination er en dokumenteret fejltype

Sprogmodeller navngiver pakker, der ikke findes. Det bedst målte tilfælde er kodegenerering snarere end SBOM-skrivning, men den fejl, det viser, gælder lige så godt for en liste over komponenter. Et studie fra USENIX Security 2025 genererede 576.000 kodeeksempler med 16 modeller og fandt en gennemsnitlig andel af hallucinerede pakker på mindst 5,2 % for kommercielle modeller og 21,7 % for open source-modeller, med 205.474 unikke hallucinerede pakkenavne. GitHubs egen dokumentation for Copilot Autofix advarer om, at det "may suggest fabricated dependencies published under statistically probable names."

Modeller giver heller ikke det samme svar to gange. Anthropics dokumentation siger, 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 genereret ud fra samme commit kan være forskellige, og ingen af dem siger, hvilken der er rigtig.

I en SBOM er en hallucineret post ikke en harmløs slåfejl. En pakke, der ikke findes, eller den forkerte version af en, der gør, sender et sårbarhedsopslag det forkerte sted hen, og resultatet kommer tilbage selvsikkert og forkert.

Hvad standarderne forventer, at en SBOM indeholder

NTIA's minimumselementer (2021)

NTIA's grundlinje definerede syv datafelter: leverandørnavn, komponentnavn, komponentens version, andre unikke identifikatorer, afhængighedsrelation, forfatter af SBOM-data og tidsstempel. Den kombinerede dem med understøttelse af automatisering og et sæt praksisser og processer. Hvert felt beskriver en kendsgerning om softwaren, ikke en holdning til den.

CISA's minimumselementer fra 2026

Den 29. juli 2026 offentliggjorde CISA, NSA, FBI og internationale partnere opdaterede minimumselementer, der erstatter grundlinjen fra 2021. Flere af tilføjelserne er svære at opfylde uden at observere buildet:

• 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 model, der læser et repository, er i bedste fald før build.
• Component Hash Value: "the output generated from applying a cryptographic hash algorithm to an executable component artifact." Har forfatteren ikke artefaktet, "the SBOM author should indicate the value is unknown." En model, der aldrig har rørt artefaktet, kan ikke producere et hash, kun tekst formet som et.
• SBOM Tool Name and Version: Det værktøj, der blev brugt til at generere SBOM'en, skal navngives.
• 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 opdigtet værdi er det modsatte af det.

EU's Cyber Resilience Act

CRA gør SBOM'en til en lovmæssig forpligtelse for producenter af produkter med digitale elementer. Bilag I, del II kræver, at de identificerer og dokumenterer sårbarheder og komponenter i produkter med digitale elementer, blandt andet ved at udarbejde en softwarestykliste i et almindeligt anvendt og maskinlæsbart format, der som minimum dækker produkternes afhængigheder på øverste niveau. Bilag VII placerer SBOM'en i den tekniske dokumentation, og en markedsovervågningsmyndighed kan anmode om den for at kontrollere overholdelsen af de væsentlige krav.

Ingen af disse tekster forbyder AI-værktøjer. Det, de beder om, er data, der beskriver det faktiske produkt, og ærlige angivelser af, hvad der er ukendt. En SBOM skrevet ud fra slutninger har svært ved begge dele.

Sådan producerer CRACI SBOM'en

CRACI kører dine GitHub Actions-jobs på sine egne runnere. Du ændrer runs-on til craci, og kørsler vises stadig i GitHub. Mens jobbet kører, observerer en pakkebevidst proxy trafikken til pakkekilder, så SBOM'en registrerer, hvad buildet faktisk hentede, inklusive transitive afhængigheder. Dokumentationen for afhængighederne følger med CI-caches, så en pakke gendannet fra en cache forbliver i registreringen.

• Økosystemer: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets.
• Fuldstændighed: Hvert job og hver cache markeres som Complete, Complete with connections, Incomplete, Unavailable eller Not recorded, så det ukendte angives i stedet for at blive udfyldt.
• Formater: CycloneDX og SPDX, med deklarerede licensmetadata inkluderet i eksporten.
• Provenance: API'et returnerer SBOM'er, netværkstraces og provenance.

CRACI automatiserer en væsentlig del af den indsigt i og dokumentation for forsyningskæden, som en bredere CRA-compliance-proces har brug for. Det gør ikke alene et produkt compliant. SBOM-generering under buildet dækker detaljerne, og vores CRA-overblik dækker tidslinjen.

Hvor AI faktisk hjælper med SBOM'er

Når du har en registreret SBOM, er en model god til at arbejde med den: at opsummere, hvilke komponenter der bærer risiko, forklare en advisory i et enkelt sprog eller udarbejde udkast til dokumentationen omkring den, som et menneske kan gennemgå. Reglen er enkel. Lad buildet producere registreringen, og lad modellen læse den.