Jämförelse
En AI-genererad SBOM är en gissning om ditt bygge. Myndigheter frågar efter en registrering.
Att be en modell skriva en SBOM går snabbt, och resultatet ser rätt ut. Det är inte samma artefakt som en SBOM registrerad under bygget, och skillnaden spelar roll för CRA och CISA:s minimielement från 2026.
Uppdaterad
Varför team provar det
Lockelsen är verklig. Du klistrar in ett repo eller en lockfile i en kodassistent, ber om CycloneDX, och ett välformat dokument kommer tillbaka på några sekunder. Assistenten kan till och med fylla i fält som skannrar brukar lämna tomma. Leverantörsfältet är det vanliga exemplet: de flesta generatorer har ingen källa för det, så det blir tomt. En modell som ombeds skriva ett komplett dokument kan skriva något i varje fält.
Den sista punkten är problemet i miniatyr. En skanner som inte känner till leverantören lämnar fältet tomt. En modell som inte känner till den kan ändå ge ett trovärdigt svar. Dokumentet ser mer komplett ut och är mindre tillförlitligt.
Vad modellen faktiskt ser
En modell som genererar en SBOM arbetar utifrån texten framför sig: manifest, lockfiler, kanske en Dockerfile. Den observerar inte bygget. Därför kan den inte se:
- vilka versioner pakethanteraren valde när ett repo inte har någon committad lockfile,
- paket som återställts från en CI-cache,
- verktyg, OS-paket och binärer som ett byggsteg laddar ner direkt,
- vad som gick in i en kompilerad binär som levereras tillsammans med ett nästan tomt manifest.
Två repon visar hur tunna filerna kan vara. expressjs/express 5.2.1 har ingen committad lockfile, så dess
package.json listar beroenden som versionsintervall och de faktiska versionerna avgörs vid installationen.
Repot anthropics/claude-code i v2.1.259 har inget beroendemanifest eller lockfile av något slag,
och dess publicerade npm-paket deklarerar noll körtidsberoenden samtidigt som det omsluter en förkompilerad native-binär.
En deterministisk skanner som riktas mot det repot har inget att läsa som beskriver binären.
En modell som får samma filer har samma brist på information, och större frihet att fylla luckan.
Hallucination är ett dokumenterat felmönster
Språkmodeller namnger paket som inte finns. Det bäst uppmätta fallet gäller kodgenerering snarare än SBOM-skrivande, men felet det visar gäller lika väl för en lista över komponenter. En studie från USENIX Security 2025 genererade 576 000 kodexempel med 16 modeller och fann en genomsnittlig andel hallucinerade paket på minst 5,2 % för kommersiella modeller och 21,7 % för modeller med öppen källkod, med 205 474 unika hallucinerade paketnamn. GitHubs egen dokumentation för Copilot Autofix varnar för att det "may suggest fabricated dependencies published under statistically probable names."
Modeller ger inte heller samma svar två gånger. Anthropics dokumentation slår fast att "even with temperature set to 0, the results will not be fully deterministic and identical inputs may produce different outputs across API calls." Två SBOM:er genererade från samma commit kan skilja sig åt, och ingen av dem säger vilken som är rätt.
I en SBOM är en hallucinerad post inget ofarligt stavfel. Ett paket som inte finns, eller fel version av ett som finns, skickar en sårbarhetssökning till fel ställe, och resultatet som kommer tillbaka är tvärsäkert och felaktigt.
Vad standarderna förväntar sig att en SBOM innehåller
NTIA:s minimielement (2021)
NTIA:s baslinje definierade sju datafält: leverantörens namn, komponentens namn, komponentens version, andra unika identifierare, beroenderelation, författare till SBOM-data och tidsstämpel. Den kombinerade dem med stöd för automatisering och en uppsättning arbetssätt och processer. Varje fält beskriver ett faktum om programvaran, inte en åsikt om den.
CISA:s minimielement 2026
Den 29 juli 2026 publicerade CISA, NSA, FBI och internationella partner uppdaterade minimielement som ersätter baslinjen från 2021. Flera tillägg är svåra att uppfylla utan att observera 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," och "after build" som exempel. En modell som läser ett repo befinner sig i bästa fall före bygget.
- Component Hash Value: "the output generated from applying a cryptographic hash algorithm to an executable component artifact." Om författaren inte har artefakten gäller att "the SBOM author should indicate the value is unknown." En modell som aldrig rörde artefakten kan inte ta fram en hash, bara text som ser ut som en.
- SBOM Tool Name and Version: verktyget som användes för att generera SBOM:en måste namnges.
- 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: författaren "should explicitly state whether the information is unknown." Ett påhittat värde är raka motsatsen.
EU:s Cyber Resilience Act
CRA gör SBOM:en till en rättslig skyldighet för tillverkare av produkter med digitala element. Bilaga I, del II kräver att de identifierar och dokumenterar sårbarheter och komponenter i produkterna, bland annat genom att upprätta en programvaruförteckning i ett vanligt förekommande och maskinläsbart format som åtminstone omfattar produktens beroenden på högsta nivå. Bilaga VII placerar SBOM:en i den tekniska dokumentationen, och en marknadskontrollmyndighet kan begära den för att kontrollera att de väsentliga kraven uppfylls.
Ingen av dessa texter förbjuder AI-verktyg. Det de frågar efter är data som beskriver den faktiska produkten, och ärliga besked om vad som är okänt. En SBOM skriven utifrån slutsatser har svårt med båda.
| Funktion | CRACI | AI-genererad SBOM |
|---|---|---|
| Observerar bygget | Pakettrafik registrerad under jobbet, plus CI-cachar | Arbetar utifrån filerna och texten den fick |
| Genereringskontext | Bygge (registrerat medan jobbet kördes) | I bästa fall före bygget: modellen såg aldrig bygget |
| Fastställda versioner | Det som installationen faktiskt hämtade | Från en lockfile, eller gissat från ett intervall |
| Okända uppgifter anges | Fem fullständighetsstatusar per jobb och per cache | Luckor och påhitt ser ut som giltiga poster |
| Samma indata, samma utdata | Samma registrering varje gång | Utdata kan skilja sig mellan körningar |
| Fungerar utan att köra ett bygge | Registrerar byggen på CRACI-runners | På några sekunder från inklistrade filer |
| Fungerar utanför GitHub Actions | GitHub Actions i dag; GitLab CI och Jenkins på roadmapen | Valfritt repo eller lockfile |
- Ingår
- Delvis
- Ingår inte
- På roadmapen
Så tar CRACI fram SBOM:en
CRACI kör dina GitHub Actions-jobb på sina egna runners. Du ändrar runs-on till craci, och
körningarna syns fortfarande i GitHub. Medan jobbet körs observerar en paketmedveten proxy trafik till paketkällor, så att
SBOM:en registrerar vad bygget faktiskt hämtade, inklusive transitiva beroenden. Beroendebevisen följer med CI-cachar,
så ett paket som återställs från en cache finns kvar i registreringen.
- Ekosystem: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk och Git-källor, plus nedladdningsförinställningar.
- Fullständighet: varje jobb och cache markeras som Complete, Complete with connections, Incomplete, Unavailable eller Not recorded, så okända uppgifter anges i stället för att fyllas i.
- Format: CycloneDX och SPDX, med deklarerade licensmetadata i exporten.
- Proveniens: API:t returnerar SBOM:er, nätverksspårningar och proveniens.
CRACI automatiserar en betydande del av den insyn i leveranskedjan och de bevis som ett bredare arbete med CRA-efterlevnad behöver. Det gör inte en produkt regelefterlevande på egen hand. SBOM-generering under bygget tar upp detaljerna, och vår översikt över CRA tar upp tidslinjen.
Där AI faktiskt hjälper med SBOM:er
När du väl har en registrerad SBOM är en modell bra på att arbeta med den: sammanfatta vilka komponenter som bär risk, förklara ett säkerhetsmeddelande på vanligt språk eller skriva utkast till dokumentationen runt den, som en människa sedan granskar. Regeln är enkel. Låt bygget ta fram registreringen, och låt modellen läsa den.
Se SBOM:en som ditt bygge faktiskt ger
Boka en demo så registrerar vi en SBOM för ett av dina byggen, med dess fullständighetsstatus och proveniens.
Boka en demo