Under de senaste månaderna har stora språkmodeller gått från att översvämma open source-projekt och bug bounty-program med tvivelaktiga säkerhetsrapporter som slösade bort utvecklarnas tid, till att rutinmässigt upptäcka zero-day-sårbarheter som människor och traditionella säkerhetsgranskningsverktyg hade missat i åratal – en snabb utveckling av cyberkapaciteterna som skrämmer till och med deras egna skapare.
Men trots dessa framsteg när det gäller att upptäcka sårbarheter och skapa exploateringar verkar AI-modellerna inte utvecklas lika snabbt inom viktiga områden av cyberförsvaret, vilket ofta leder till att grundläggande säkerhetsbrister kvarstår i den kod de genererar – en kritisk brist inte bara på grund av den utbredda användningen av AI för mjukvaruutveckling, utan också när det gäller att tillhandahålla korrigeringar för de säkerhetshål som AI nu lätt kan upptäcka och utnyttja.
Enligt en färsk studie från applikationssäkerhetsföretaget Veracode innehåller 44 procent av den AI-genererade koden minst en känd sårbarhet från OWASP Top 10. Även om de senaste frontier-modellerna fick högre poäng hade ingen modell en säkerhetsgodkännandegrad på mer än 68 procent, vilket innebär att de fortfarande genererade osäker kod var tredje försök.
Dessutom förbättrades den genomsnittliga säkerhetsgodkännandegraden för AI-genererad kod knappt alls i de fyra undersökningar som Veracode genomförde under det senaste året, där man sammanlagt testade mer än 100 modellversioner.
Samtidigt producerade alla testade modeller syntaxmässigt korrekt kod i 99 procent av fallen.
– Varför blir de bättre på syntax? Varför blir de bättre på att skriva exploateringskod men inte bättre på att skriva säker kod?, säger Chris Wysopal, chefsäkerhetsevangelist på Veracode.
– Det är min fråga och det är vad vi försöker mäta.
Det är en avgörande fråga för it-chefer som vill infria AI:s löfte om att påskynda mjukvaruutvecklingen i en tid då AI också bidrar till att minska tiden till utnyttjande till nästan omedelbar tid.
Cyberobalans
Veracode är inte det enda företaget som sett den växande obalansen mellan offensiva och defensiva cyberförmågor inom stora språkmodeller. Tester utförda av det nederländska mjukvarukvalitetsföretaget Software Improvement Group (SIG) för rapporten ”State of Software 2026” visade att AI-genererad kod ger upphov till ungefär dubbelt så många säkerhetsöverträdelser jämfört med kod skriven av människor.
– Vi fann också att 71 procent av all kod, inte bara AI-kod, har en låg nivå av säkerhetskontroller, säger Jasper Geurts, SIG:s tekniska chef.
– AI skapade inte problemet; det förstärkte det. Där organisationer har mätt och hanterat kodkvaliteten påskyndar AI leveransen. Där de inte har gjort det, påskyndar det den tekniska skulden och säkerhetsrisken.
I juli använde forskare från Xint.io, en plattform för säkerhetstestning av kod utvecklad av Theori, fem nya AI-modeller från Anthropic och Open AI för att skapa applikationer från grunden med hjälp av AI, och arbetade med dem för att omstrukturera och stärka en befintlig, av människor skriven applikation. Bland de 28 appvarianterna hittade och validerade forskarna 434 säkerhetsbrister, varav 196 fanns i de nyligen genererade kodbaserna (greenfield) och 238 i den omstrukturerade applikationen (brownfield).
– Generellt sett ser vi att den vanligaste typen av brister i AI-genererad kod är sådana där koden fortfarande kompileras – det vill säga att koden körs men innehåller inbäddade hemligheter eller förbrukar för mycket resurser i stor skala, säger Kay Kwak, produktansvarig för Xint på Theori.
– Detta beror delvis på genvägar och snabbstarter i träningsdata, samt på att utvecklare efterfrågar en funktion utan att samtidigt uttryckligen begära en säkerhetsbarriär. Vi fann också att ju större och mer komplex kodbasen är, desto större är sannolikheten att AI:n tappar greppet om de finfördelade användarbehörigheterna.
Som Xints studie visar har modellerna problem med att generera säker kod även när de arbetar med en befintlig kodbas. Och detta gäller även för att åtgärda säkerhetsbrister, enligt forskning från 1Passwords Off-By-1 Labs, som testade kvaliteten på nya patchar genererade av olika modeller för sex kända och redan åtgärdade sårbarheter i komplexa open source-projekt.
Över 6 000 körningar var den genomsnittliga framgångsgraden för att generera en patch som helt åtgärdade sårbarheten utan att väsentligt ändra applikationens beteende endast 26 procent. Över hälften av de LLM-genererade patcharna åtgärdade inte sårbarheten, tillförde en ny sårbarhet eller båda delarna.
– Eftersom vår forskning handlade om patchning observerade vi snarare en redigeringsprocess än en helt ny skapandeprocess, säger Keith Hoodlet, chef för 1Passwords Off-By-1 Labs.
– Därför bör vår forskning och forskningen från Veracode ses som komplementära, snarare än att de utvärderar samma utmaningar. Med detta sagt citerar vi deras forskning som inspiration för vårt arbete, och båda forskningsprojekten pekar i riktning mot liknande slutsatser.
Bättre träning kanske inte löser problemet
Medan AI-laboratorier skyndar sig att lyfta fram modellförbättringar inom banbrytande sårbarhetsforskning är det inte helt klart varför generering av säker kod och åtgärdande av sårbarheter verkar ligga långt efter upptäckten av sårbarheter och utvecklingen av exploateringar.
Kwak på Xint anser att det i sig är svårt att skriva säker kod och bevisa att koden är säker.
– Svårigheten är inte specifik för AI. Mjukvaruutveckling har ett problem med bristande specifikation: Ingen skriver ner allt som koden inte får göra.
Olika definitioner av framgång för offensiva respektive defensiva scenarier kan också bidra till att förklara skillnaderna. Offensiv framgång är relativt enkel att verifiera: Om en agent kan reproducera eller utnyttja en sårbarhet är resultatet konkret. Men att avgöra om en patch täpper till varje relevant exploateringsvektor och sårbar kodväg är mycket svårare.
Med detta sagt är kvaliteten på träningsdata viktig för LLM:s prestanda, och det är rimligt att anta att befintliga modeller har tränats på en stor mängd offentlig kod som varierar kraftigt i kvalitet och säkerhet.
– Alla experiment vi hör talas om går ut på att de leker med offensiva förmågor och försöker förstå hur man genomför attacker; det är så dessa agenter kom på fri fot, säger Wysopal från Veracode och hänvisar till den rad av incidenter som nyligen inträffat på AI-labb, där agenter undkom sina inneslutningar under testning och attackerade tredjepartssystem.
– Vad de borde göra är att skaffa en noggrant utvald, säker datamängd med programkod och träna på den, och säga: ”Glöm all annan kod ni har tränat på, det vill säga den slumpmässiga koden som finns på internet. Gör er av med allt det där”, säger han.
– Skaffa licens för den bästa koden ni kan få tag på, kanske från banker eller andra områden som flygelektronik, där koden är känd för att vara säker eftersom den har genomgått noggranna kodgranskningar, och träna enbart på den. Det är svårt och tar tid, men det är så man skulle göra för försvaret. Såvitt jag vet gör de inte saker på det sättet.
Samtidigt pekar Hoodlet på en annan inneboende begränsning hos stora språkmodeller: deras uppmärksamhetsmekanismer, genom vilka de bedömer sammanhanget och relevansen hos ingångstoken.
– Uppmärksamhetsmekanismerna, som är grundläggande för hur dagens stora språkmodeller fungerar, kan hindra modellerna från att någonsin fullt ut hantera utmaningen att åtgärda sårbarheter, säger han.
– I forskningsrapporten observerade vi situationer där en agents korrigering endast åtgärdade en enda kodväg från proof-of-concept-exploiten, medan tecken-för-tecken identiska förekomster av samma bugg i angränsande kodvägar förbigicks. Det är oklart hur mycket mer träning som krävs för att åstadkomma bättre resultat inom säker kodning med tanke på denna inneboende begränsning.
Geurts anser att bättre träning endast kommer att hjälpa marginellt, eftersom en modell som standard inte har tillgång till en organisations arkitektur, säkerhetspolicyer, hotmodell och annan applikationsspecifik kontext. Harnesses kan tillhandahålla den kontexten och integrera deterministiska säkerhetskontroller i utvecklingsarbetsflödet.
Harness-utveckling förblir avgörande
I sin studie använde Veracode medvetet minimala prompter som skickades direkt till modellerna utan ytterligare säkerhetsinstruktioner, vilket inte är hur mjukvaruutvecklingsteam använder stora språkmodeller i praktiken. De andra studierna använde olika grader av stödstrukturer, men ingen utvärderade hela bredden av kontroller som kan finnas i en mogen utvecklingspipeline inom ett företag, vilka ofta inkluderar specialiserade AI-kodningsassistenter med detaljerade specifikationer, valideringsarbetsflöden, systemprompter, MCP-anslutningar, kompetensdefinitioner och andra stödverktyg.
Sådana stödstrukturer kan hämta relevanta filer och arkitekturdokumentation, tillhandahålla information om hotmodeller, lista godkända kodningsmönster, köra kompilatorer och tester, anropa verktyg för statisk och dynamisk säkerhetstestning samt genomdriva godkännandekontroller som hindrar AI-agenter från att fortsätta tills identifierade fel har åtgärdats.
Open AI samarbetade till exempel med Trail of Bits för att använda sina modeller till att hitta sårbarheter i open source-projekt som är kritiska för internetinfrastrukturen och hjälpa till att utveckla korrigeringar för dessa. För projektet, som fått namnet Patch the Planet, byggde forskarna specialiserade arbetsflöden och verktygssatser, och den 11 augusti hade initiativet listat 1 250 rapporterade problem i 49 kodbaser, 271 framtagna korrigeringar och 146 patchar som godkänts uppströms.
Xint har observerat en liknande effekt i interna tester, enligt Kwak. Företaget utvärderade de senaste modellerna mot 208 000 rader kod som innehöll 17 insatta sårbarheter. Enkla loopar med prompt hittade mellan noll och en av bristerna, medan modeller som kördes i Xints specialiserade testramverk hittade mellan 11 och 14.
– De enkla looparna öppnade endast 2,9 procent av filerna, och man kan inte hitta en bugg i en fil man aldrig öppnar, säger Kwak.
Testramar kan avgöra vilka bevis som når modellen, vilka verktyg som kan motsäga dess initiala svar, vad som räknas som framsteg och när arbetsflödet ska avbrytas eller eskaleras. Detta kan vara lika viktigt som valet av modell, särskilt när man arbetar med stora kodbaser. Det finns gott om exempel från de senaste sex månaderna där modeller med öppen vikt, som är mindre kapabla i långa resonemangsslingor, presterade lika bra som frontlinjemodeller när de användes i specialbyggda ramverk som hjälpte till att hålla dem på rätt spår och hantera deras minne.
SIG använde nyligen Claude Sonnet 4.6 för att bygga samma testprojekt 20 gånger. I tio körningar användes samma modell, uppgift, ramverk, acceptanstester och initiala instruktioner, medan de övriga tio även hade företagets Sigrid Guardrails-system via MCP som en obligatorisk säkerhets- och kvalitetskontroll. De vägledda körningarna resulterade i cirka 97 % färre säkerhetsproblem med hög risk enligt SIG:s analys och uppnådde 24 % högre underhållbarhetsbetyg.
– Harnessen är operativsystemet för AI-agenter. Det är där man lägger in de begränsningar som gör dem tillförlitliga. Utan den är AI snabb och övertygande, även när den har fel, säger Geurts.
Effektiva testramverk integrerar deterministiska analysverktyg i AI-arbetsflödet, såsom kodgranskare, typkontrollverktyg, säkerhetsskannrar och tester som hindrar en agent från att fortsätta tills dess utdata har verifierats. Men även med välkonstruerade testramverk finns det ingen garanti för att inga sårbarheter kvarstår.
– Implementering av testramar är i stor utsträckning den riktning vi tror att branschen är på väg mot, säger Hoodlet från Off-By-1 Labs.
– Om man kör ett arbetsflöde som går från upptäckt av sårbarheter, till granskning och bedömning, till patchning och validering innan man återgår till upptäckt av sårbarheter – måste man då upprepa den processen tio gånger för att uppnå en 90-procentig eller bättre chans att skapa en robust patch? Krävs det hundra eller tusen iterationer för att uppnå ett robust patchresultat? Det är något vi är intresserade av att titta närmare på.
Mänsklig övervakning behövs fortfarande
Valideringssteg och automatiserade kontroller kan minska mängden felaktig kod som når utvecklare, men de överför inte ansvaret för resultatet till LLM:en. En AI-agent kan agera utifrån skannerns resultat, köra tester och revidera sitt utfall, men i slutändan måste organisationen fortfarande avgöra om kraven var fullständiga, om valideringen var tillräcklig och om den kvarstående risken är acceptabel.
Geurts hävdar att detta förändrar var mänskligt omdöme tillämpas och att, i takt med att organisationer utökar sin användning av AI, flyttas den mänskliga rollen uppströms: från att granska kod till att styra vad och hur som byggs.
Experter är överens om att företag bör behålla de säkerhetskontroller de använder i dag istället för att betrakta AI-baserade kodgranskare som ersättare för dessa. Kompilering, typkontroll, enhets- och integrationstester, statisk applikationssäkerhetstestning, analys av programvarukomposition, skanning av hemlig information och infrastrukturkontroller kan upptäcka olika typer av säkerhetsfel.
– Alla de kontroller vi har i dag måste fortsätta att användas, men vi har nu dessa ytterligare möjligheter med agentbaserad säkerhetstestning”, säger Wysopal.
Han ser deterministiska verktyg och AI-baserad säkerhetstestning som komplementära eftersom båda kan identifiera problem som den andra missar.
Men i slutändan bör säkerhetskänsliga ändringar förbli under kontroll av utvecklare som förstår den berörda koden och dess roll i det större systemet.
– Man skulle inte låta en AI driftsätta sin programvara utan mänsklig inblandning – så varför efterfrågar man automatisk korrigering i form av patchar som skulle göra det möjligt att kringgå ingenjörerna? De viktigaste stegen – att slå samman ändringar och testa dessa ändringar – bör förbli kodägarnas ansvar, säger Kwak.
Mänsklig validering kommer att begränsa hur snabbt organisationer kan godkänna AI-genererade ändringar, särskilt när agenterna producerar mer kod och fler kandidater till patchar. Men åtminstone för tillfället kan det vara farligt att betrakta den granskningsprocessen som något man kan undvika.
– Även om detta kanske inte är effektivt sett till kodhastigheten, så kan man återanvända ett mantra från US Navy SEALs: ”Långsamt är smidigt, och smidigt är snabbt”, säger Hoodlet.
– Att producera större mängder kod snabbare är inte detsamma som att producera funktionell, säker och robust kod. Kod som är funktionell, säker och robust är otroligt effektiv – eftersom den bara behöver skrivas en gång.