AI-säkerhet behöver en second opinion

AI skriver programvara snabbare än vi hinner säkra den. Hänger du med?

Innan du har läst klart den här meningen kommer utvecklare och deras AI-agenter att ha skickat in ett par tusen kodändringar. Vid samma tidpunkt förra året skulle siffran ha varit omkring 150.

Under det senaste året har AI-genererad programvara ökat i en häpnadsväckande takt. GitHub registrerade 7,38 miljarder kodändringar enbart i september 2026, mer än fem gånger så många som året innan. Säkerhetskonsekvenserna av den här explosionen är djupgående. Varje sådan kodändring är kod som någon förväntas förstå, underhålla och säkra. Cloud Security Alliance fann att utvecklare med AI-stöd på Fortune 50-företag skickar in kod tre till fyra gånger så snabbt som sina kollegor, samtidigt som deras månatliga säkerhetsfynd ökade ungefär tiofalt.

Tänk nu på vem som får ta hand om den här ökningen. CISO:ns team är lika stort som för ett år sedan, men eftersläpningen är det inte. Antalet rapporterade sårbarheter ökar, antalet åtgärdade sårbarheter per månad minskar och antalet olösta kritiska sårbarheter växer. Det är inte konstigt att Gartner säger att utbrändhet bland CISO:er håller på att bli en kritisk operativ risk.

Frestelsen att välja den senaste modellen

När siffran är så hög är det lätt att vilja få upp den ännu mer: fler fynd, större täckning, fler skanningar. Men det är som att ösa ur en läckande båt och be om en större hink, när det du behöver är att hitta läckan. Ett säkerhetsprogram mäts inte efter hur mycket det hittar. Det mäts efter hur stor andel av fynden som är verkliga och hur många av de mest kritiska fynden som faktiskt åtgärdas.

De mest avancerade AI-modellerna är imponerande bra på att hitta nya angrepp och tidigare okatalogiserade sårbarheter med hjälp av sannolikhetsbaserat resonemang. Men resultaten varierar. Om du kör samma skanning på samma kod fem gånger stämmer fynden bara överens i ungefär en tredjedel av fallen, enligt Checkmarx forskning.

Det är därför regelbaserad analys fortfarande spelar roll. Den är mindre flexibel än de mest avancerade AI-modellerna, men tillämpar beprövad logik på samma sätt varje gång, så att team kan lita på och verifiera resultaten. AI hittar sådant som regler missar, till exempel välkända svagheter i ovanliga former eller brister som bara kan utnyttjas när olika delar av koden samverkar. Tillsammans hittar AI och regelbaserad analys fler av de viktiga problemen, med färre falsklarm.

Inget av det här är ett argument mot AI. Det är ett argument för att säkerhet behöver en second opinion. Oavsett vilken motor du väljer bör du ställa tre frågor.

Fråga ett: Tillförlitlighet

När skannern säger att något är fel, är det då värt din tid?

Tillförlitlighet handlar om förtroende. Ett fynd som inte stämmer kostar en utvecklare en eftermiddag och gör att säkerhetsteamet förlorar lite mer trovärdighet. I stor skala får falska positiva resultat teamen att sluta lyssna. Varningarna blir som att ropa ”vargen kommer” och försvinner i bakgrundsbruset.

Det är här konsekvens spelar roll. Deterministisk analys ger samma svar varje gång den körs på samma kod, vilket bygger förtroende och gör resultaten möjliga att granska.

Fråga två: Träffsäkerhet

Hittar du alla de problem som är viktigast?

Tillförlitlighet visar om ett fynd är värt din tid, men inte vad skannern har missat. Vi använder ett praktiskt mått med rötter i datavetenskapen som kallas F1-poäng. F1 mäter prestanda på en skala från 1 till 0 utifrån två faktorer:

• Precision: andelen rapporterade fynd som är verkliga. Hög precision innebär färre falsklarm.
• Täckningsgrad: andelen verkliga sårbarheter som skannern faktiskt hittar. Hög täckningsgrad innebär att få problem slinker igenom.

En skanner kan verka precis genom att flagga nästan ingenting, eller grundlig genom att flagga allt, men i båda fallen blir F1-poängen låg. Branschgenomsnittet ligger på omkring 0,20. Vi har arbetat hårt med den här utmaningen och sett resultat med tre till fyra gånger så hög träffsäkerhet som en standardskanner.

Bättre träffsäkerhet gör allt efterföljande arbete enklare för utvecklarna. Teamet lägger mindre tid på att kontrollera fynd och mer tid på att åtgärda dem.

Fråga tre: ROI

Hur maximerar vi investeringar och resurser?

Det här är den fråga som oftast förbises i pilotprojekt och som blir smärtsammast att besvara i produktion.

De mest avancerade modellerna tar betalt per token, och tokens förbrukas oavsett om en skanning hittar något eller inte. Att skanna ett kodförråd med en miljon rader kostar mer än tusen dollar enligt de publicerade priserna just nu. Skillnaden i tokenförbrukning mellan modellerna är dessutom stor; priset varierar beroende på vilken modell du väljer och hur mycket den behöver resonera för att slutföra uppgiften.

Multiplicera det med varje kodändring, pull-förfrågan och kodförråd i ett företag. Uber, som lägger 3,4 miljarder dollar om året på forskning och utveckling, ska enligt uppgift ha förbrukat hela sin AI-budget för 2026 inom några månader efter att ha infört AI-verktyg för kodning.

Vi kallar det tokenkostnaden. Det är som att ta en Ferrari för att handla mat: du betalar för en kraft som resan inte kräver. Hårdkodade inloggningsuppgifter och SQL-injektion är förutsägbara mönster som deterministisk analys hanterar på ett tillförlitligt sätt.

Applikationssäkerheten måste utvecklas

Det är tanken bakom arkitekturen i Checkmarx Fusion. Regelbaserade motorer fastställer tillförlitliga referensvärden på ett reproducerbart sätt och till en lägre kostnad än tokenbaserad analys. Frontiermodeller används för sådant som regler inte kan förutse: nya mönster, komplex logik och om något går att utnyttja i sitt sammanhang. Därefter sammanför ett analyslager för resultaten dem till en enda tillförlitlig helhet.

Deterministisk analys ger säkerhet. AI ger räckvidd. Täckning och tillförlitlighet ökar samtidigt. Jämfört med en LLM som arbetar på egen hand ser vi upp till fyra gånger högre resultattrohet, två till fyra gånger högre precision och ungefär en tredjedel av kostnaden.

Att hitta problem är bara början. Samma logik gäller förebyggande arbete. Låt oss ta ett exempel. Genom att ge utvecklare bättre förutsättningar redan när de skapar kod, i den utvecklingsmiljö där de skriver den, kan vi stoppa problemen innan de uppstår. Och när det gäller de sårbarheter som ändå slinker igenom, varför inte ge utvecklarna korrigeringar som är redo att sammanfogas för de sårbarheter som betyder mest? Det är de här utmaningarna vi arbetar med att lösa, med målet att beta av den befintliga ärendebalansen och skapa största möjliga effekt så snabbt som möjligt med minsta möjliga insats.

Koden körs. Hänger ni med?

AI har gett angripare en gåva i form av snabbhet. Lösningen på det gapet är inte ännu ett verktyg. Det handlar om ett beslut om hur hela organisationen utvecklar och skyddar programvara. Koden som skrivs i dag kommer att driva verksamheten i flera år. Frågan för säkerhetsansvariga är inte längre hur mycket snabbare AI hjälper er att utveckla. Frågan är om era program kan hålla jämna steg med det AI skapar.

Fastna inte i siffrorna. Ställ tre frågor om varje program: Kan jag lita på det som programmet hittar? Hittar det tillräckligt många av de problem som är viktiga? Är det realistiskt att införa i hela organisationen? Genom att kombinera deterministisk precision med frontiermodellernas förmåga att resonera får ni bäst möjlighet att svara ja på alla tre frågorna.

Programvaruutvecklingen saktar inte ner. Vårt uppdrag nu är att minska riskgapet: avståndet mellan hur snabbt programvara skapas och hur snabbt risker upptäcks och åtgärdas.