AI-säkerhetsverktyg läser din kod. Något måste fortfarande registrera ditt bygge.

Ditt team lägger troligen redan till AI i säkerhetsarbetet

De flesta utvecklingsteam har i dag minst ett AI-verktyg i säkerhetsflödet. En modell granskar pull requests. En annan föreslår rättningar för varningar från statisk analys. En tredje sorterar skannerfynd i ”titta på det här” och ”troligen brus”. Verktygen sparar verklig tid, och ingenting på den här sidan argumenterar emot dem.

Den användbara frågan är vilka uppgifter de ska äga och vilka uppgifter som kräver en registrering som blir likadan varje gång. Följdfrågan är vad dina AI-verktyg läser när de gör en bedömning av dina beroenden.

Vad AI-säkerhetsverktyg gör bra

• AI-kodgranskning. GitHub Copilot code review lämnar kommentarer på naturligt språk och kodförslag på pull requests, och kan följa instruktioner som är specifika för ett repo. Det är bra på det läsarbete som en upptagen granskare hoppar över.
• AI-rättningar. GitHub Copilot Autofix ”genererar automatiskt förslag på kodändringar för CodeQL-varningar som hittas i pull requests och på standardgrenen”. En utvecklare får en föreslagen patch bredvid varningen i stället för en länk till en CWE-sida.
• AI-triage. Semgreps AI-funktioner triagerar automatiskt fynd från Semgrep Code och föreslår rättningar. Semgrep dokumenterar sin brusfiltrering som ”över 95 % träffsäker i att klassa fynd från Semgrep Code som falska positiva”.

Lägg märke till mönstret i de två sista. Copilot Autofix arbetar med CodeQL-varningar. Semgreps triage arbetar med fynd från Semgreps regelbaserade motor. AI:n lägger till omdöme ovanpå deterministiska utdata. Den tar inte själv fram de underliggande fynden.

Vad leverantörerna säger om begränsningarna

De tydligaste beskrivningarna av var gränsen går för AI-verktygen kommer från leverantörerna själva, vilket talar till deras fördel.

• Om kodgranskning skriver GitHub att ”Copilot kanske inte identifierar alla problem som finns i koden” och att det ”har en risk för hallucinationer”, det vill säga lyfter fram problem som inte finns.
• Om Autofix skriver GitHub att det ”använder en generativ modell som är icke-deterministisk. Ä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.”
• Också om Autofix: ”Systemet vet inte vilka beroendeversioner som stöds eller är säkra, och kan föreslå påhittade beroenden publicerade under statistiskt sannolika namn.”

Inget av detta gör verktygen mindre användbara. Det definierar deras uppgift: de tar fram förslag som en människa ska kontrollera. Det är en annan uppgift än att ta fram den registrering som människan kontrollerar mot.

Två lager, två uppgifter

CRACI finns i registreringslagret. Det ersätter GitHub Actions-runnern (du ändrar runs-on till craci), och en paketmedveten proxy observerar byggets trafik till paketkällorna medan jobbet körs. Resultatet är en SBOM över vad jobbet faktiskt hämtade, en fullständighetsstatus för varje jobb och cache och en nätverksspårning. API:t returnerar SBOM:er, nätverksspårningar och proveniens.

Där deterministisk insyn behövs

”Är vi berörda?”

När ett nytt säkerhetsmeddelande kommer är den första frågan om något av dina byggen innehöll den berörda versionen. CISA:s minimielement för SBOM:er från 2026 uttrycker kravet rakt ut: mottagaren av en SBOM ”bör kunna dra slutsatsen att en nyligen rapporterad sårbarhet inte påverkar dem om SBOM:en inte listar komponenten”. Den slutsatsen håller bara om listan är komplett. En modell kan hjälpa dig att läsa svaret. Den bör inte vara det som avgör vad som fanns i bygget.

CRACI sammanställer sårbarheter över byggen och repon och omvärderar bevakade SBOM:er när nya sårbarheter publiceras, så frågan besvaras utifrån det som registrerades.

Beroenden som en AI lade till

AI-kodassistenter lägger till beroenden, och forskning visar att de ibland namnger paket som inte finns. En studie som presenterades vid USENIX Security 2025 genererade 576 000 kodexempel med 16 modeller och fann att den genomsnittliga andelen hallucinerade paket var minst 5,2 % för kommersiella modeller och 21,7 % för modeller med öppen källkod. Ett namn som inte finns i dag kan registreras i morgon. Oavsett vem eller vad som lade till ett beroende registrerar CRACI det paket som bygget faktiskt laddade ner, och egress-policyer för nätverket kan begränsa ett jobb till de paketkällor du godkänner.

Revisioner och kundfrågor

En revisor eller en kunds säkerhetsteam kommer att fråga hur du vet vad som levererades. ”Modellen sa det” är ett svagt svar. ”Här är SBOM:en som registrerades under releasebygget, dess fullständighetsstatus och nätverksspårningen för det jobbet” är ett starkt svar. SBOM:er exporteras i CycloneDX eller SPDX, sårbarheter inräknade, och API:t returnerar SBOM:er, nätverksspårningar och proveniens.

Repeterbara svar

Vissa frågor kräver samma svar oavsett vem som frågar eller när. Vilka paket hämtade förra tisdagens release? En generativ modell kan formulera svaret väl, men enligt leverantörerna själva kan den formulera det olika varje gång. Ett registrerat bygge ger ett enda svar.

Hur de två hänger ihop

Mönstret som fungerar är det som Copilot Autofix och Semgrep redan använder: deterministiska data i botten, AI-omdöme ovanpå.

1. Låt AI-kodgranskning och AI-rättningar arbeta med pull requests, med en människa som godkänner varje ändring.
2. Låt CRACI registrera vad varje bygge drog in och ange om registreringen är komplett.
3. När du vill ha AI-hjälp med beroenderisker ger du modellen den registrerade SBOM:en. CRACI:s publika REST API returnerar SBOM:en i CycloneDX, jobbets nätverksspårning och artefaktens proveniens.
4. Spara den registrerade SBOM:en, inte modellens sammanfattning av den, som bevis.

Om ditt team skriver mycket av sin kod med AI-assistenter tar vår sida om säkerhet i AI-driven utveckling upp den situationen, och SBOM-generering under bygget förklarar hur registreringen görs.