AI-sikkerhedsværktøjer læser din kode. Noget skal stadig registrere dit build.

Dit team er sandsynligvis allerede ved at tilføje AI til sikkerheden

De fleste udviklingsteams har nu mindst ét AI-værktøj i sikkerhedsprocessen. En model gennemgår pull requests. En anden foreslår rettelser til alarmer fra statisk analyse. En tredje sorterer scannerfund i "kig på det her" og "sandsynligvis støj". Værktøjerne sparer reel tid, og intet på denne side argumenterer imod dem.

Det nyttige spørgsmål er, hvilke opgaver de skal eje, og hvilke opgaver der kræver en registrering, der giver samme resultat hver gang. Det tilhørende spørgsmål er, hvad dine AI-værktøjer læser, når de træffer en beslutning om dine afhængigheder.

Hvad AI-sikkerhedsværktøjer gør godt

• AI-kodereview. GitHub Copilot code review skriver kommentarer i naturligt sprog og kodeforslag på pull requests og kan følge repository-specifikke instruktioner. Det er godt til det læsearbejde, en travl reviewer springer over.
• AI-rettelser. GitHub Copilot Autofix "genererer automatisk forslag til kodeændringer for CodeQL-alarmer, der findes i pull requests og på default-branchen". En udvikler får en foreslået patch ved siden af alarmen i stedet for et link til en CWE-side.
• AI-triage. Semgreps AI-funktioner autotriagerer fund fra Semgrep Code og foreslår rettelser. Semgrep dokumenterer sin støjfiltrering som "over 95 % præcis i at kategorisere Semgrep Code-fund som falske positiver".

Læg mærke til mønsteret i de to sidste. Copilot Autofix arbejder på CodeQL-alarmer. Semgreps triage arbejder på fund fra Semgreps regelbaserede motor. AI'en lægger vurdering oven på deterministisk output. Den producerer ikke selv de underliggende fund.

Hvad leverandørerne selv siger om begrænsningerne

De klareste beskrivelser af, hvor AI-værktøjer stopper, kommer fra leverandørerne selv, hvilket taler til deres fordel.

• Om kodereview skriver GitHub, at "Copilot muligvis ikke identificerer alle de problemer, der findes i koden", og at det "har en risiko for hallucination", hvor det fremhæver problemer, der ikke findes.
• Om Autofix skriver GitHub, at det "bruger en generativ model, der er ikke-deterministisk. Selv med samme alarm og kode kan den undlade at producere et brugbart forslag, eller forslaget kan variere fra forsøg til forsøg."
• Også om Autofix: "Systemet ved ikke, hvilke afhængighedsversioner der er understøttede eller sikre, og kan foreslå opdigtede afhængigheder udgivet under statistisk sandsynlige navne."

Intet af dette gør værktøjerne mindre nyttige. Det definerer deres opgave: De producerer forslag, som et menneske skal kontrollere. Det er en anden opgave end at producere den registrering, mennesket kontrollerer op imod.

To lag, to opgaver

CRACI ligger i registreringslaget. Det erstatter GitHub Actions-runneren (du ændrer runs-on til craci), og en pakkebevidst proxy overvåger buildets trafik til pakkekilderne, mens jobbet kører. Resultatet er en SBOM over det, jobbet faktisk hentede, en fuldstændighedsstatus for hvert job og hver cache og et netværkstrace. API'et returnerer SBOM'er, netværkstraces og provenance.

Hvor der er brug for deterministisk indsigt

"Er vi berørt?"

Når en ny advisory lander, er det første spørgsmål, om nogen af dine builds indeholdt den berørte version. CISA's minimumselementer for SBOM fra 2026 formulerer kravet klart: Modtageren af en SBOM "bør kunne konkludere, at en nyligt rapporteret sårbarhed ikke berører dem, hvis SBOM'en ikke angiver komponenten". Den konklusion holder kun, hvis listen er komplet. En model kan hjælpe dig med at læse svaret. Den bør ikke være det, der afgør, hvad der var i buildet.

CRACI samler sårbarheder på tværs af builds og repositories og genvurderer overvågede SBOM'er, efterhånden som nye sårbarheder offentliggøres, så spørgsmålet besvares ud fra det, der blev registreret.

Afhængigheder, som en AI har tilføjet

AI-kodeassistenter tilføjer afhængigheder, og forskning viser, at de nogle gange navngiver pakker, der ikke findes. Et studie præsenteret på USENIX Security 2025 genererede 576.000 kodeeksempler med 16 modeller og fandt, at den gennemsnitlige andel af hallucinerede pakker var mindst 5,2 % for kommercielle modeller og 21,7 % for open source-modeller. Et navn, der ikke findes i dag, kan blive registreret i morgen. Uanset hvem eller hvad der tilføjede en afhængighed, registrerer CRACI den pakke, buildet faktisk downloadede, og egress-politikker for netværket kan begrænse et job til de pakkekilder, du godkender.

Revisioner og spørgsmål fra kunder

En revisor eller en kundes sikkerhedsteam vil spørge, hvordan du ved, hvad der blev leveret. "Det sagde modellen" er et svagt svar. "Her er den SBOM, der blev registreret under release-buildet, dens fuldstændighedsstatus og netværkstracet for det job" er et stærkt svar. SBOM'er eksporteres som CycloneDX eller SPDX, inklusive sårbarheder, og API'et returnerer SBOM'er, netværkstraces og provenance.

Reproducerbare svar

Nogle spørgsmål kræver det samme svar, uanset hvem der spørger, eller hvornår. Hvilke pakker hentede sidste tirsdags release? En generativ model kan formulere det svar godt, men efter leverandørernes egen beskrivelse kan den formulere det forskelligt hver gang. Et registreret build giver ét svar.

Sådan passer de to sammen

Det mønster, der virker, er det, Copilot Autofix og Semgrep allerede bruger: deterministiske data nederst, AI-vurdering ovenpå.

1. Lad AI-kodereview og AI-rettelser arbejde på pull requests, med et menneske, der godkender hver ændring.
2. Lad CRACI registrere, hvad hvert build hentede, og angive, om registreringen er komplet.
3. Når du vil have AI-hjælp til afhængighedsrisiko, så giv modellen den registrerede SBOM. CRACI's offentlige REST API returnerer SBOM'en som CycloneDX, jobbets netværkstrace og artefaktets provenance.
4. Behold den registrerede SBOM, ikke modellens opsummering af den, som dokumentation.

Skriver dit team meget af sin kode med AI-assistenter, dækker vores side om sikkerhed i AI-udvikling den situation, og SBOM-generering under buildet forklarer, hvordan registreringen bliver til.