Koden bredvid är mallen

Kodagenter skriver en växande andel av produktionskoden, och det är känt att de ibland producerar osäker kod. En artikel som lades upp på arXiv den 8 november ställer en annan fråga: vad händer med ett repositoriums säkerhet över tid när agenter fortsätter att bidra till det.

Författarna gjorde två experiment. I det första fick agenterna 96 uppgifter som krävde att de byggde en ny backend-applikation i ett repositorium där andra applikationer redan fanns. I det andra undersökte de kodgenerering på repositorienivå i 20 uppgiftspar i verkliga C- och C++-projekt, där agenten varje gång skulle färdigställa kod som var kritisk för minnessäkerheten.

I båda fallen pekade resultatet åt samma håll. Osäker befintlig kod fick agenterna att skriva sårbar kod oftare. I backend-genereringen var effekten måttlig: osäkra grannar minskade andelen implementationer som var både korrekta och säkra med 3,4 procent i snitt. I C- och C++-arbetet var den allt annat än måttlig: det genomsnittliga gapet mellan säkra och osäkra sammanhang nådde 35,4 procent.

Rostiga kedjelänkar fotograferade på nära håll
Agenterna tillskrev sina implementationsval ett annat kodställe i 76,5 procent av fallen. Miguel Á. Padriñán · pexels · Pexels License

De såg vad de gjorde

Den obekvämaste siffran i artikeln är inte gapet utan förklaringen. När agenterna ombads redogöra för sina implementationsval tillskrev de dem ett annat kodställe i repositoriet i 76,5 procent av fallen. I 69,9 procent av fallen kände de igen sårbarheten de just hade infört.

Den kombinationen utesluter den enklaste tolkningen. Det handlar inte om en modell som inte kan skilja säker kod från osäker; det är en modell som kan det, och som behandlar det lokala prejudikatet som den starkare signalen. Författarna uttrycker det rakt: agenter använder befintliga sårbarheter som mallar för nya utan urskillning, och gör varje bidrag till ett tillfälle att införa fler.

Prompten flyttar nålen utan att stänga gapet

Studien testade också de två uppenbara åtgärderna. Att be agenten följa den befintliga kodstilen ökade hur starkt den spred sårbarheter. Att be den vara försiktig med säkerheten minskade spridningen. Ingen av dem stoppade den.

Det spelar roll för hur verktygen faktiskt ställs in. “Följ stilen i omgivningen” är nästan en standardinstruktion i agenternas konfigurationsfiler och i bidragsguider, och artikeln säger att instruktionen har ett säkerhetspris. En säkerhetspåminnelse i prompten hjälper, men är en lindring snarare än en lösning.

En slät vägg av rött tegel
Osäker grannkod vidgade gapet mellan säkert och osäkert till 35,4 procent i C och C++. Ila Bappa Ibrahim · pexels · Pexels License

Varför riktningen är poängen

En osäker funktion har alltid varit en skuld. Det artikeln beskriver är en skuld som förökar sig. Om en agent läser repositoriet för att avgöra hur den ska skriva, är en orättad sårbarhet inte bara ett hål på ett ställe — den är ett mönster som finns tillgängligt att kopiera in i varje nytt bidrag som rör liknande kod.

Författarna drar slutsatsen rakt ut: när agenter skriver en växande andel av produktionskoden under minskande mänsklig granskning kan kodbaser gradvis försämras säkerhetsmässigt om inte sårbarheter rättas grundligt och fortlöpande. Det gör patchning till ett villkor för allt agenten skriver härnäst, snarare än en post i en backlogg.

Siffrorna kommer från författarnas egna experiment och har inte reproducerats oberoende. Det som skulle avgöra saken är samma mätning på ett verkligt repositorium över månader i stället för på uppgifter, och om gapet på 35,4 procent i minneskritisk C och C++ krymper när agenter blir bättre på att resonera om koden de läser i stället för att härma den.