18 AI-modeller jämförda: Så säkert skriver de kod

– Det går inte att lita på att någon AI-modell kan generera säker kod på egen hand, inte ens de modeller som presterar bäst, säger Michael Freeman, chef för hotanalys på Armis by Servicenow, till Techtidningen.

Hans slutsats är att AI-genererad kod bör hanteras på samma sätt som kod från en okänd extern källa.

– Produktivitetsvinster är inte gratis. Varje rad AI-genererad kod måste behandlas som opålitlig tills den har granskats och validerats ordentligt.

Gemini i topp

Google Gemini 3.1 Pro fick bäst resultat i jämförelsen. Modellen hade lägst andel scenarier med sårbarheter kopplade till OWASP tio vanligaste säkerhetsrisker och till de särskilt prioriterade CWE-kategorier som Armis använde i testet.

Gemini 3.1 Pro genererade totalt 39 identifierade sårbarheter och undvek helt scenarier med flera sammanfallande kritiska brister. Open AI Codex-modeller placerade sig också högt och beskrivs i rapporten som den jämnaste modellfamiljen ur säkerhetssynpunkt.

Bland Claude-modellerna presterade de nyare versionerna Opus 4.6 och Sonnet 4.6 betydligt bättre än sina föregångare. Claude Sonnet 4.5 och Claude Haiku 4.5 hamnade däremot långt ned i jämförelsen efter att ha genererat många sårbarheter och flera fall där flera brister uppstod samtidigt.

Även Gemini 2.5 Pro placerade sig svagt i förhållande till kostnaden.

– Ett högt pris garanterar inte säkerhet. Gemini 2.5 Pro är en av de dyraste modellerna i jämförelsen, men hamnar först på 13:e plats. Samtidigt presterade flera modeller med öppen källkod bättre än flera premiumalternativ, säger Michael Freeman.

Modeller som placerade sig högst i Armis jämförelse

• Google Gemini 3.1 Pro
• Open AI GPT-5.1 Codex
• Anthropic Claude Opus 4.6
• Open AI GPT-5.3 Codex
• Open AI GPT-5.2 Codex

Rankningen bygger på Armis Labs sammanvägning av antalet sårbarheter, förekomsten av särskilt prioriterade brister och scenarier där flera brister uppstod samtidigt.

Missade skydd mot överbelastning

Den vanligaste svagheten i testet var CWE-770. Den innebär att kod saknar begränsningar för exempelvis minnesanvändning, filstorlek eller antal anrop. Bristen förekom 179 gånger.

Utan sådana gränser kan en applikation bli sårbar för överbelastningsattacker eller förbruka stora mängder systemresurser.

– AI-modeller inför nästan aldrig begränsningar för antal anrop, filstorlek eller minnesanvändning som standard. Det gör applikationer sårbara för överbelastningsattacker, säger Michael Freeman.

Ett annat återkommande problem var felsökningsfunktioner som lämnats aktiverade. I ett scenario med inloggning genererade samtliga modeller sådan kod. Det kan vara naturligt under utvecklingen, men innebär en risk om funktionerna följer med till produktionsmiljön.

Rapporten pekar också ut autentisering, auktorisering, osäker deserialisering och filuppladdning som särskilt problematiska områden.

Säkerheten måste följa med i arbetsflödet

Säkerhetsarbetet blir mer komplicerat när AI-verktygen går från att föreslå enstaka kodrader till att planera, skriva, köra och förändra större delar av en applikation.

Michael Freeman beskriver det som en övergång till agentbaserade utvecklingsflöden. Det gör utvecklingen snabbare, men kan samtidigt minska tiden för traditionell granskning.

– Kod genereras, förändras och driftsätts i en takt som traditionella säkerhetsprocesser aldrig utformades för att hantera. Säkerhet kan därför inte vara något som tillämpas efter att koden har skrivits, utan måste integreras direkt i det agentbaserade arbetsflödet.

För it- och säkerhetschefer innebär det att organisationen behöver bestämma vilka AI-verktyg och modellversioner som får användas, vilken typ av kod de får skapa och vilka kontroller som alltid måste genomföras.

Tre kontroller innan koden når produktion

Michael Freeman pekar ut tre åtgärder som organisationer bör ha på plats innan AI-genererad kod driftsätts.

1. Skanna koden tidigt

Säkerhetsskanning bör ske innan koden checkas in och fortsätta genom hela CI/CD-flödet. Syftet är att hitta sårbar kod innan den byggs in i större komponenter och blir svårare och dyrare att åtgärda.

2. Styr vilka modeller som används

Organisationen bör ha tydliga regler för vilka modeller och modellversioner som får användas och till vilka uppgifter. Nyare och utvecklaranpassade modeller kan ge ett bättre grundskydd, men modellvalet ersätter inte andra säkerhetskontroller.

3. Behåll den mänskliga granskningen

Kod som hanterar autentisering, auktorisering, behörigheter eller känsliga uppgifter bör alltid granskas av en människa.

Michael Freeman rekommenderar obligatorisk mänsklig granskning, oavsett hur säkert AI-verktyget verkar vara. Enligt honom väger risken för och kostnaden av ett intrång tyngre än den tid som sparas genom att hoppa över granskningen.

Rapporten har tagits fram av Armis Labs, forskningsverksamheten inom säkerhetsbolaget Armis by Servicenow.