Hvor AI-sikkerhetsverktøy kommer til kort, og hva deterministisk byggdokumentasjon dekker

Argumentet, snevert formulert

Dette er ikke et argument mot AI i sikkerhetsarbeid. Modeller er gode til å lese kode, forklare et funn og foreslå en rettelse, og team som bruker dem godt, jobber raskere. Argumentet er snevrere: For registreringer som må holde vann senere, er en probabilistisk modell feil primærkilde. Det gjelder SBOM-en du gir en tilsynsmyndighet, provenance for artefakten du leverte, og svaret på «var vi berørt?».

Tre egenskaper avgjør om en registrering holder vann. Hver del nedenfor tar for seg én av dem, med eksempler og kilder.

1. Reproduserbarhet: spør to ganger, få samme svar

En sikkerhetsregistrering er bare nyttig hvis noen andre kan få samme svar fra samme input. Språkmodeller lover ikke det, og leverandørene sier det selv.

• Anthropics dokumentasjon: «Selv med temperature satt til 0 vil resultatene ikke være fullt deterministiske, og identisk input kan gi ulikt output mellom API-kall.»
• GitHub om Copilot Autofix: «Selv med samme varsel og kode kan den mislykkes i å lage et brukbart forslag, eller forslaget kan variere mellom forsøkene.»
• Forskerne bak rammeverket SecLLMHolmes testet åtte LLM-er på 228 kodescenarier for IEEE S&P 2024. De rapporterer at modellene «gir ikke-deterministiske svar», og at «bare ved å endre funksjons- eller variabelnavn, eller ved å legge til biblioteksfunksjoner i kildekoden» ga PaLM2 og GPT-4 feil svar i henholdsvis 26 % og 17 % av tilfellene.

Eksempel. To utviklere spør den samme assistenten om en tjeneste er eksponert for et nytt sikkerhetsvarsel. Den ene får «nei», den andre får «muligens, sjekk det transitive treet». Ingen av svarene er en registrering, og ingen av dem kan reproduseres for en revisor seks måneder senere.

Et registrert bygg har ikke dette problemet, fordi ingenting utledes. CRACI observerer pakkene en jobb henter fra pakkekildene mens den kjører, og SBOM-en er en registrering av den observasjonen.

2. Reviderbarhet: vis hvordan du vet det

Revisjoner dreier seg om spørsmålet «hvordan vet du det?». En modell kan gi et velformulert svar, men forklaringen er ikke dokumentasjon. Evalueringen av SecLLMHolmes fant at LLM-er gir «feilaktig og upålitelig resonnering» om sårbarhetene de vurderer, så en riktig konklusjon kan komme med en forklaring som ikke holder.

Standardene beveger seg mot registreringer som forklarer sin egen opprinnelse. Minimumselementene for SBOM fra 2026, publisert av CISA sammen med NSA, FBI og internasjonale partnere, legger til SBOM Tool Name, SBOM Tool Version og SBOM Generation Context, som angir om SBOM-en ble laget «before build», under «build» eller «after build». Det samme dokumentet advarer om at «organisasjoner kan ta hensyn til feil, enten de skyldes praksisen til SBOM-forfatteren eller valg av utilstrekkelige verktøy, i organisasjonens beslutninger om risikostyring».

Eksempel. Et spørreskjema fra en kunde spør hvordan SBOM-en din ble laget. «En assistent leste repositoriet og skrev den» gir en generation context, men ikke en som en kontrollør kan sjekke. «Den ble registrert i CI-runneren under utgivelsesbygget, og jobbens fullstendighetsstatus er Complete» er noe kontrolløren kan verifisere mot bygget.

3. Fullstendighet: du kan ikke rapportere det du aldri så

En modell resonnerer over det den får se. Hvis filene den leser, ikke beskriver programvaren, gjør ikke svaret det heller, og ingenting i resultatet sier fra om det. CISAs veiledning fra 2026 legger listen ved mottakerens beslutning: De «bør kunne konkludere med at en nylig rapportert sårbarhet ikke berører dem hvis SBOM-en ikke oppfører komponenten». Det fungerer bare hvis fravær i listen betyr fravær i bygget.

Eksempel. Repositoriet anthropics/claude-code i v2.1.259 har ikke noe avhengighetsmanifest eller noen lockfile av noe slag. Den publiserte npm-pakken deklarerer null kjøretidsavhengigheter og pakker inn en ferdigbygd native binærfil. Ethvert verktøy som leser repositoriet, AI eller ikke, har nesten ingenting å liste opp, mens programmet som kjører, er en kompilert binærfil.

Eksempel. AI-kodeverktøy kan også skape gapet selv. GitHub advarer om at Copilot Autofix «kan foreslå oppdiktede avhengigheter publisert under statistisk sannsynlige navn». En studie fra USENIX Security 2025 av 576 000 genererte kodeeksempler fra 16 modeller fant en gjennomsnittlig andel hallusinerte pakker på minst 5,2 % for kommersielle modeller og 21,7 % for modeller med åpen kildekode, med 205 474 unike hallusinerte pakkenavn.

Deterministisk er nødvendig, men ikke tilstrekkelig

En ærlig versjon av dette argumentet må ta med neste poeng. SBOM-generatorer er deterministiske, og likevel er de uenige med hverandre. Rettet mot samme commit av expressjs/express kan de returnere ulike lister, fordi hvert verktøy selv avgjør hva som teller som en komponent, og hvilke filer det skal stole på. Repositoriet har ingen lockfile, så et verktøy som utleder avhengigheter fra en lockfile, har ingen av avhengighetene i package.json å rapportere i det hele tatt.

En deterministisk skanner gjentar det samme ufullstendige svaret hver gang. Repeterbarhet er nødvendig, men det som lukker gapet, er observasjon: å registrere hva bygget faktisk hentet, og å si fra når registreringen er ufullstendig. CRACI merker hver jobb og cache som Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.

Et konkret eksempel: avgrensning av et nytt sikkerhetsvarsel

Et tenkt tilfelle: Et sikkerhetsvarsel publiseres for en versjon av en mye brukt npm-pakke. Etter Cyber Resilience Act har produsenter 24 timer på seg til å rapportere en aktivt utnyttet sårbarhet til ENISA, så avgrensningen må gå raskt og bli riktig.

Veien med AI først

Du ber en assistent sjekke repositoriene dine. Den leser manifester og lockfiler, og kanskje en Dockerfile. Den ser ikke pakker gjenopprettet fra en CI-cache, verktøy lastet ned av et byggesteg eller versjoner som fastsettes ved installasjon i et repositorium uten lockfile. Spør du to ganger, kan den svare ulikt. Sammendraget er nyttig, men du kan ikke signere rapporten din på grunnlag av det.

Veien med registrering først

CRACI samler sårbarheter på tvers av bygg og repositorier, avgrenset til standardgrenen på organisasjonsnivå, og vurderer overvåkede SBOM-er på nytt etter hvert som nye sårbarheter dukker opp. API-et returnerer hvert byggs CycloneDX-SBOM, nettverkssporet og provenance. Er registreringen for en jobb ufullstendig, forteller fullstendighetsstatusen deg hvor du må se manuelt. Du kan fortsatt be en modell oppsummere resultatet. Den oppsummerer da en registrering, den lager ikke en.

Med registreringen er spørsmålet «hvilke utgivelser leverte denne pakken?» et oppslag, ikke en etterforskning.

Side om side

Sett hvert verktøy der det er sterkt

Bruk AI der vurderinger hjelper og et menneske kontrollerer resultatet: kodegjennomgang, forklaring av et funn, utkast til en rettelse. Bruk deterministiske byggregistreringer der resultatet må reproduseres, revideres eller kunne stoles på som fullstendig: SBOM-er, provenance og avgrensning av hendelser. CRACI automatiserer en betydelig del av den dokumentasjonen for leverandørkjeden i en bredere CRA-prosess. Det sikrer ikke alene at du er i samsvar.

Les hvordan registreringen lages i SBOM-generering under bygget, eller start med hva CRA krever.