Blogg

En AI‑drevet sårbarhetsstorm er på vei 

Kunstig intelligens har flyttet sikkerhetsarbeidet fra planlagte sykluser til et kappløp mot tiden. I praksis betyr det at tiden fra en sårbarhet oppstår til den blir utnyttet, er blitt dramatisk kortere. Samtidig er tradisjonelle oppdateringsprosesser og etablerte sikkerhetsforutsetninger under press. Denne artikkelen forklarer hva som driver utviklingen, fra AI med sikkerhetskapasiteter til stadig raskere patching, og hvilke konsekvenser det får for sikkerhetsarkitektur og styring. Den beskriver også hvilke konkrete tiltak organisasjoner bør prioritere for å redusere eksponering nå.

I april 2026 lanserte Anthropic Claude Mythos Preview, en intern modell som på egen hånd oppdaget zero‑day‑sårbarheter i alle større operativsystemer og nettlesere. I testing oppnådde modellen en utnyttelsesrate på 72,4 prosent mot Firefox, og avdekket blant annet en 27 år gammel sårbarhet i OpenBSD. (2). Om Mythos faktisk er akkurat det selskapet hevder (og rapporter fra uavhengige partnere tyder på at det langt på vei er tilfelle) eller om det viser seg å være den mest effektive markedsføringskampanjen i teknologihistorien, er retningen uansett ikke lenger til å misforstå. En modell i denne klassen finnes enten allerede eller er svært nær. Asymmetrien den skaper er strukturell, ikke midlertidig.

Kort tid etter lanserte også Microsoft et svært avansert AI‑system som toppet en ledende bransjetest, MDASH. Det er et system bestående av mer enn hundre spesialiserte AI‑agenter (9). Siden dette først ble kjent da det ble offentliggjort, er det god grunn til å tro at det vi vet om kapasitetene deres bare er en del av det reelle bildet.

AI krymper tiden fra sårbarhet til utnyttelse

Tenk over hva dette betyr i praksis. Gjennomsnittlig tid fra en sårbarhet blir offentliggjort til den blir bekreftet utnyttet, har falt fra nesten ett år i 2021 til litt over én dag i 2026, med en forventet utvikling mot én time, og deretter ett minutt. Andelen sårbarheter som allerede var i bruk da de ble offentliggjort, har økt fra 31 prosent for fem år siden til 73,2 prosent i dag. Antallet offentliggjorte sårbarheter som fortsatt ikke er utnyttet etter seks uker, har i praksis falt til null (1).

Denne utviklingen skyldes ikke at angripere generelt har blitt smartere. Den skyldes at AI nå brukes målrettet i sårbarhetsutforskning, og utviklingen har økt bratt til de siste tolv månedene.

AI senker både kostnaden og kompetansekravet for å finne angrepsveien langt raskere enn noen organisasjon klarer å stenge dem. I en test av sårbarheter i Firefox genererte Claude Mythos Preview 181 fungerende exploits, der forrige generasjon klarte to (3). Dette er ikke en gradvis forbedring. Det er et tydelig sprang i autonomi og pålitelighet, og det vil ikke være det siste.

Sikkerhetsmodeller bygget for en verden som ikke lenger finnes

Budskapet er ubehagelig, men viktig å ta inn over seg. Mange sikkerhetsprogrammer bygger på forutsetningene med ukentlige oppdaterings-sykluser, kvartalsvise penetrasjonstester, hendelseshåndtering i menneskelig tempo, trusselinformasjon basert på CVEer. Disse er utviklet for en verden som ikke lenger finnes. En angriper trenger én fungerende angrepsvei. En forsvarer må lukke dem alle.

Oppdaterings‑bølgen har startet, men den skalerer ikke

Anthropics respons, Project Glasswing, ga rundt femti leverandører av kritisk infrastruktur og forvaltere av åpen kildekodeprosjekter tidlig tilgang til å rette sårbarheter før offentliggjøring. I løpet av den første måneden identifiserte partnerne mer enn 10 000 sårbarheter med høy eller kritisk alvorlighetsgrad (4). Dette er den største koordinerte innsatsen for håndtering av sårbarheter noensinne. Samtidig er den, per definisjon, ikke tilstrekkelig. De fleste organisasjoner som utvikler eller vedlikeholder kritisk programvare, vil aldri være en del av et slikt program. Fordelen ved tidlig tilgang er dessuten tidsbegrenset.

Tilsvarende offensive kapabiliteter forventes å komme i andre avanserte modeller i løpet av måneder, og i åpne modeller innen seks til tolv måneder.

Det finnes også en annen effekt som er viktig å være oppmerksom på: Hver oppdatering er i praksis en oppskrift på et angrep. AI gjør det raskere å analysere endringer og forstå hvordan feil er rettet. Dermed starter ikke kappløpet ved offentliggjøring, men allerede idet endringen legges inn i koden.

Hva betyr dette for din organisasjon?

I ukene og månedene som kommer, vil partnerne i Glasswing og resten av økosystemet som følger etter slippe kritiske oppdateringer i et volum bransjen aldri har sett tidligere. Palo Alto Networks har allerede publisert mer enn fem ganger så mange oppdateringer som i en normal syklus, og Microsoft har signalisert at volumet vil fortsette å øke (5).

Hvis oppdaterings-programmet ditt allerede er presset, teamet ditt er underbemannet, eller hvis endringsprosesser fortsatt tar uker, vil denne bølgen komme raskere enn dere klarer å håndtere den. Det er viktig å gjøre forberedelser nå, før sårbarhetene offentliggjøres. Kapasiteten til å prioritere, automatisere utrulling, godkjenne endringer og håndtere rollback må fungere i et langt høyere tempo enn tidligere.

Organisasjoner som har gjort dette forarbeidet og som opererer med en Zero Trust‑tilnærming basert på «assume breach» vil kunne henge med på bølgen. De som ikke har det, vil havne bakpå. I dette landskapet er det nettopp slik eksponering oppstår.

Når oppdateringen ikke rekker frem i tide

Når oppdaterings-vinduet krymper til timer, er ikke spørsmålet lenger hvor raskt du kan legge inn en oppdatering, men hva du gjør når det ikke er mulig.

Svaret ligger i arkitekturen, i kontrollmekanismer som begrenser skade uansett hvilken sårbarhet som utnyttes. Det er kjernen i Zero Trust: behandle alle miljøer som potensielt kompromittert, alle identiteter som uverifiserte som standard, og enhver vellykket tilgang som et delvis brudd.

Det kan også være nyttig å jobbe med avledningstiltak. Utlokkingsdata, falske systemer og andre lokkemidler gjør det mulig å oppdage angripere basert på hva de faktisk gjør, ikke forhåndsdefinerte mønstre. Derfor fungerer de også mot helt nye sårbarheter som ennå ikke er kjent.

Dette er ikke nye anbefalinger. Det som har endret seg, er kostnaden ved å ikke ha dem på plass.

Forsvarerne må også bruke AI

Det ligger et paradoks i kjernen av situasjonen vi står i nå. En offensive bruken av AI er moden, dokumentert og i ferd med å bli bredt tilgjengelig. Defensive AI‑produkter, utviklet for å oppdage AI‑genererte angrep eller håndtere hendelser autonomt, ligger etter, utvikles saktere og er ofte knyttet til én leverandørs økosystem. Det er feil å vente til forsvarssiden tar igjen forspranget.

Det som betyr mest akkurat nå, er ikke spesialiserte sikkerhetsprodukter. Det er de samme kodeagentene og språkmodellene som angripere allerede bruker, bare brukt internt i egen organisasjon.

Det første steget er det enkleste. Enhver organisasjon kan i dag bruke en agent til å gjennomgå sin egen kode for sårbarheter, og enhver organisasjon kan integrere sikkerhetskontroll drevet av språkmodeller i sin CI/CD‑pipeline, slik at både menneskeskrevet og AI‑generert kode går gjennom en konsekvent kontroll før den settes i produksjon. Dette er ikke lenger eksperimentelt. Det er det enkleste enkelttiltaket som reduserer avstanden mellom hvor raskt kode leveres og hvor raskt den blir gjennomgått.

Det neste steget er å gi modellen kontekst. En kodeagent uten kjennskap til virksomheten din er et generisk verktøy. En kodeagent som kjenner leverandørene dine, hvilke versjoner dere bruker, hvilke tjenester som avhenger av hvilke biblioteker, og hvilke systemer som er forretningskritiske, blir en kontinuerlig, asymmetrisk fordel.

Tenk over hva dette muliggjør. Agenten kan overvåke offentlige commits og sikkerhetsvarsler fra leverandørene i din teknologistack og flagge relevante endringer i det øyeblikket de skjer, ikke uker senere når en CVE blir tildelt. Den kan kartlegge oppstrøms og nedstrøms avhengigheter for en foreslått oppdatering opp mot ditt faktiske miljø, slik at du allerede vet hva den påvirker, hva den kan ødelegge og hva den beskytter, før den når endringsrådet. Den kan kontinuerlig gå gjennom egen kode og bruke de samme metodene som angripere, slik at dere selv oppdager sårbarhetene før de slipper ut.

Det tredje steget er operasjonelt. Kodeagenter kan allerede sette fart på arbeidet sikkerhetsteam gjør i det daglige ved å triagere og validere innkommende oppdateringer raskere enn mennesker klarer å håndtere. De kan gjennomføre red‑team‑øvelser mot eget miljø kontinuerlig, ikke kvartalsvis. Samtidig kan de samle inn revisjonsdata og dokumentasjon automatisk, og omdanne varselstøy til prioriterte hendelser med nødvendig kontekst.

Ingenting av dette krever en ny produktkategori. Det krever de samme agentene som allerede er i utstrakt bruk, gitt riktig tilgang, riktige instrukser og tydelige rammer.

Den langsiktige retningen peker mot det som begynner å bli omtalt som VulnOps. En permanent funksjon, bemannet og automatisert på samme måte som DevOps, med ansvar for kontinuerlig, AI‑drevet oppdagelse og utbedring av sårbarheter på tvers av hele programvareporteføljen. Å etablere dette er et tolv måneders prosjekt for de fleste organisasjoner. Å begynne å bygge kapasitet er et prosjekt du kan starte denne uken.

Under teknologien ligger det en kulturell endring som er like viktig som verktøyene selv. Alle sikkerhetsroller blir i økende grad også AI‑roller. Terskelen for å ta det i bruk er lavere enn mange tror. Team som tar dette i bruk tidlig, vil operere i maskinhastighet. Team som venter, vil fortsatt håndtere triagering manuelt, mens motstanderne deres ikke gjør det.

Kapasitets‑ og styringsavviket

I løpet av det neste året vil to mindre synlige endringer skille organisasjonene som tilpasser seg, fra de som sliter. Ingen av dem er tekniske.

Den første handler om kapasitet. Bransjen investerer tungt i AI‑kapabiliteter, inkludert avanserte modeller, agentinfrastruktur og utviklerverktøy. Den parallelle investeringen i menneskelig kapasitet til å håndtere det nye trusselbildet har ikke holdt tritt. Sikkerhetsteam må håndtere en eksponentiell økning i arbeidsmengde: mer kode som leveres raskere, flere sårbarheter som offentliggjøres, flere hendelser som må triageres, flere verktøy som må integreres, som regel uten tilsvarende økning i bemanning, budsjett eller støtte for arbeidsbelastning.

AI gir angripere fordeler som forsterker seg over tid. På forsvarssiden blir de altfor ofte absorbert som en ekstra belastning på de samme menneskene. Utbrenthet og tap av kompetanse i sikkerhetsmiljøer er ikke et HR‑problem. Det er en direkte operasjonell risiko, fordi kompetansen som kreves for å håndtere denne overgangen tar lang tid å bygge opp, og ikke lar seg erstatte raskt. Et sikkerhetsteam uten kapasitet til å utvikle seg, som er låst i en reaktiv rolle der de håndterer det resten av organisasjonen allerede har levert, blir en sårbarhet i det øyeblikket trusselbildet endrer seg. Det øyeblikket er nå.

Fra etterlevelse til ansvar

Den andre endringen gjelder styring, og den har nå fått en tydelig regulatorisk dimensjon. EUs AI Act innfører et risikobasert rammeverk med fire nivåer: uakseptabel risiko, høy risiko, begrenset risiko og minimal risiko. For de fleste virksomheter er det særlig kategorien høy risiko som er relevant (6). I henhold til artikkel 6, vedlegg III faller AI‑systemer brukt innen områder som kritisk infrastruktur, sysselsetting og arbeidsledelse, tilgang til essensielle tjenester, rettshåndhevelse og drift av biometriske eller sikkerhetskritiske komponenter inn i denne kategorien. Det utløser krav knyttet til risikostyring, datastyring, menneskelig kontroll, teknisk dokumentasjon, nøyaktighet, robusthet og cybersikkerhet.

For sikkerhetsledere er ikke dette et fremtidig problem. Etter hvert som AI‑drevet defensiv skanning blir allment tilgjengelig, endres også standarden for hva som anses som «rimelig aktsomhet». I økende grad må styrene ta stilling til om det er uaktsomt å ikke ta i bruk tilgjengelige AI‑verktøy.

Det praktiske startpunktet er enkelt. Kartlegg hvilke AI‑systemer som allerede er i bruk i organisasjonen, klassifiser dem etter risikonivåene i forordningen, og identifiser hvilke som faller inn under kategorien høy risiko. Dette arbeidet bør starte nå, fordi kravene til selvstendige høy‑risiko‑systemer etter vedlegg III trer i kraft 2. august 2026, sammen med egne krav til både leverandører og brukere (7).

Merk: EU har blitt enige om å utsette denne datoen til slutten av 2027 som en del av Digital Omnibus (8) men frem til denne endringen er formelt vedtatt, er 2. august 2026 gjeldende dato.

Begge endringene peker i samme retning. Å håndtere en AI‑drevet sårbarhetsstorm handler ikke bare om bedre verktøy og strammere arkitektur. Det handler om å investere i menneskene som skal bruke dem, og å rydde vei i styringsmodeller slik at de kan handle i det tempoet trusselbildet nå krever.

Konklusjon: dette har vi gjort før

Sikkerhetsbransjen har håndtert systemiske, tidskritiske utfordringer før. Y2K var en strukturell risiko med en fast deadline, og ble håndtert gjennom koordinert innsats, disiplinert og målrettet arbeid på tvers av tusenvis av organisasjoner. Mønsteret denne situasjonen krever, er det samme, med to forskjeller. Tidsfristen er kortere, og verktøyene forsvarerne har til rådighet, er kraftigere enn noen gang tidligere.

Å være forberedt på det som kommer etter Mythos handler mindre om å reagere på én modell eller én kunngjøring, og mer om å permanent redusere avviket mellom hvor raskt sårbarheter oppdages og hvor raskt en organisasjon kan reagere. Dette avviket lukkes ikke av seg selv. Det lukkes gjennom arkitektur som er designet for å begrense skade fremfor å forhindre alt, gjennom forsvarere som bruker AI like naturlig som angriperne gjør, gjennom investeringer i menneskene som driver arbeidet, og gjennom styringsmodeller som er raske nok til å holde tritt med trusselbildet.

Ingen av disse tiltakene krever at du venter. Alt kan starte denne uken. Organisasjoner som begynner å bygge denne kapasiteten nå, vil møte neste bølge på egne premisser. De som venter, vil møte stormen på stormens premisser.

AI Sikkerhet

Whitepaper

Cybersikker AI 2026

Gratis guide for sikker styring av AI

Omfattende guide for ledere, teknologiansvarlige og virksomhetsutviklere som ønsker å forstå hva AI betyr for egen organisasjon, utover hype og enkeltstående tekniske løsninger.

Les mer

Om våre eksperter