AI ændrer åbent kildekode-sikkerhed. Software-livscyklus-ansvar skal ændres med det.

Når Drupal offentliggjorde CVE-2026-9082 i maj, blev forsøg på at udnytte det rapporteret inden for 48 timer. Denne forkortede periode mellem offentliggørelse og udnyttelse illustrerer den nye virkelighed, som organisationer, der afhænger af åbent kildekode-software, står over for. De har mindre tid end nogensinde før til at vurdere risici og reagere, før sårbarheder aktivt målrettes.

AI accelererer denne udvikling ved dramatisk at øge hastigheden og omfanget af opdagelse af sårbarheder. Da opdagelsen af sårbarheder accelererer, bliver udfordringen for virksomhederne ikke længere kun at identificere sårbarheder; det er sikring af, at den software, de afhænger af, forbliver sikker, understøttet og robust på tværs af dens livscyklus.

AI accelererer trusler hurtigere, end virksomheder kan reagere

AI-drevne værktøjer accelererer opdagelsen af sårbarheder og sænker barrieren for udvikling af udnyttelser, hvilket reducerer den tid, organisationer har til at vurdere risici og reagere. Opdaterede brancheprojekter fra FIRST estimerer nu, at næsten 66.000 CVE’er vil blive offentliggjort i 2026, en revision på 11% opad fra februar-prognosen, efter at offentliggørelserne lå 46% over den forventede takt gennem april.

FIRST bemærker rettelig, at den eksploaterbare risiko ikke er vokset i samme takt som den rene mængde, og at KEV og EPSS-triagering kan absorbere øgningen. Men triagering og retning af fejl antager, at en retning findes. For software bygget på rammer, der er nået til enden af deres livscyklus, findes den ikke, og hele prioriteringsmodellen kollapser præcis på det punkt, hvor det betyder mest.

Mens sikkerhedsteams ikke opererer med maskinehastighed. De skal stadig afgøre, hvilke systemer er berørt, vurdere forretningsrisici, teste rettelser og installere opdateringer uden at forstyrre driften. For organisationer, der afhænger af åbent kildekode-software, bliver udfordringen endnu større, når forretningskritiske komponenter har nået enden af deres livscyklus og ikke længere modtager sikkerhedsopdateringer fra deres oprindelige vedligeholdere.

Resultatet er en vækst i gapet mellem identifikation af sårbarheder og faktisk afhjælpning af dem. Organisationer har brug for mere end indsigt i sårbarheder. De har brug for tillid til, at den software, de afhænger af, vil forblive sikker og understøttet på tværs af dens livscyklus.

Understøttet software bliver en voksende risiko for virksomheder

Mange organisationer fortsætter med at køre versioner af åbent kildekode-rammer som Drupal, Spring og AngularJS, fordi erstatning af forretningskritiske applikationer er dyrt, forstyrrende og ofte tager år at gennemføre.

Denne virkelighed kolliderer mere og mere med nye regulatoriske forventninger. Rammer som EU’s Cyber Resilience Act, DORA, NIS2 og PCI DSS 4.0 lægger større vægt på softwarevedligeholdelse, synlighed i forsyningskæden og fortsat software-understøttelse, hvilket gør understøttet software til en voksende compliance- og operationsmæssig bekymring.

Fordi modernisering ofte tager år, har organisationer brug for en strategi for at vedligeholde sikker, understøttet software under overgangen.

Organisationer har brug for livscyklus-synlighed, ikke kun sårbarheds-synlighed

De fleste organisationer har investeret massivt i værktøjer designet til at identificere sårbarheder på tværs af deres miljøer. Disse værktøjer besvarer spørgsmålet om, hvor sårbarhederne er. De besvarer ikke et andet spørgsmål, der bliver lige så vigtigt: Er denne software stadig understøttet?

At besvare dette spørgsmål kræver, at organisationer ser ud over sårbarhedsstyring. De har brug for indsigt i, om forretningskritiske åbent kildekode-komponenter stadig vedligeholdes, nærmer sig enden af deres livscyklus eller ikke længere modtager community-understøttelse, og en strategi for at holde disse systemer sikre, indtil moderniseringen er fuldført.

Virksomhedsledere bør fokusere på tre prioriteter:

• Vid, hvad du ejer. Identificer understøttet software, før sårbarheder, audits eller incidenter tvinger spørgsmålet, og forstå, hvilke forretningskritiske applikationer afhænger af det.
• Planlæg en sikker modernisering. Byg livscyklusplanlægning ind i indkøbs-, udviklings- og moderniseringsstrategier med klare planer for at vedligeholde softwaren sikker på tværs af overgangen.
• Behandle software-understøttelse som en forretningsprioritet. Da software-økosystemer bliver mere komplekse, bør langsigtede software-understøttelse behandles som en strategisk forretningskapacitet og ikke kun som en teknisk bekymring.

AI ændrer, hvordan software bygges, hvordan sårbarheder opdages, og hvor hurtigt organisationer forventes at reagere. Det, der ikke er ændret, er virksomhedens ansvar for at vedligeholde den software, virksomheder allerede afhænger af, på en sikker måde. Da AI omformulerer åbent kildekode-sikkerhed, afhænger succes af, at software-livscyklus-ansvar behandles som en kerne-sikkerhedsfunktion, ikke kun en teknisk overvejelse.

De organisationer, der lykkes, er ikke nødvendigvis dem, der retter fejl hurtigst. De er dem, der kan håndtere software-risici på tværs af hele livscyklusen med tillid, holde forretningskritiske applikationer sikre og operative, mens de moderniserer på deres egne betingelser.