AI-sikkerhed kræver en second opinion

AI skriver software hurtigere, end vi kan sikre den. Kan du følge med?

Når du er færdig med at læse denne sætning, vil udviklere og deres AI-agenter have indsendt et par tusind kodeændringer. På samme tidspunkt sidste år ville tallet have været omkring 150.

Det seneste år er AI-genereret software blevet udviklet med en forbløffende hastighed. GitHub registrerede 7,38 milliarder commits alene i september 2026, mere end fem gange så mange som året før. Sikkerhedsmæssigt har denne eksplosion vidtrækkende konsekvenser. Hver eneste af disse commits er kode, som nogen forventes at forstå, vedligeholde og sikre. Cloud Security Alliance fandt, at udviklere, der bruger AI, hos Fortune 50-virksomheder indsender kode tre til fire gange så hurtigt som deres kolleger, mens antallet af månedlige sikkerhedsproblemer, de finder, steg omtrent tidoblet.

Overvej nu, hvem der skal håndtere denne stigning. CISO’ens team er lige så stort som for et år siden, men efterslæbet er ikke. Antallet af indberettede sårbarheder stiger, antallet af rettelser om måneden falder, og antallet af uløste kritiske problemer vokser. Det er ikke så mærkeligt, at Gartner siger, at udbrændthed blandt CISO’er er ved at blive en kritisk operationel risiko.

Fristelsen ved den nyeste model

Når tallet er så stort, er det fristende at gå efter et endnu større tal: flere fund, større dækning, flere scanninger. Men det svarer til at øse vand ud af en synkende båd og bede om en større spand, når det, du har brug for, er at finde lækagen. Et sikkerhedsprogram måles ikke på, hvor meget det finder. Det måles på, hvor meget af det, det finder, der er reelt, og hvor mange af de mest kritiske fund der faktisk bliver rettet.

Avancerede AI-modeller er imponerende gode til at finde nye udnyttelsesmetoder og hidtil ukatalogiserede fejl ved hjælp af probabilistisk ræsonnement. Men resultaterne varierer. Ifølge Checkmarx’ undersøgelser stemmer fundene kun overens i omkring en tredjedel af tilfældene, når den samme kode scannes fem gange.

Derfor er regelbaseret analyse stadig vigtig, trods denne inkonsistens. Den er mindre fleksibel end avanceret AI, men anvender gennemprøvet logik på samme måde hver gang, så teams kan have tillid til resultaterne og efterprøve dem. AI opdager det, regler overser, f.eks. velkendte svagheder i ukendte former eller fejl, der først kan udnyttes, når forskellige dele af koden påvirker hinanden. Tilsammen afdækker AI og regelbaseret analyse flere af de vigtige problemer og skaber færre falske alarmer.

Intet af dette er et argument imod AI. Det er et argument for, at sikkerhed kræver en second opinion. Uanset hvilken løsning du vælger, bør du stille den tre spørgsmål.

Spørgsmål ét: Pålidelighed

Når scanneren siger, at noget er galt, er det så værd at bruge tid på?

Pålidelighed handler om tillid. Et fund, der ikke er reelt, koster en udvikler en eftermiddag og sikkerhedsteamet lidt mere troværdighed. Når omfanget vokser, er det falske positiver, der får teams til at holde op med at lytte. Advarslerne er bare »ulven kommer« og forsvinder i baggrundsstøjen.

Det er her, konsistens er vigtig. Deterministisk analyse giver det samme svar hver gang på den samme kode, hvilket opbygger tillid og gør resultaterne mulige at revidere.

Spørgsmål to: Nøjagtighed

Finder du alle de vigtigste problemer?

Pålidelighed fortæller dig, om et fund er værd at bruge tid på, men ikke, hvad scanneren har overset. Vi bruger et praktisk måltal med rødder i datavidenskab, der kaldes en F1-score. F1 måler ydeevnen på en skala fra 1-0 ud fra to faktorer:

• Præcision: andelen af de indberettede fund, der er reelle. Høj præcision betyder færre falske alarmer.
• Recall: andelen af de reelle sårbarheder, som scanneren faktisk finder. Høj recall betyder, at kun få slipper igennem.

En scanner kan virke præcis ved næsten ikke at markere noget eller grundig ved at markere alt, men i begge tilfælde kan F1-scoren være lav. Branchens gennemsnit ligger på omkring 0,20. Vi har arbejdet hårdt med denne udfordring og har set resultater, der er tre til fire gange så nøjagtige som en standards scanners.

Større nøjagtighed gør alt det efterfølgende lettere for udviklerne. Dit team bruger mindre tid på at kontrollere fund og mere tid på at rette dem.

Spørgsmål tre: ROI

Hvordan får vi mest muligt ud af investeringer og ressourcer?

Det er det spørgsmål, man oftest springer over i pilotfasen, og som det gør mest ondt at besvare i produktion.

Avancerede modeller faktureres efter tokenforbrug, og der bruges tokens, uanset om en scanning finder noget eller ej. Det koster mere end tusind dollars at scanne et kodearkiv med en million linjer til de aktuelt offentliggjorte priser. Og der er stor forskel på modellernes tokenforbrug; prisen varierer alt efter, hvilken model du vælger, og hvor meget den skal ræsonnere for at løse din opgave.

Gang det op med alle commits, pullanmodninger og kodearkiver i en virksomhed. Uber, der bruger 3,4 milliarder dollars om året på R&D, havde angiveligt opbrugt hele sit AI-budget for 2026 inden for få måneder efter indførelsen af AI-kodeværktøjer.

Vi kalder det tokenafgiften. Det svarer til at tage en Ferrari for at hente dagligvarer: Du betaler for en motorkraft, turen ikke kræver. Hardcodede legitimationsoplysninger og SQL-injektion er forudsigelige mønstre, som deterministisk analyse pålideligt kan afdække.

Applikationssikkerhed skal udvikle sig

Det er tankegangen bag arkitekturen i Checkmarx Fusion. Regelbaserede motorer fastlægger et reproducerbart facit til lavere omkostninger end tokenbaseret analyse. Frontiermodeller sættes ind på det, reglerne ikke kan forudse: nye mønstre, kompleks logik og udnyttelsesmuligheder i den rette kontekst. Derefter samler et lag til analyse af fundene resultaterne i ét pålideligt sæt.

Deterministisk analyse giver sikkerhed. AI giver rækkevidde. Dækning og tillid øges samtidig. Sammenlignet med en LLM, der arbejder alene, ser vi op til fire gange så høj fidelitet, to til fire gange så høj nøjagtighed og en pris på omtrent en tredjedel.

At finde problemer er kun begyndelsen. Den samme tankegang gælder forebyggelse. Lad os se på et eksempel. Ved at give udviklerne de rette værktøjer dér, hvor koden bliver skrevet – i det integrerede udviklingsmiljø (IDE) – kan vi forhindre problemer, før de opstår. Og når det gælder de sårbarheder, der alligevel slipper igennem, hvorfor så ikke give udviklerne rettelser, der er klar til at blive flettet ind, for de sårbarheder, der betyder mest? Det er de udfordringer, vi arbejder på at løse, med det mål gradvist at nedbringe den eksisterende pukkel og skabe den hurtigst mulige effekt med mindst mulig indsats.

Koden kører. Kan du følge med?

AI har givet angriberne en gave i form af hastighed. Den måde, vi lukker det gab på, er ikke ved at tilføje endnu et værktøj. Det handler om en beslutning om, hvordan hele organisationen udvikler og sikrer software. Den kode, der skrives i dag, kommer til at drive virksomheden i årevis. Sikkerhedschefernes spørgsmål er ikke længere, hvor meget hurtigere AI hjælper dem med at udvikle. Spørgsmålet er, om deres programmer kan følge med det, AI skaber.

Lad dig derfor ikke fortabe i tallene. Stil tre spørgsmål til ethvert program: Kan jeg stole på det, programmet finder? Finder det nok af det, der er vigtigt? Er det realistisk at implementere i hele organisationen? Kombinationen af deterministisk præcision og avanceret ræsonnement giver dig den bedste mulighed for at kunne svare ja til alle tre spørgsmål.

Softwareudviklingen går ikke langsommere. Vores opgave er nu at lukke risikogabet: afstanden mellem, hvor hurtigt software skabes, og hvor hurtigt risici opdages og afhjælpes.