AI-basert utbedring av sårbarheter: hva pull requests med AI-rettinger kan gjøre

Hva AI-basert utbedring er

AI-basert utbedring av sårbarheter bruker en språkmodell til å lage rettingen for en kjent sårbarhet. Den finnes i tre former:

• Forslag til kodeendringer. En modell foreslår en patch ved siden av et varsel fra statisk analyse. GitHub Copilot Autofix, for eksempel, «genererer automatisk forslag til kodeendringer for CodeQL-varsler som blir funnet i pull requests og på standardgrenen».
• Oppgraderinger av avhengigheter som tilpasser koden. Å øke et versjonsnummer er enkelt. Det vanskelige er den omdøpte funksjonen eller den endrede standardverdien som den nye versjonen fører med seg. En modell kan gjøre disse følgeendringene i samme pull request.
• Agentisk utbedring. En agent fører rettingen gjennom flere steg på egen hånd: endrer koden, kjører bygget og testene, leser feilene, prøver igjen og åpner en pull request først når kontrollene består.

Der AI-rettinger gjør nytte for seg

Regelbaserte oppdateringsboter åpner allerede pull requests som løfter en sårbar pakke til en rettet versjon. De stopper opp når oppgraderingen ødelegger noe, fordi det å tilpasse koden som kaller pakken, ikke er en regel. Det er der etterslepet hoper seg opp: sikkerhetsoppdateringen som blir liggende åpen i månedsvis fordi ingen har tid til å arbeide seg gjennom endringen av hovedversjon.

Å lese en endringslogg, finne kallstedene og skrive dem om er den typen arbeid språkmodeller gjør godt. En AI-retting som kommer med oppgraderingen og kodeendringene, bygget og testet, gjør en ukes oppmerksomhet fra noen om til en gjennomgang.

Der AI-rettinger går galt

De klareste beskrivelsene av begrensningene kommer fra leverandørene selv. Om Copilot Autofix skriver GitHub:

• Det «bruker en generativ modell som er ikke-deterministisk. Selv med samme varsel og samme kode kan den mislykkes i å lage et brukbart forslag, eller forslaget kan variere fra forsøk til forsøk».
• «Systemet vet ikke hvilke versjoner av avhengigheter som er støttet eller sikre, og kan foreslå oppdiktede avhengigheter publisert under statistisk sannsynlige navn.»

Det andre punktet er ikke hypotetisk. Forskning på kodegenererende modeller har målt hvor ofte de anbefaler pakker som ikke finnes, navn en angriper kan registrere og fylle med skadevare. En retting som installerer en hallusinert pakke, bytter ut én sårbarhet med en verre.

Tre sikkerhetsmekanismer dekker det meste av risikoen:

1. Bygg og test hver retting før en person går gjennom den, så tiden til gjennomgang går til rettinger som fungerer.
2. Sjekk hver pakke som legges til eller endres mot registeret og versjonen du forventer.
3. La en person stå for mergen. En AI-retting er en pull request fra en bidragsyter, ikke en beslutning.

Søppel inn, pull requests ut

Et AI-verktøy for utbedring retter sårbarhetene det får. Hvis den listen er rekonstruert fra lockfiler eller et skannet image, arver den hvert hull i rekonstruksjonen: verktøy som bygget laster ned uten at noe manifest deklarerer dem, versjoner som avviker fra det bygget løste, pakker gjenopprettet fra cacher. Verktøyet åpner da selvsikre pull requests for noen sårbarheter og hører aldri om andre.

Noen team går lenger og ber en modell finne ut av avhengighetene selv. Da blir også inventaret ikke-deterministisk, og det er nettopp den ene delen av prosessen som bør bli lik hver gang. AI-genererte SBOM-er forklarer hvorfor et gjettet inventar ikke er dokumentasjon.

Mønsteret som fungerer, er deterministiske data i bunnen og AI-skjønn på toppen: en registrert liste over hva hvert bygg faktisk inneholder, matchet mot sikkerhetsmeldinger ved oppslag, og AI som skriver rettingen.

Der CRACI passer inn

CRACI er det deterministiske laget. Det kjører GitHub Actions-jobbene dine på egne runnere og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter og pakker gjenopprettet fra cacher, med en fullstendighetsstatus for hver jobb. Det vurderer overvåkede SBOM-er på nytt fortløpende, så en ny sikkerhetsmelding dukker opp mot byggene den berører, og sikkerhetsteamene prioriterer hvert funn og sender det til teamet som eier rettingen.

Det er listen en AI-retting bør starte fra, og etter at rettingen er merget, viser SBOM-en fra neste bygg om den rettede versjonen er den bygget faktisk brukte. Se sårbarhetssporing for hele funksjonen, og AI vs. deterministisk sikkerhet for hvor hver tilnærming hører hjemme.

AI-basert utbedring av sårbarheter: ofte stilte spørsmål

Hva er AI-basert utbedring av sårbarheter?

AI-basert utbedring av sårbarheter bruker en språkmodell til å lage rettingen for en sårbarhet: en kodeendring for et funn fra statisk analyse, eller en oppgradering av en avhengighet pluss kodeendringene oppgraderingen krever. Resultatet er som regel et forslag eller en pull request som en person skal gå gjennom.

Hva er agentisk utbedring?

Ved agentisk utbedring får en AI-agent verktøyene til å føre en retting gjennom flere steg på egen hånd: lese funnet, endre koden, kjøre bygget og testene og prøve igjen til de består, og deretter åpne en pull request. Forskjellen fra et engangsforslag er at agenten kontrollerer sitt eget arbeid før en person ser det.

Er AI-genererte sikkerhetsrettinger trygge å merge?

Behandle dem som en pull request fra en hvilken som helst annen bidragsyter. GitHub beskriver Copilot Autofix som ikke-deterministisk og advarer om at det kan foreslå oppdiktede avhengigheter, så gå gjennom endringen, kjør testene og sjekk at hver pakke den legger til, finnes og er den du forventer.

Kan AI finne sårbarheter i avhengigheter?

Det er feil verktøy for den delen. Om en pakkeversjon er berørt av en kjent sikkerhetsmelding, er et oppslag, og svaret bør bli det samme hver gang. La deterministiske verktøy lage listen over sårbare pakker ut fra en registrert SBOM, og bruk AI der skjønn hjelper: når rettingen skal skrives og tilpasses.

Hva trenger et AI-verktøy for utbedring for å fungere godt?

En nøyaktig liste over hva som faktisk er sårbart, et bygg og en testsuite det kan kjøre rettingen mot, og en person som står for mergen. Det første er det som oftest mangler: en pull request med en retting for en pakke produktet ikke leverer, er bare støy, og en sårbar pakke som inventaret gikk glipp av, får aldri noen.