AI-sikkerhetsverktøy leser koden din. Noe må fortsatt registrere bygget ditt.

Teamet ditt legger trolig allerede AI inn i sikkerhetsarbeidet

De fleste utviklingsteam har nå minst ett AI-verktøy i sikkerhetsarbeidet. En modell gjennomgår pull requests. En annen foreslår rettelser for varsler fra statisk analyse. En tredje sorterer skannerfunn i «se på dette» og «trolig støy». Disse verktøyene sparer reell tid, og ingenting på denne siden argumenterer mot dem.

Det nyttige spørsmålet er hvilke oppgaver de bør eie, og hvilke oppgaver som trenger en registrering som blir lik hver gang. Det tilhørende spørsmålet er hva AI-verktøyene dine leser når de tar en avgjørelse om avhengighetene dine.

Hva AI-sikkerhetsverktøy gjør bra

• AI-kodegjennomgang. GitHub Copilot code review legger igjen kommentarer på naturlig språk og kodeforslag på pull requests, og kan følge instruksjoner for det enkelte repositoriet. Det er godt til lesearbeidet en travel reviewer hopper over.
• AI-rettelser. GitHub Copilot Autofix «genererer automatisk forslag til kodeendringer for CodeQL-varsler som finnes i pull requests og på standardgrenen». En utvikler får en foreslått patch ved siden av varselet i stedet for en lenke til en CWE-side.
• AI-prioritering. Semgreps AI-funksjoner prioriterer funn fra Semgrep Code automatisk og foreslår rettelser. Semgrep dokumenterer støyfiltreringen sin som «over 95 % nøyaktig i å kategorisere Semgrep Code-funn som falske positiver».

Legg merke til mønsteret i de to siste. Copilot Autofix jobber med CodeQL-varsler. Semgreps prioritering jobber med funn fra Semgreps regelbaserte motor. AI-en legger vurderinger på toppen av deterministisk output. Den produserer ikke de underliggende funnene selv.

Hva leverandørene sier om begrensningene

De tydeligste beskrivelsene av hvor AI-verktøy stopper, kommer fra leverandørene selv, noe de skal ha ros for.

• Om kodegjennomgang skriver GitHub at «Copilot kanskje ikke identifiserer alle problemene som finnes i koden», og at den «har en risiko for hallusinering», der den fremhever problemer som ikke finnes.
• Om Autofix skriver GitHub at den «bruker en generativ modell som er ikke-deterministisk. Selv med samme varsel og kode kan den mislykkes i å lage et brukbart forslag, eller forslaget kan variere mellom forsøkene».
• Også om Autofix: «Systemet vet ikke hvilke versjoner av avhengigheter som er støttet eller sikre, og kan foreslå oppdiktede avhengigheter publisert under statistisk sannsynlige navn.»

Ingenting av dette gjør verktøyene mindre nyttige. Det definerer jobben deres: De lager forslag som en person skal kontrollere. Det er en annen jobb enn å lage registreringen personen kontrollerer mot.

To lag, to jobber

CRACI ligger i registreringslaget. Det erstatter GitHub Actions-runneren (du endrer runs-on til craci), og en pakkebevisst proxy observerer byggets trafikk til pakkekildene mens jobben kjører. Resultatet er en SBOM over hva jobben faktisk hentet, en fullstendighetsstatus for hver jobb og cache, og et nettverksspor. API-et returnerer SBOM-er, nettverksspor og provenance.

Der deterministisk innsikt trengs

«Er vi berørt?»

Når et nytt sikkerhetsvarsel kommer, er det første spørsmålet om noen av byggene dine inneholdt den berørte versjonen. CISAs minimumselementer for SBOM fra 2026 sier kravet rett ut: Mottakeren av en SBOM «bør kunne konkludere med at en nylig rapportert sårbarhet ikke berører dem hvis SBOM-en ikke oppfører komponenten». Den konklusjonen holder bare hvis listen er fullstendig. En modell kan hjelpe deg med å lese svaret. Den bør ikke være det som avgjør hva som var i bygget.

CRACI samler sårbarheter på tvers av bygg og repositorier og vurderer overvåkede SBOM-er på nytt etter hvert som nye sårbarheter publiseres, så spørsmålet besvares ut fra det som ble registrert.

Avhengigheter som en AI la til

AI-kodeassistenter legger til avhengigheter, og forskning viser at de noen ganger navngir pakker som ikke finnes. En studie presentert på USENIX Security 2025 genererte 576 000 kodeeksempler med 16 modeller og fant at den gjennomsnittlige andelen hallusinerte pakker var minst 5,2 % for kommersielle modeller og 21,7 % for modeller med åpen kildekode. Et navn som ikke finnes i dag, kan registreres i morgen. Uansett hvem eller hva som la til en avhengighet, registrerer CRACI pakken bygget faktisk lastet ned, og egress-policyer for nettverket kan begrense en jobb til pakkekildene du godkjenner.

Revisjoner og spørsmål fra kunder

En revisor eller sikkerhetsteamet hos en kunde vil spørre hvordan du vet hva som ble levert. «Modellen sa det» er et svakt svar. «Her er SBOM-en registrert under utgivelsesbygget, fullstendighetsstatusen dens og nettverkssporet fra den jobben» er et sterkt svar. SBOM-er eksporteres som CycloneDX eller SPDX, sårbarheter inkludert, og API-et returnerer SBOM-er, nettverksspor og provenance.

Repeterbare svar

Noen spørsmål trenger samme svar uansett hvem som spør eller når. Hvilke pakker hentet utgivelsen fra sist tirsdag? En generativ modell kan formulere det svaret godt, men etter leverandørenes egen beskrivelse kan den formulere det ulikt hver gang. Et registrert bygg gir ett svar.

Hvordan de to passer sammen

Mønsteret som fungerer, er det Copilot Autofix og Semgrep allerede bruker: deterministiske data i bunnen, AI-vurderinger på toppen.

1. La AI-kodegjennomgang og AI-rettelser jobbe med pull requests, med et menneske som godkjenner hver endring.
2. La CRACI registrere hva hvert bygg hentet inn, og angi om registreringen er fullstendig.
3. Når du vil ha AI-hjelp med avhengighetsrisiko, gir du modellen den registrerte SBOM-en. CRACIs offentlige REST-API returnerer SBOM-en som CycloneDX, jobbens nettverksspor og artefaktens provenance.
4. Behold den registrerte SBOM-en, ikke modellens sammendrag av den, som dokumentasjon.

Skriver teamet ditt mye av koden sin med AI-assistenter, dekker siden vår om sikkerhet i AI-utvikling den situasjonen, og SBOM-generering under bygget forklarer hvordan registreringen lages.