KI-sikkerhet trenger en ny vurdering

KI skriver programvare raskere enn vi klarer å sikre den. Henger du med?

Innen du er ferdig med å lese denne setningen, vil utviklere og KI-agentene deres ha pushet et par tusen kode-commits. På samme tid i fjor ville tallet ha vært rundt 150.

Det siste året har KI-generert programvare utviklet seg i et forbløffende tempo. GitHub registrerte 7,38 milliarder commits bare i september 2026, mer enn fem ganger så mange som året før. Sikkerhetskonsekvensene av denne eksplosive veksten er omfattende. Hver eneste av disse commitene inneholder kode som noen forventes å forstå, vedlikeholde og sikre. Cloud Security Alliance fant at utviklere som bruker KI i Fortune 50-selskaper, committer kode tre til fire ganger så ofte som kollegene sine, samtidig som antallet sikkerhetsfunn per måned økte omtrent tidoblet.

Tenk nå på hvem som må håndtere denne økningen. CISO-teamet er like stort som for et år siden, men etterslepet har vokst. Det kommer inn stadig flere sårbarhetsrapporter, antallet rettinger per måned går ned, og antallet uløste kritiske funn øker. Det er ikke rart at Gartner sier at utbrenthet blant CISO-er er i ferd med å bli en kritisk operasjonell risiko.

Fristelsen til å velge den nyeste modellen

Når tallet er så høyt, er det lett å ville jage et enda høyere tall: flere funn, bredere dekning, flere skanninger. Men det er som å øse vann ut av en båt som synker og be om en større bøtte, når du egentlig må finne lekkasjen. Et sikkerhetsprogram måles ikke etter hvor mye det finner. Det måles etter hvor mye av det det finner som er reelt, og hvor mange av de mest kritiske funnene som faktisk blir rettet.

De mest avanserte KI-modellene er svært gode til å finne nye måter å utnytte sårbarheter på og feil som ikke er katalogisert, ved hjelp av probabilistisk resonnering. Men resultatene varierer. Kjør den samme skanningen på den samme koden fem ganger, og funnene samsvarer bare omtrent én av tre ganger, ifølge Checkmarx’ forskning.

Denne inkonsekvensen er grunnen til at regelbasert analyse fortsatt er viktig. Den er mindre fleksibel enn de mest avanserte KI-modellene, men bruker velprøvd logikk på samme måte hver gang, slik at teamene kan stole på og etterprøve resultatene. KI fanger opp det reglene overser, som kjente svakheter i ukjente former eller feil som bare kan utnyttes når ulike deler av koden samvirker. Sammen avdekker KI og regelbasert analyse flere av de viktige funnene, med færre falske alarmer.

Dette er ikke et argument mot KI. Det er et argument for at sikkerhet trenger en ny vurdering. Uansett hvilken motor du velger, bør du stille den tre spørsmål.

Spørsmål én: Pålitelighet

Når skanneren sier at noe er galt, er det verdt tiden din?

Pålitelighet handler om tillit. Et funn som ikke er reelt, koster en utvikler en ettermiddag og svekker sikkerhetsteamets troverdighet. I stor skala får falske positive teamene til å slutte å lytte. Varslene blir bare «ulv, ulv» og forsvinner i bakgrunnsstøyen.

Det er her konsistens blir viktig. Deterministisk analyse gir samme svar hver gang den kjøres på den samme koden, noe som bygger tillit og gjør resultatene etterprøvbare.

Spørsmål to: Nøyaktighet

Finner du alle problemene som betyr mest?

Pålitelighet forteller deg om et funn er verdt tiden din, men ikke hva skanneren overså. Vi bruker et praktisk måltall med røtter i datavitenskap, kalt F1-skår. F1 måler ytelsen på en skala fra 1 til 0, basert på to faktorer:

• Presisjon: andelen rapporterte funn som er reelle. Høy presisjon betyr færre falske alarmer.
• Gjenfinning: andelen reelle sårbarheter som skanneren faktisk finner. Høy gjenfinning betyr at lite slipper gjennom.

En skanner kan virke presis ved å flagge nesten ingenting, eller grundig ved å flagge alt, men F1-skåren blir lav i begge tilfeller. Bransjegjennomsnittet er omtrent 0,20. Vi har jobbet hardt med denne utfordringen og sett resultater med en nøyaktighet som er tre til fire ganger så høy som hos en standardskanner.

Bedre nøyaktighet gjør alt som følger enklere for utviklerne. Teamet ditt bruker mindre tid på å kontrollere funn og mer tid på å rette dem.

Spørsmål tre: Avkastning på investering (ROI)

Hvordan får vi mest mulig ut av investeringene og ressursene våre?

Dette er spørsmålet som oftest blir hoppet over i pilotfasen, og som det gjør mest vondt å besvare i produksjon.

De mest avanserte modellene fakturerer per token, og tokenene brukes uansett om en skanning finner noe eller ikke. Det koster mer enn tusen dollar å skanne et repositorium med én million kodelinjer, basert på de publiserte prisene som gjelder nå. Det er også stor forskjell på hvor mange tokens modellene bruker; prisen varierer etter hvilken modell du velger, og hvor mye den må resonnere for å fullføre oppgaven.

Gang dette opp med alle commitene, pull-forespørslene og repositoriene i en stor bedrift. Uber, som bruker 3,4 milliarder dollar i året på R&D, skal angivelig ha brukt opp hele KI-budsjettet for 2026 i løpet av få måneder etter at selskapet tok i bruk KI-verktøy for programmering.

Vi kaller dette tokenavgiften. Det er som å bruke en Ferrari til å handle dagligvarer: Du betaler for kraft du ikke trenger på turen. Hardkodede påloggingsopplysninger og SQL-injeksjon følger forutsigbare mønstre som deterministisk analyse håndterer pålitelig.

Applikasjonssikkerheten må utvikles

Dette er tankegangen bak arkitekturen til Checkmarx Fusion. Regelbaserte motorer fastslår grunnsannheten på en reproduserbar måte og til en lavere kostnad enn tokenbasert analyse. Frontmodeller brukes til å håndtere det regler ikke kan forutse: nye mønstre, kompleks logikk og utnyttbarhet i kontekst. Deretter samler et lag for funnanalyse resultatene i ett pålitelig sett.

Deterministisk analyse gir sikkerhet. KI gir større rekkevidde. Dekningen øker, og tilliten styrkes. Sammenlignet med en LLM som arbeider alene ser vi opptil fire ganger høyere resultatkvalitet, to til fire ganger så høy nøyaktighet og omtrent en tredel av kostnaden.

Å finne problemer er bare begynnelsen. Den samme logikken gjelder forebygging. La oss ta et eksempel. Ved å gi utviklerne bedre verktøy mens de skriver koden, direkte i utviklingsmiljøet (IDE-et), kan vi stanse problemer før de oppstår. Og når det gjelder sårbarhetene som likevel slipper gjennom, hvorfor ikke gi utviklerne rettelser som er klare til å flettes inn, for de sårbarhetene som betyr mest? Dette er utfordringene vi jobber med å løse, med mål om gradvis å redusere det eksisterende etterslepet og oppnå raskest mulig effekt med minst mulig innsats.

Koden kjører allerede. Klarer du å holde følge?

KI ga angriperne fordelen av økt hastighet. Løsningen på dette gapet er ikke enda et verktøy. Det handler om en beslutning om hvordan hele organisasjonen utvikler og sikrer programvare. Koden som skrives i dag, skal drive virksomheten i årevis. Spørsmålet for sikkerhetsledere er ikke lenger hvor mye raskere KI hjelper dere med å utvikle programvare. Spørsmålet er om sikkerhetsprogrammene deres klarer å holde tritt med det KI skaper.

Ikke la deg blende av tallene. Still tre spørsmål om ethvert program: Kan jeg stole på det det finner? Finner det nok av det som er viktig? Er det realistisk å innføre det i hele organisasjonen? Ved å kombinere deterministisk presisjon med frontmodellenes resonnering får du best mulighet til å svare ja på alle tre spørsmålene.

Programvareutviklingen går ikke saktere. Jobben vår nå er å lukke risikogapet: avstanden mellom hvor raskt programvare utvikles, og hvor raskt risikoer oppdages og håndteres.