Azuls rapport om gapet i KI-sårbarheter for 2026 viser at virksomhetenes sikkerhetsoppdateringer henger etter KI-truslene

Azuls 2026-rapport om gapet i KI-sårbarheter avdekker et misforhold mellom hvor raskt sikkerhetsledere mener angripere utstyrt med KI kan handle, og hvor lang tid organisasjonene deres trenger på å installere rettelser. I en undersøkelse blant 300 amerikanske sikkerhetsledere svarte 69 % at angripere kunne utvikle en fungerende utnyttelse innen tre dager, mens 44 % sa at organisasjonene deres trenger fire dager eller mer på å rette en kritisk sårbarhet i produksjonsmiljøet.

Rapportens mest slående funn gjelder respondentenes erfaringer med disse forsinkelsene: 85 % rapporterte om en hendelse, en mistenkt hendelse eller et nesten-uhell som de knyttet til treg installering av sikkerhetsoppdateringer. Tallet beskriver rapporterte erfaringer, ikke en uavhengig bekreftet andel sikkerhetsbrudd – og det fastslår ikke at KI forårsaket disse hendelsene.

Undersøkelsen ble bestilt av Azul og gjennomført av Censuswide, og fokuserer på organisasjoner med omfattende Java-installasjoner. Det overordnede budskapet handler om drift: Å oppdage en sårbarhet er bare begynnelsen. En rettelse må bestå testing, nå frem til de berørte systemene og fjerne eksponeringen i et miljø som teamene kanskje ikke har full oversikt over.

To tidslinjer som ikke samsvarer

Undersøkelsen skiller mellom ledernes forventninger til angriperne og organisasjonenes egne muligheter til å installere oppdateringer:

• 69 % mener at angripere utstyrt med KI kan utvikle en utnyttelse på tre dager eller mindre. Dette inkluderer 22 % som mener at det kan skje på under 24 timer.
• 56 % sier at de kan installere en kritisk oppdatering i hele produksjonsmiljøet innen tre dager: 13 % på under 24 timer og 43 % på én til tre dager.
• 44 % trenger lengre tid: 32 % trenger fire til seks dager, og 12 % trenger mer tid.

Dette er fordelinger av svar i undersøkelsen, ikke målinger av angripere som konkurrerer mot bestemte organisasjoner om å utnytte de samme sårbarhetene. Forskjellen gir grunn til bekymring for beredskapen, men bør ikke tolkes som et nøyaktig eksponeringsvindu på tre dager for alle virksomheter.

Den samme ubalansen viser seg ved en grense på én dag: 22 % forventer at angripere kan handle så raskt, sammenlignet med 13 % som sier at organisasjonen deres kan installere en rettelse innenfor dette tidsrommet. Samtidig erkjenner 59 % at KI-drevne angrepsverktøy øker eksponeringen, uten at de har endret sikkerhetstilnærmingen sin.

Testing bidrar vesentlig til forsinkelsen

Testing av oppdateringer for Java-kjøremiljøer legger til fire dager eller mer i oppdateringssyklusen hos 58 % av organisasjonene i undersøkelsen. Dette inkluderer 36 % som oppgir fire til seks dager, og 22 % som oppgir en uke eller mer. Ytterligere 33 % oppgir én til tre dager, og 9 % under 24 timer. Ingen respondenter sa at testingen ble hoppet over.

Endringer i kjøremiljøet kan påvirke mange applikasjoner, så testing har et praktisk formål: En sikkerhetsoppdatering som forstyrrer en kritisk tjeneste, skaper et nytt driftsproblem. Rapporten hevder at omfanget av oppdateringene bidrar til denne belastningen, fordi fullstendige kvartalsvise OpenJDK-utgivelser kan inneholde andre endringer enn sikkerhetsrettelser.

Azul vurderte separat 26 kvartalsvise OpenJDK-oppdateringer over mer enn seks år og klassifiserte seks av dem som årsak til en alvorlig regresjon. Tallet på 23 % er leverandørens vurdering av utgivelsene, ikke et anslag basert på undersøkelsen over hvor ofte en enkelt kundes applikasjon vil slutte å fungere.

Blant de største hindringene for raskere installering av sikkerhetsoppdateringer oppgir 44 % omfattende testing, 40 % kompleksiteten eller alderen på berørte systemer og 36 % begrenset oversikt over kjente sårbarheter. Forsinkelser i leverandørenes oppdateringer ble oppgitt av 25 %. Mønsteret viser at en stor del av utfordringen med utbedring ligger i virksomhetenes egne prosesser for å installere oppdateringer.

Hendelsesrapporter og mangler i oversikten må tolkes hver for seg

55 % rapporterer om en bekreftet hendelse som de knytter til treg installering av sikkerhetsoppdateringer, og 53 % rapporterer om et nesten-uhell. Respondentene kunne velge flere svar, så tallene overlapper og bør ikke legges sammen. Den bredere overskriftsandelen på 85 % inkluderer også mistenkte hendelser.

Undersøkelsen fastslår ikke at alle disse hendelsene involverte Java-sårbarheter. Deltakerne jobber i organisasjoner med omfattende bruk av Java, men undersøkelsen omfatter også spørsmål om programvareoppdateringer mer generelt, i tillegg til spørsmål spesifikt om Java-kjøremiljøer.

En annen utfordring er oversikten over installasjonene. Bare 19 % sier at minst 90 % av Java-kjøremiljøene i produksjon har det nyeste sikkerhetsoppdateringsnivået. Det betyr at 81 % ligger under denne terskelen, ikke at 81 % ikke har noen oppdaterte kjøremiljøer. Omtrent én av fem sier at halvparten eller mindre av miljøet deres er oppdatert.

Separat oppgir 51 % at de har delvis eller begrenset oversikt over kritiske Java-kjøremiljøer, inkludert innebygde, eldre og ikke-administrerte forekomster. Det kan være vanskeligere å finne et sårbart kjøremiljø i en pakket applikasjon eller beholder enn å identifisere en sentralt administrert installasjon. En oppdatering kan ikke fjerne eksponeringen på et system som prosessen for installering av oppdateringer aldri når frem til.

Hva Azul-teknologien tilfører diskusjonen

Azuls tilbud om sikkerhetsoppdateringer begrenser utvalgte utgivelser til sikkerhetsrettinger for en tidligere stabilisert OpenJDK-baseline. Selskapet tilbyr kvartalsvise, målrettede månedlige og ekstraordinære oppdateringer, med mål om å redusere mengden uvedkommende endringer virksomheter må vurdere når de installerer en kritisk retting.

Dette er et mer avgrenset teknisk tiltak enn å fjerne behovet for endringskontroll. Færre kodeendringer kan redusere omfanget av valideringen, men applikasjonsspesifikke kontroller, ansvar for utrulling og forberedelser til tilbakerulling er fortsatt viktige. Azul sponser rapporten og selger produkter som retter seg mot problemene den måler.

Verktøyene deres for Java-inventar og sårbarheter retter seg mot den andre delen av arbeidsflyten: å identifisere kjøremiljøer, versjoner og eksponering, slik at en ny sårbarhetsavsløring kan knyttes til berørte systemer. Rapporten inneholder ingen kontrollert sammenligning som viser hvor mye organisasjonene som deltok i undersøkelsen, ville forbedret seg ved å ta i bruk disse produktene.

«Forskningen vår viser at sikkerhetsledere forstår trusselen: Bevissthet er ikke lenger gapet; det er gjennomføringen», sa Scott Sellers, medgrunnlegger og administrerende direktør i Azul.

Fra intensjon om oppdatering til en målbar prosess

For det kommende året peker 32 % på raskere og hyppigere oppdateringer som sin viktigste strategi for å redusere eksponeringen, mens 26 % foretrekker bedre oversikt over programvare og kjøremiljøer. Ytterligere 17 % prioriterer oppdagelse og håndtering fremfor raskere oppdateringer.

Undersøkelsen peker på at man bør følge hele veien fra sårbarhetsavsløring til utbedring: hvilke systemer som er berørt, hvem som har ansvaret for dem, hvilke tester som kreves, og om rettingen faktisk ble satt i produksjon. En frist er bare nyttig når teamene kan bekrefte at arbeidet er fullført på tvers av hele den relevante systemparken.

Funnene fra USA bygger på feltarbeid gjennomført 3.–7. august 2026 blant sikkerhetsledere i organisasjoner med minst 1 000 ansatte og betydelig bruk av Java/JVM i produksjon. Dette er selvrapporterte svar fra en definert gruppe, ikke en fullstendig opptelling av virksomheter eller en direkte måling av utvikling av utnyttelseskode.

Den fullstendige rapporten om gapet mellom AI og sårbarheter i 2026 beskriver funnene og metoden. Den tydeligste konklusjonen er at både oppdateringshastigheten og oversikten over kjøremiljøer må forbedres: En rask retting har begrenset verdi hvis organisasjonen ikke kan identifisere alle berørte utrullinger eller bekrefte at oppdateringen nådde dem.