Azuls rapport om AI-sårbarhedskløften for 2026 viser, at virksomhederne halter bagefter AI-truslerne med sikkerhedsrettelser

Azuls rapport om AI-sårbarhedskløften for 2026 viser en forskel mellem den hastighed, sikkerhedsledere mener, at angribere med AI-værktøjer kan arbejde med, og den tid, deres organisationer har brug for til at udrulle rettelser. I en undersøgelse blandt 300 amerikanske sikkerhedsledere svarede 69 %, at angribere kunne udvikle en fungerende udnyttelse inden for tre dage, mens 44 % svarede, at deres organisationer skal bruge fire dage eller mere på at rette en kritisk sårbarhed i hele produktionsmiljøet.

Rapportens mest slående resultat er de erfaringer, som respondenterne forbinder med forsinkelserne: 85 % rapporterede en hændelse, en formodet hændelse eller en nærved-hændelse, der skyldtes langsom udrulning af sikkerhedsrettelser. Tallet beskriver rapporterede erfaringer, ikke en uafhængigt verificeret andel af sikkerhedsbrud, og det fastslår ikke, at AI forårsagede disse hændelser.

Undersøgelsen er bestilt af Azul og gennemført af Censuswide og fokuserer på organisationer med omfattende Java-udrulninger. Det overordnede budskab handler om driften: At opdage en sårbarhed er kun begyndelsen. En rettelse skal bestå test, nå frem til de berørte systemer og lukke sikkerhedshullet på tværs af et systemlandskab, som teams måske ikke har fuldt overblik over.

To tidslinjer, der ikke stemmer overens

Undersøgelsen skelner mellem ledernes forventninger til angriberne og deres egne organisationers evne til at udrulle rettelser:

• 69 % mener, at angribere med AI-værktøjer kan udvikle en udnyttelse på tre dage eller mindre. Heraf angiver 22 %, at det kan ske på under 24 timer.
• 56 % siger, at de kan udrulle en kritisk sikkerhedsrettelse i hele produktionsmiljøet inden for tre dage: 13 % på under 24 timer og 43 % på én til tre dage.
• 44 % har brug for længere tid: 32 % skal bruge fire til seks dage, og 12 % skal bruge endnu længere tid.

Tallene viser fordelingen af undersøgelsens svar, ikke målinger af angribere, der forsøger at komme bestemte organisationer i forkøbet med hensyn til de samme sårbarheder. Forskellen giver grund til bekymring for beredskabet, men bør ikke opfattes som et præcist eksponeringsvindue på tre dage for alle virksomheder.

Den samme ubalance viser sig ved grænsen på én dag: 22 % forventer, at angribere kan handle så hurtigt, mens 13 % siger, at deres organisation kan udrulle en rettelse inden for tidsrammen. Samtidig erkender 59 %, at AI-drevne angrebsværktøjer øger deres eksponering, uden at de har ændret deres sikkerhedstilgang.

Test er en væsentlig del af forsinkelsen

Test af opdateringer til Java-runtimemiljøer føjer mindst fire dage til rettelsescyklussen hos 58 % af de undersøgte organisationer. Det omfatter 36 %, der rapporterer fire til seks dage, og 22 %, der rapporterer en uge eller mere. Yderligere 33 % rapporterer én til tre dage, og 9 % mindre end 24 timer. Ingen respondenter sagde, at test blev sprunget over.

Ændringer i runtime-miljøer kan påvirke mange applikationer, så test har et praktisk formål: En sikkerhedsopdatering, der forstyrrer en kritisk tjeneste, skaber endnu et driftsproblem. Rapporten fremfører, at opdateringernes omfang bidrager til denne byrde, fordi kvartalsvise fulde OpenJDK-udgivelser kan indeholde ændringer, der ikke vedrører sikkerhed, sideløbende med rettelser af sårbarheder.

Azul vurderede særskilt 26 kvartalsvise OpenJDK-opdateringer over en periode på mere end seks år og klassificerede seks af dem som årsag til en alvorlig regression. Tallet på 23 % er leverandørens vurdering af udgivelserne, ikke et estimat baseret på en undersøgelse af, hvor ofte en enkelt kundes applikation vil holde op med at fungere.

Blandt de største rapporterede hindringer for hurtigere udrulning af sikkerhedsrettelser nævner 44 % omfattende test, 40 % kompleksiteten eller alderen på de berørte systemer og 36 % begrænset overblik over kendte sårbarheder. Forsinkelser med sikkerhedsrettelser fra leverandører blev nævnt af 25 %. Mønstret viser, at en stor del af udfordringen med at afhjælpe sårbarheder ligger i virksomhedens egen udrulningsproces.

Hændelsesrapporter og mangelfuldt overblik over systembeholdningen skal fortolkes forskelligt

55 % rapporterer en bekræftet hændelse, der skyldtes langsom udrulning af sikkerhedsrettelser, og 53 % rapporterer en nærved-hændelse. Respondenterne kunne vælge flere svar, så tallene overlapper og bør ikke lægges sammen. Det overordnede tal på 85 % omfatter også formodede hændelser.

Undersøgelsen fastslår ikke, at alle disse hændelser involverede Java-sårbarheder. Deltagerne arbejder i organisationer med omfattende brug af Java, men undersøgelsen indeholder både spørgsmål om udrulning af softwareopdateringer generelt og spørgsmål specifikt om Java-runtimemiljøer.

Et andet problem er overblikket over systembeholdningen. Kun 19 % siger, at mindst 90 % af deres Java-runtimemiljøer i produktionsmiljøet er på det nyeste sikkerhedsrettelsesniveau. Det betyder, at 81 % ligger under denne grænse; det betyder ikke, at 81 % slet ikke har opdaterede runtime-miljøer. Omkring hver femte siger, at halvdelen eller mindre af deres systembeholdning er opdateret.

Separat erkender 51 % kun at have delvist eller begrænset overblik over kritiske Java-runtimemiljøer, herunder indlejrede, ældre og ikke-administrerede installationer. Det kan være sværere at finde et sårbart runtime-miljø i en pakketeret applikation eller container end at identificere en centralt administreret installation. En sikkerhedsrettelse kan ikke lukke et sikkerhedshul på et system, som udrulningsprocessen aldrig når frem til.

Hvad Azuls teknologi bidrager med til diskussionen

Azuls tilbud om sikkerhedsopdateringer begrænser udvalgte udgivelser til sikkerhedsrettelser på et tidligere stabiliseret OpenJDK-grundlag. Virksomheden leverer kvartalsvise, målrettede månedlige og ekstraordinære opdateringer med det formål at reducere mængden af uvedkommende ændringer, som virksomheder skal vurdere, når de implementerer en presserende rettelse.

Det er en mere afgrænset teknisk indsats end at fjerne behovet for ændringsstyring. Begrænsning af kodeændringer kan mindske omfanget af valideringen, men applikationsspecifikke kontroller, ansvar for implementeringen og forberedelse af tilbagerulning er stadig vigtige. Azul er rapportens sponsor og sælger produkter, der adresserer de problemer, den måler.

Virksomhedens værktøjer til Java-inventar og sårbarheder adresserer den anden del af arbejdsgangen: at identificere kørselsmiljøer, versioner og eksponering, så en ny sårbarhedsmeddelelse kan knyttes til de berørte systemer. Rapporten indeholder ikke en kontrolleret sammenligning, der viser, hvor meget de adspurgte organisationer ville forbedre sig ved at tage produkterne i brug.

»Vores undersøgelse viser, at sikkerhedsledere forstår truslen: Bevidsthed er ikke længere problemet; det er gennemførelsen,« sagde Scott Sellers, Azuls medstifter og administrerende direktør.

Gør intentionen om hurtigere rettelser til en målbar proces

I det kommende år peger 32 % på hurtigere og hyppigere rettelser som deres primære strategi til at reducere eksponeringen, mens 26 % foretrækker bedre overblik over software og kørselsmiljøer. Yderligere 17 % prioriterer detektion og reaktion frem for hurtigere rettelser.

Undersøgelsen peger på, at man bør følge hele forløbet fra offentliggørelse til afhjælpning: hvilke systemer der er berørt, hvem der har ansvaret for dem, hvilke test der er nødvendige, og om rettelsen rent faktisk er nået i produktion. En tidsfrist er kun nyttig, hvis teams kan kontrollere, at arbejdet er fuldført på tværs af det relevante systemlandskab.

De amerikanske resultater bygger på feltarbejde udført 3.–7. august 2026 blandt sikkerhedsledere i organisationer med mindst 1.000 ansatte og betydelig produktionsbrug af Java/JVM. Der er tale om selvrapporterede svar fra en afgrænset population, ikke en optælling af alle virksomheder eller en direkte måling af udviklingen af udnyttelseskode.

Den fulde Rapport om AI-sårbarhedsgabet 2026 beskriver resultaterne og metoden. Den tydeligste konklusion er, at hastigheden på rettelser og synligheden af kørselsmiljøer skal forbedres samtidig: En hurtig rettelse har begrænset værdi, hvis organisationen ikke kan identificere alle berørte installationer eller bekræfte, at opdateringen er nået frem.