Där AI-säkerhetsverktyg brister, och vad deterministiska bevis från bygget täcker

Argumentet, snävt formulerat

Det här är inget argument mot AI i säkerhetsarbetet. Modeller är bra på att läsa kod, förklara ett fynd och föreslå en rättning, och team som använder dem väl arbetar snabbare. Argumentet är snävare: för registreringar som ska hålla i efterhand är en probabilistisk modell fel primärkälla. Det gäller SBOM:en du lämnar till en tillsynsmyndighet, proveniensen för den artefakt du levererade och svaret på frågan ”var vi drabbade?”

Tre egenskaper avgör om en registrering håller. Varje avsnitt nedan tar upp en av dem, med exempel och källor.

1. Reproducerbarhet: fråga två gånger, få samma svar

En säkerhetsregistrering är bara användbar om någon annan kan få samma svar från samma indata. Språkmodeller lovar inte det, och leverantörerna säger det själva.

• Anthropics dokumentation: ”Även med temperaturen satt till 0 blir resultaten inte helt deterministiska, och identiska indata kan ge olika utdata mellan API-anrop.”
• GitHub om Copilot Autofix: ”Även med samma varning och samma kod kan den misslyckas med att ta fram ett användbart förslag, eller så kan förslaget variera mellan försöken.”
• Forskarna som byggde ramverket SecLLMHolmes testade åtta LLM:er på 228 kodscenarier för IEEE S&P 2024. De rapporterar att modellerna ”ger icke-deterministiska svar” och att ”bara genom att byta namn på funktioner eller variabler, eller genom att lägga till biblioteksfunktioner i källkoden” gav PaLM2 och GPT-4 felaktiga svar i 26 % respektive 17 % av fallen.

Exempel. Två utvecklare frågar samma assistent om en tjänst är exponerad för ett nytt säkerhetsmeddelande. Den ena får ”nej”, den andra får ”möjligen, kontrollera det transitiva trädet”. Inget av svaren är en registrering, och inget av dem kan reproduceras för en revisor sex månader senare.

Ett registrerat bygge har inte det problemet, eftersom ingenting härleds. CRACI observerar de paket som ett jobb hämtar från paketkällorna medan det körs, och SBOM:en är en registrering av den observationen.

2. Granskningsbarhet: visa hur du vet

Revisioner kretsar kring frågan ”hur vet ni det?” En modell kan ge ett välformulerat svar, men dess förklaring är inget bevis. Utvärderingen av SecLLMHolmes visade att LLM:er ger ”felaktiga och opålitliga resonemang” om de sårbarheter de bedömer, så en korrekt slutsats kan komma med en förklaring som inte håller.

Standarderna rör sig mot registreringar som förklarar sitt eget ursprung. Minimielementen för SBOM:er från 2026, publicerade av CISA tillsammans med NSA, FBI och internationella partner, lägger till SBOM Tool Name, SBOM Tool Version och SBOM Generation Context, som anger om SBOM:en togs fram ”före bygget”, under ”bygget” eller ”efter bygget”. Samma dokument varnar för att ”organisationer kan beakta fel, oavsett om de beror på SBOM-författarens arbetssätt eller val av otillräckliga verktyg, i organisationens beslut om riskhantering”.

Exempel. Ett kundformulär frågar hur din SBOM togs fram. ”En assistent läste repositoryt och skrev den” ger en genereringskontext, men inte en som en granskare kan kontrollera. ”Den registrerades i CI-runnern under releasebygget, och jobbets fullständighetsstatus är Complete” är något som granskaren kan verifiera mot bygget.

3. Fullständighet: du kan inte rapportera det du aldrig såg

En modell resonerar utifrån det den får se. Om filerna den läser inte beskriver programvaran gör svaret det inte heller, och ingenting i utdata säger det. CISA:s vägledning från 2026 sätter ribban vid mottagarens beslut: de ”bör kunna dra slutsatsen att en nyligen rapporterad sårbarhet inte påverkar dem om SBOM:en inte listar komponenten”. Det fungerar bara om frånvaro i listan innebär frånvaro i bygget.

Exempel. Repositoryt anthropics/claude-code i v2.1.259 har inget beroendemanifest och ingen lockfile av något slag. Det publicerade npm-paketet deklarerar noll beroenden vid körning och kapslar in en förkompilerad native-binär. Ett verktyg som läser repositoryt, AI eller annat, har nästan ingenting att lista, medan programmet som körs är en kompilerad binär.

Exempel. AI-kodverktyg kan också själva skapa luckan. GitHub varnar för att Copilot Autofix ”kan föreslå påhittade beroenden publicerade under statistiskt sannolika namn”. En studie från USENIX Security 2025 av 576 000 genererade kodexempel från 16 modeller 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.

Deterministiskt är nödvändigt, men inte tillräckligt

En ärlig version av det här argumentet måste ta med nästa punkt. SBOM-generatorer är deterministiska, och de är ändå oense med varandra. Riktade mot samma commit av expressjs/express kan de returnera olika listor, eftersom var och en själv avgör vad som räknas som en komponent och vilka filer den ska lita på. Repositoryt checkar inte in någon lockfile, så ett verktyg som fastställer beroenden utifrån en sådan har inget av beroendena i package.json att rapportera alls.

En deterministisk skanner reproducerar samma ofullständiga svar varje gång. Repeterbarhet är nödvändig, men det som täpper till luckan är observation: att registrera vad bygget faktiskt hämtade och säga när registreringen är ofullständig. CRACI markerar varje jobb och cache som Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.

Ett genomarbetat exempel: att avgränsa ett nytt säkerhetsmeddelande

Ett hypotetiskt fall: ett säkerhetsmeddelande publiceras för en version av ett mycket använt npm-paket. Enligt Cyber Resilience Act har tillverkare 24 timmar på sig att rapportera en aktivt utnyttjad sårbarhet till ENISA, så avgränsningen måste gå snabbt och bli rätt.

Vägen där AI kommer först

Du ber en assistent att kontrollera dina repon. Den läser manifest och lockfiler, och kanske en Dockerfile. Den ser inte paket som återställs från en CI-cache, verktyg som ett byggsteg laddar ner eller versioner som fastställs vid installationen i ett repository utan lockfile. Frågar du två gånger kan den svara olika. Sammanfattningen är användbar, men du kan inte skriva under din rapport med den som grund.

Vägen där registreringen kommer först

CRACI sammanställer sårbarheter över byggen och repon, avgränsat till standardgrenen på organisationsnivå, och omvärderar bevakade SBOM:er när nya sårbarheter dyker upp. API:t returnerar varje bygges SBOM i CycloneDX, dess nätverksspårning och proveniens. Om ett jobbs registrering är ofullständig visar dess fullständighetsstatus var du behöver titta manuellt. Du kan fortfarande be en modell sammanfatta resultatet. Den sammanfattar då en registrering, den genererar ingen.

Med registreringen blir frågan ”vilka releaser levererades med det här paketet?” en uppslagning, inte en utredning.

Sida vid sida

Använd varje verktyg där det är starkt

Använd AI där omdöme hjälper och en människa kontrollerar resultatet: kodgranskning, förklaring av ett fynd, utkast till en rättning. Använd deterministiska byggregistreringar där resultatet måste kunna reproduceras, granskas eller betraktas som komplett: SBOM:er, proveniens och avgränsning av incidenter. CRACI automatiserar en betydande del av de här bevisen för leveranskedjan för ett bredare CRA-arbete. Det gör dig inte regelefterlevande på egen hand.

Läs hur registreringen görs i SBOM-generering under bygget, eller börja med vad CRA kräver.