AI-baserad åtgärd av sårbarheter: vad pull requests med AI-rättningar klarar

Vad AI-baserad åtgärd är

AI-baserad åtgärd av sårbarheter innebär att en språkmodell tar fram rättningen av en känd sårbarhet. Den finns i tre former:

• Förslag på kodrättningar. En modell föreslår en patch bredvid en varning från statisk analys. GitHub Copilot Autofix, till exempel, ”genererar automatiskt förslag på kodändringar för CodeQL-varningar som hittas i pull requests och på standardgrenen”.
• Uppgraderingar av beroenden som anpassar koden. Att höja en version är enkelt. Det svåra är den omdöpta funktionen eller det ändrade standardvärdet som den nya versionen för med sig. En modell kan göra de följdändringarna i samma pull request.
• Agentisk åtgärd. En agent driver rättningen genom flera steg på egen hand: ändrar koden, kör bygget och testerna, läser felen, försöker igen och öppnar en pull request först när kontrollerna går igenom.

Där AI-rättningar gör nytta

Regelbaserade uppdateringsbottar öppnar redan pull requests som höjer ett sårbart paket till en rättad version. De fastnar när uppgraderingen bryter något, eftersom det inte finns någon regel för att anpassa den anropande koden. Det är där eftersläpningen växer: säkerhetsuppdateringen som ligger öppen i månader eftersom ingen har tid att ta sig igenom bytet av huvudversion.

Att läsa en ändringslogg, hitta anropsplatserna och skriva om dem är just den sortens arbete som språkmodeller gör bra. En AI-rättning som kommer med uppgraderingen och kodändringarna, byggd och testad, förvandlar en veckas uppmärksamhet från någon till en granskning.

Där AI-rättningar går fel

De tydligaste beskrivningarna av begränsningarna kommer från leverantörerna själva. Om Copilot Autofix skriver GitHub:

• Det ”använder en generativ modell som är icke-deterministisk. Även med samma varning och samma kod kan den misslyckas med att ta fram ett användbart förslag, eller så kan förslaget variera mellan försöken.”
• ”Systemet vet inte vilka versioner av beroenden som stöds eller är säkra, och kan föreslå påhittade beroenden publicerade under statistiskt sannolika namn.”

Den andra punkten är inte hypotetisk. Forskning om kodgenererande modeller har mätt hur ofta de rekommenderar paket som inte finns, namn som en angripare kan registrera och fylla med skadlig kod. En rättning som installerar ett hallucinerat paket byter ut en sårbarhet mot en värre.

Tre skyddsräcken täcker det mesta av risken:

1. Bygg och testa varje rättning innan en människa granskar den, så att granskningstiden går till rättningar som fungerar.
2. Kontrollera varje tillagt eller ändrat paket mot registret och den version du förväntar dig.
3. Låt en människa besluta om merge. En AI-rättning är en bidragsgivares pull request, inte ett beslut.

Skräp in, pull requests ut

Ett AI-verktyg för åtgärd av sårbarheter rättar de sårbarheter det får. Om den listan är rekonstruerad från lockfiler eller en skannad avbild ärver den varje lucka i rekonstruktionen: verktyg som bygget laddar ner men som inget manifest deklarerar, versioner som skiljer sig från dem bygget faktiskt löste, paket som återställs från cachar. Verktyget öppnar då självsäkra pull requests för vissa sårbarheter och hör aldrig talas om andra.

Vissa team går längre och ber en modell att själv räkna ut beroendena. Då blir även inventeringen icke-deterministisk, och det är just den del av processen som ska bli likadan varje gång. AI-genererade SBOM:er förklarar varför en gissad inventering inte är något bevis.

Det mönster som fungerar är deterministiska data i botten och AI-omdöme ovanpå: en registrerad lista över vad varje bygge faktiskt innehåller, matchad mot säkerhetsmeddelanden genom uppslagning, och AI som skriver rättningen.

Där CRACI passar in

CRACI är det deterministiska lagret. Det kör dina GitHub Actions-jobb på sina egna runners och registrerar paketen varje jobb faktiskt hämtade, inklusive transitiva beroenden och paket som återställs från cachar, med en fullständighetsstatus för varje jobb. Det omvärderar bevakade SBOM:er löpande, så att ett nytt säkerhetsmeddelande syns mot de byggen det berör, och säkerhetsteamen triagerar varje fynd och skickar det vidare till teamet som äger rättningen.

Det är den listan en AI-rättning ska utgå från, och när rättningen har mergats visar nästa byggs SBOM om den rättade versionen verkligen är den som bygget använde. Se sårbarhetsbevakning för hela funktionen och AI kontra deterministisk säkerhet för var respektive metod hör hemma.

AI-baserad åtgärd av sårbarheter: vanliga frågor

Vad är AI-baserad åtgärd av sårbarheter?

AI-baserad åtgärd av sårbarheter innebär att en språkmodell tar fram rättningen av en sårbarhet: en kodändring för ett fynd från statisk analys, eller en uppgradering av ett beroende plus de kodändringar som uppgraderingen kräver. Resultatet är oftast ett förslag eller en pull request som en människa granskar.

Vad är agentisk åtgärd?

Vid agentisk åtgärd får en AI-agent verktygen för att driva en rättning genom flera steg på egen hand: läsa fyndet, ändra koden, köra bygget och testerna och iterera tills de går igenom, och sedan öppna en pull request. Skillnaden mot ett engångsförslag är att agenten kontrollerar sitt eget arbete innan en människa ser det.

Är AI-genererade säkerhetsrättningar säkra att merga?

Behandla dem som vilken annan bidragsgivares pull request som helst. GitHub beskriver Copilot Autofix som icke-deterministiskt och varnar för att det kan föreslå påhittade beroenden, så granska ändringen, kör testerna och kontrollera att varje paket som läggs till finns och är det du förväntar dig.

Kan AI hitta sårbarheter i beroenden?

Det är fel verktyg för den delen. Om en paketversion berörs av ett känt säkerhetsmeddelande är en uppslagning, och svaret ska bli detsamma varje gång. Låt deterministiska verktyg ta fram listan över sårbara paket ur en registrerad SBOM, och använd AI där omdöme hjälper: att skriva och anpassa rättningen.

Vad behöver ett AI-verktyg för åtgärd av sårbarheter för att fungera bra?

En korrekt lista över vad som faktiskt är sårbart, ett bygge och en testsvit som rättningen kan köras mot, och en människa som beslutar om merge. Det första är det som oftast saknas: en pull request med en rättning för ett paket som produkten inte levererar är brus, och ett sårbart paket som inventeringen missade får aldrig någon.