AI-afhjælpning af sårbarheder: hvad pull requests med AI-rettelser kan

Hvad AI-afhjælpning er

AI-afhjælpning af sårbarheder bruger en sprogmodel til at lave rettelsen af en kendt sårbarhed. Den findes i tre former:

• Forslag til koderettelser. En model foreslår en patch ved siden af en alert fra statisk analyse. GitHub Copilot Autofix "genererer for eksempel automatisk forslag til kodeændringer for CodeQL-alerts, der findes i pull requests og på standardbranchen."
• Opgraderinger af afhængigheder, der tilpasser koden. Det er let at hæve en version. Det svære er den omdøbte funktion eller den ændrede standardværdi, som den nye version medfører. En model kan lave de efterfølgende ændringer i den samme pull request.
• Agentisk afhjælpning. En agent fører selv rettelsen gennem flere trin: ændrer koden, kører buildet og testene, læser fejlene, prøver igen og åbner først en pull request, når tjekkene består.

Hvor AI-rettelser betaler sig

Regelbaserede opdateringsbots åbner allerede pull requests, der hæver en sårbar pakke til en rettet version. De går i stå, når opgraderingen ødelægger noget, for at tilpasse den kaldende kode er ikke en regel. Det er dér, efterslæbet hober sig op: sikkerhedsopdateringen, der står åben i månedsvis, fordi ingen har tid til at arbejde sig gennem skiftet til en ny hovedversion.

At læse en changelog, finde kaldestederne og omskrive dem er den slags arbejde, sprogmodeller er gode til. En AI-rettelse, der kommer med opgraderingen og kodeændringerne, bygget og testet, forvandler en uges opmærksomhed fra en kollega til en gennemgang.

Hvor AI-rettelser går galt

De klareste beskrivelser af begrænsningerne kommer fra leverandørerne selv. Om Copilot Autofix skriver GitHub:

• Den "bruger en generativ model, der er ikke-deterministisk. Selv med den samme alert og kode kan den undlade at levere et brugbart forslag, eller forslaget kan variere fra forsøg til forsøg."
• "Systemet ved ikke, hvilke versioner af afhængigheder der understøttes eller er sikre, og kan foreslå opdigtede afhængigheder udgivet under statistisk sandsynlige navne."

Det andet punkt er ikke hypotetisk. Forskning i kodegenererende modeller har målt, hvor ofte de anbefaler pakker, der ikke findes – navne, som en angriber kan registrere og fylde med malware. En rettelse, der installerer en hallucineret pakke, erstatter én sårbarhed med en værre.

Tre sikkerhedsforanstaltninger dækker det meste af risikoen:

1. Byg og test hver rettelse, før et menneske gennemgår den, så tiden til gennemgang går til rettelser, der virker.
2. Tjek hver tilføjet eller ændret pakke mod registryet og den version, du forventer.
3. Lad et menneske stå for merge. En AI-rettelse er en bidragyders pull request, ikke en beslutning.

Skrald ind, pull requests ud

Et AI-værktøj til afhjælpning retter de sårbarheder, det får. Hvis den liste er rekonstrueret ud fra lockfiles eller et scannet image, arver den alle huller i rekonstruktionen: værktøjer, som buildet downloader, og som intet manifest deklarerer, versioner, der afviger fra det, buildet faktisk resolvede, og pakker gendannet fra caches. Værktøjet åbner så selvsikre pull requests for nogle sårbarheder og hører aldrig om andre.

Nogle teams går videre og beder en model om selv at finde frem til afhængighederne. Så bliver inventaret også ikke-deterministisk, og det er netop den del af processen, der bør give det samme resultat hver gang. AI-genererede SBOM'er forklarer, hvorfor et gættet inventar ikke er dokumentation.

Det mønster, der virker, er deterministiske data i bunden og AI-dømmekraft ovenpå: en registreret liste over, hvad hvert build faktisk indeholder, matchet mod advisories ved opslag, og AI, der skriver rettelsen.

Hvor CRACI passer ind

CRACI er det deterministiske lag. Det kører dine GitHub Actions-jobs på sine egne runnere og registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder og pakker gendannet fra caches, med en fuldstændighedsstatus for hvert job. Det genvurderer løbende overvågede SBOM'er, så en ny advisory vises ved de builds, den rammer, og sikkerhedsteams triagerer hvert fund og sender det videre til det team, der ejer rettelsen.

Det er den liste, en AI-rettelse bør tage udgangspunkt i, og når rettelsen er merget, viser det næste builds SBOM, om den rettede version er den, buildet reelt brugte. Se sårbarhedssporing for hele funktionen og AI vs. deterministisk sikkerhed for, hvor hver tilgang hører hjemme.

AI-afhjælpning af sårbarheder: ofte stillede spørgsmål

Hvad er AI-afhjælpning af sårbarheder?

AI-afhjælpning af sårbarheder bruger en sprogmodel til at lave rettelsen af en sårbarhed: en kodeændring til et fund fra statisk analyse eller en opgradering af en afhængighed plus de kodeændringer, opgraderingen kræver. Resultatet er som regel et forslag eller en pull request, som et menneske skal gennemgå.

Hvad er agentisk afhjælpning?

Agentisk afhjælpning giver en AI-agent værktøjerne til selv at føre en rettelse gennem flere trin: læse fundet, ændre koden, køre buildet og testene og gentage, indtil de består, og derefter åbne en pull request. Forskellen fra et enkeltstående forslag er, at agenten tjekker sit eget arbejde, før et menneske ser det.

Er AI-genererede sikkerhedsrettelser sikre at merge?

Behandl dem som enhver anden bidragyders pull request. GitHub beskriver Copilot Autofix som ikke-deterministisk og advarer om, at den kan foreslå opdigtede afhængigheder, så gennemgå ændringen, kør testene, og tjek, at hver pakke, den tilføjer, findes og er den, du forventer.

Kan AI finde sårbarheder i afhængigheder?

Det er det forkerte værktøj til den del. Om en pakkeversion er ramt af en kendt advisory, er et opslag, og svaret bør være det samme hver gang. Lad deterministiske værktøjer lave listen over sårbare pakker ud fra en registreret SBOM, og brug AI, hvor dømmekraft hjælper: til at skrive og tilpasse rettelsen.

Hvad skal et AI-værktøj til afhjælpning bruge for at fungere godt?

En præcis liste over, hvad der faktisk er sårbart, et build og en testsuite, som rettelsen kan køres mod, og et menneske, der står for merge. Det første er det, der oftest mangler: En pull request med en rettelse til en pakke, produktet ikke leverer, er støj, og en sårbar pakke, som inventaret overså, får aldrig en.