Hvor AI-sikkerhedsværktøjer kommer til kort, og hvad deterministisk build-dokumentation dækker

Argumentet, snævert formuleret

Dette er ikke et argument imod AI i sikkerhed. Modeller er gode til at læse kode, forklare et fund og foreslå en rettelse, og teams, der bruger dem godt, bevæger sig hurtigere. Argumentet er snævrere: For registreringer, der skal holde senere, er en probabilistisk model den forkerte primære kilde. Det gælder den SBOM, du giver en myndighed, provenance for det artefakt, du leverede, og svaret på "var vi berørt?"

Tre egenskaber afgør, om en registrering holder. Hvert afsnit nedenfor tager én, med eksempler og kilder.

1. Reproducerbarhed: spørg to gange, få samme svar

En sikkerhedsregistrering er kun nyttig, hvis en anden kan få samme svar ud fra samme input. Sprogmodeller lover ikke det, og leverandørerne siger det selv.

• Anthropics dokumentation: "Selv med temperature sat til 0 vil resultaterne ikke være fuldt deterministiske, og identiske input kan give forskelligt output på tværs af API-kald."
• GitHub om Copilot Autofix: "Selv med samme alarm og kode kan den undlade at producere et brugbart forslag, eller forslaget kan variere fra forsøg til forsøg."
• Forskerne bag SecLLMHolmes-frameworket testede otte LLM'er på 228 kodescenarier til IEEE S&P 2024. De rapporterer, at modellerne "giver ikke-deterministiske svar", og at "blot ved at ændre funktions- eller variabelnavne eller ved at tilføje biblioteksfunktioner i kildekoden" gav PaLM2 og GPT-4 forkerte svar i henholdsvis 26 % og 17 % af tilfældene.

Eksempel. To udviklere spørger den samme assistent, om en service er eksponeret for en ny advisory. Den ene får "nej", den anden får "muligvis, tjek det transitive træ". Ingen af svarene er en registrering, og ingen af dem kan reproduceres for en revisor seks måneder senere.

Et registreret build har ikke det problem, fordi intet udledes. CRACI overvåger de pakker, et job henter fra pakkekilderne, mens det kører, og SBOM'en er en registrering af den observation.

2. Revision: vis, hvordan du ved det

Revisioner drejer sig om spørgsmålet "hvordan ved du det?" En model kan give et flydende svar, men dens forklaring er ikke dokumentation. SecLLMHolmes-evalueringen fandt, at LLM'er giver "forkert og uretvisende ræsonnement" om de sårbarheder, de vurderer, så en korrekt konklusion kan komme med en forklaring, der ikke holder.

Standarderne bevæger sig mod registreringer, der forklarer deres egen oprindelse. Minimumselementerne for SBOM fra 2026, udgivet af CISA sammen med NSA, FBI og internationale partnere, tilføjer et SBOM Tool Name, en SBOM Tool Version og en SBOM Generation Context, der angiver, om SBOM'en blev produceret "before build", under "build" eller "after build". Samme dokument advarer om, at "organisationer kan inddrage fejl, hvad enten de stammer fra SBOM-forfatterens praksis eller valget af utilstrækkelige værktøjer, i organisationens beslutninger om risikostyring".

Eksempel. Et kundespørgeskema spørger, hvordan din SBOM blev produceret. "En assistent læste repositoriet og skrev den" giver en generation context, men ikke en, en reviewer kan kontrollere. "Den blev registreret inde i CI-runneren under release-buildet, og jobbets fuldstændighedsstatus er Complete" er noget, revieweren kan verificere op imod buildet.

3. Fuldstændighed: du kan ikke rapportere det, du aldrig så

En model ræsonnerer over det, den får vist. Hvis de filer, den læser, ikke beskriver softwaren, gør svaret det heller ikke, og intet i outputtet siger det. CISA's vejledning fra 2026 sætter barren ved modtagerens beslutning: De "bør kunne konkludere, at en nyligt rapporteret sårbarhed ikke berører dem, hvis SBOM'en ikke angiver komponenten". Det virker kun, hvis fravær på listen betyder fravær i buildet.

Eksempel. Repositoriet anthropics/claude-code i v2.1.259 har intet afhængighedsmanifest eller lockfile af nogen art. Den udgivne npm-pakke deklarerer nul runtime-afhængigheder og pakker en færdigbygget native binærfil ind. Ethvert værktøj, der læser repositoriet, AI eller ej, har næsten intet at angive, mens det program, der kører, er en kompileret binærfil.

Eksempel. AI-kodeværktøjer kan også selv skabe hullet. GitHub advarer om, at Copilot Autofix "kan foreslå opdigtede afhængigheder udgivet under statistisk sandsynlige navne". Et studie fra USENIX Security 2025 af 576.000 genererede kodeeksempler fra 16 modeller fandt en gennemsnitlig andel af hallucinerede pakker på mindst 5,2 % for kommercielle modeller og 21,7 % for open source-modeller, med 205.474 unikke hallucinerede pakkenavne.

Deterministisk er nødvendigt, ikke tilstrækkeligt

En ærlig version af dette argument må tage det næste punkt med. SBOM-generatorer er deterministiske, og de er stadig uenige med hinanden. Peget mod samme commit af expressjs/express kan de returnere forskellige lister, fordi hver af dem selv afgør, hvad der tæller som en komponent, og hvilke filer den stoler på. Repositoriet committer ingen lockfile, så et værktøj, der læser afhængigheder fra en lockfile, har slet ingen af afhængighederne i package.json at rapportere.

En deterministisk scanner reproducerer det samme ufuldstændige svar hver gang. Gentagelighed er nødvendig, men det, der lukker hullet, er observation: at registrere, hvad buildet faktisk hentede, og at sige det, når registreringen er ufuldstændig. CRACI markerer hvert job og hver cache som Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.

Et gennemgået eksempel: afgrænsning af en ny advisory

Et hypotetisk tilfælde: Der udgives en advisory for en version af en udbredt npm-pakke. Under Cyber Resilience Act har producenter 24 timer til at rapportere en aktivt udnyttet sårbarhed til ENISA, så afgrænsningen skal være hurtig og korrekt.

AI først

Du beder en assistent tjekke dine repositories. Den læser manifester og lockfiles og måske en Dockerfile. Den ser ikke pakker gendannet fra en CI-cache, værktøjer downloadet af et build-trin eller versioner fastlagt ved installationen i et repository uden lockfile. Spurgt to gange kan den svare forskelligt. Dens opsummering er nyttig, men du kan ikke underskrive din rapport på baggrund af den.

Registreringen først

CRACI samler sårbarheder på tværs af builds og repositories, afgrænset til default-branchen på organisationsniveau, og genvurderer overvågede SBOM'er, efterhånden som nye sårbarheder dukker op. API'et returnerer hvert builds CycloneDX-SBOM, dets netværkstrace og provenance. Hvis et jobs registrering er ufuldstændig, fortæller dens fuldstændighedsstatus dig, hvor du skal kigge manuelt. Du kan stadig bede en model opsummere resultatet. Den opsummerer en registrering, den genererer ikke en.

Med registreringen er spørgsmålet "hvilke releases leverede denne pakke?" et opslag, ikke en undersøgelse.

Side om side

Brug hvert værktøj, hvor det er stærkt

Brug AI, hvor vurdering hjælper, og et menneske kontrollerer outputtet: kodereview, forklaring af et fund, udkast til en rettelse. Brug deterministiske build-registreringer, hvor outputtet skal kunne reproduceres, revideres eller regnes for komplet: SBOM'er, provenance og afgrænsning af hændelser. CRACI automatiserer en væsentlig del af dokumentationen for forsyningskæden i en bredere CRA-proces. Det gør dig ikke compliant i sig selv.

Læs, hvordan registreringen bliver til, i SBOM-generering under buildet, eller start med hvad CRA kræver.