VEX og CSAF: revisionsklart bevismateriale for sårbarheder

07:40-meddelelsen, der gør en SBOM til et bestyrelsesanliggende

Kl. 07:40 en tirsdag morgen i begyndelsen af 2026 ser Anya, CISO i en hurtigt voksende fintech-platform, en kritisk leverandørmeddelelse ankomme i CSAF-format. Der er fundet en sårbarhed med fjernudførelse af kode i et udbredt open source-bibliotek. Hendes SBOM (Software Bill of Materials) bekræfter, at biblioteket er indlejret i flagskibsapplikationen til betalingsbehandling, to interne tjenester og en outsourcet analysekomponent.

Kl. 08:10 vibrerer hendes telefon. Udviklingsorganisationen vil vide, om den sårbare funktion kan nås. Compliance vil vide, om dette berører ISO/IEC 27001:2022, NIS2 eller DORA. Juridisk afdeling spørger, om Cyber Resilience Act kan kræve kommunikation til kunder eller myndigheder. Et bestyrelsesmedlem, der netop er blevet trænet i ledelsesansvar under NIS2, stiller spørgsmålet, alle tænker på:

Er vi berørt?

Det første svar fra udviklingsteamet er teknisk korrekt: pakken findes, men den sårbare funktion bliver muligvis ikke kaldt i produktionsmiljøet. I 2026 er det svar ikke nok.

Bestyrelsen ønsker dokumentation. Kunderne ønsker et klart svar. Indkøb vil vide, om leverandøren har opfyldt sine kontraktlige oplysningsforpligtelser. Databeskyttelsesrådgiveren (DPO) vil vide, om personoplysninger kan blive eksponeret. En ISO 27001-revisor vil ikke acceptere “udvikleren sagde det” som opbevaret bevismateriale. En DORA-revisor vil forvente, at sårbarheden kan knyttes til IKT-aktiver, kritiske funktioner og tredjepartsafhængigheder.

Det er her, VEX og CSAF ophører med blot at være tekniske formater og bliver styringsinfrastruktur.

CSAF, Common Security Advisory Framework, strukturerer sikkerhedsmeddelelser, så både mennesker og maskiner kan behandle berørte produkter, versioner, vejledning om afhjælpning, referencer og statusoplysninger. VEX, Vulnerability Exploitability eXchange, udgør beslutningslaget. Det fortæller interessenter, om en kendt sårbarhed faktisk kan udnyttes i et bestemt produkt, en bestemt tjeneste eller et bestemt miljø.

De praktiske VEX-statusser er enkle: berørt, ikke berørt, rettet og under undersøgelse. Styringen bag dem er ikke enkel. Hver status kræver bevismateriale, en ejer, en begrundelse, godkendelse og en udløser for gennemgang.

Efterlevelseshullet er ikke længere fraværet af SBOM’er. Mange organisationer har nu SBOM’er. Hullet består i at dokumentere, hvordan hver sårbarhedsmeddelelse blev triageret, hvem der godkendte statusbeslutningen, hvilket bevismateriale der understøttede en konklusion om “ikke berørt”, hvordan afhjælpning blev prioriteret, når produktet var “berørt”, og hvordan organisationen bevarede dette spor til revisorer, tilsynsmyndigheder, kunder og ledelsen.

Clarysec behandler VEX og CSAF som en del af ISMS-driftsmodellen. I Zenith Blueprint: En revisors 30-trins køreplan hører dette hjemme i faserne for risikostyring, leverandørsikkerhed, teknologiske kontroller og bevismateriale. I Zenith Controls: Den tværgående efterlevelsesguide kobles samme emne til ISO/IEC 27001:2022-kontroller, sikkerhed i IKT-forsyningskæden, sårbarhedsstyring, styring af bevismateriale, NIS2, DORA, GDPR og NIST-forventninger.

Hvorfor SBOM’er skaber signaler, men VEX skaber bevismateriale

En SBOM er en komponentfortegnelse. Den fortæller, hvad der findes i et produkt eller en tjeneste. Når en CVE optræder i en af disse komponenter, fortæller SBOM’en, at I muligvis er berørt.

Det signal er værdifuldt, men det er ikke en konklusion.

Et modent softwaremiljø kan generere tusindvis af SBOM-match på sårbarheder. Mange er reelle risici. Mange kan ikke udnyttes, fordi den sårbare kode ikke leveres, ikke importeres, ikke kan nås, ikke er konfigureret, ikke er eksponeret for ikke-betroede input eller er afbødet af kompenserende kontroller. Uden en formel proces til at registrere undersøgelsen falder teams typisk i et af to uhensigtsmæssige mønstre.

Det første er triageudmattelse. Udviklere jagter hvert sårbarhedsmatch med samme hastende karakter, selv når komponenten er en build-time-afhængighed, en inaktiv kodevej eller en funktion, der kun er intern og beskyttet af lagdelte kontroller.

Det andet er udokumenteret risikoaccept. Teams lukker sager med korte kommentarer som “ikke relevant” eller “falsk positiv”. Det kan føles effektivt, men for en revisor er det en ukontrolleret beslutning. For en tilsynsmyndighed kan det ligne en ikke-håndteret sårbarhed.

VEX og CSAF løser dette ved at omsætte sårbarhedsstøj til struktureret, revisionsklart bevismateriale for sårbarheder.

En forsvarlig styringsproces for VEX og CSAF besvarer fem spørgsmål:

1. Modtog eller identificerede vi meddelelsen?
2. Kortlagde vi den til produkter, aktiver, leverandører, kunder og dataflows med personoplysninger?
3. Fastlagde vi sårbarhedsstatus efter definerede kriterier?
4. Dokumenterede vi beslutningen, bevismaterialet, ejeren, godkendelsen og udløseren for gennemgang?
5. Afhjulpede, offentliggjorde, overvågede eller bevarede vi bevismateriale baseret på risiko?

Forskellen mellem “ikke berørt” og “ignoreret” er bevismateriale.

En VEX-status som “ikke berørt” bør understøttes af en begrundelse, f.eks. at den sårbare komponent ikke er til stede, at den sårbare version ikke er udrullet, at den sårbare kodevej ikke udføres, at den sårbare konfiguration er deaktiveret, eller at en kompenserende kontrol forhindrer udnyttelse. “Under undersøgelse” bør have en tidsbundet opfølgning og må ikke blive en kirkegård i sagskøen. “Rettet” bør pege på en patch, afbødning, versionsopdatering, testresultat og udrulningsregistrering. “Berørt” bør indgå i risikobehandling, afhjælpningsplanlægning, leverandørunderretning, kundekommunikation og, hvor relevant, arbejdsgange for vurdering af hændelser eller brud.

Clarysecs styringsmodel for beslutninger om VEX-status

Hver CSAF-meddelelse og VEX-erklæring bør behandles som en kontrolleret registrering i ISMS’et, ikke som et isoleret udviklingsartefakt. Arbejdsgangen kan ligge i en GRC-platform, et værktøj til sårbarhedsstyring, et servicedesk-sagsstyringssystem, en arbejdsgang for kildekodestyring eller en Clarysec-projektmappe til bevismateriale. Det afgørende er, at status, bevismateriale, godkendelse og risikobehandling forbliver sammenkædet.

Tabellen ser enkel ud, men den ændrer kontrolmiljøet. En erklæring om “ikke berørt” bliver en afgrænset risikobeslutning for et bestemt produkt og miljø. En status som “rettet” kobler sårbarhedsstyring til ændringsstyring og test. En status som “berørt” udløser behandling, eskalering og mulig offentliggørelse. En status som “under undersøgelse” giver ledelsen en synlig, tidsbundet risiko.

Zenith Blueprint understøtter denne tilgang i trin 13 om planlægning af risikobehandling og anvendelighedserklæring. Den forklarer, at kontrolbeslutninger bør begrundes ud fra risikobehandling, retlige eller kontraktlige krav, relevans for omfanget og organisatorisk kontekst:

“I SoA-arket markeres hver kontrol som ‘Ja’ (anvendelig) eller ‘Nej’ (ikke anvendelig). Angiv en begrundelse/noter.”

For VEX følger “ikke berørt” samme disciplin. Det er ikke en uformel lukning af en sag. Det er en begrundet beslutning, der skal kunne modstå gennemgang.

Trin 19 i Zenith Blueprint behandler teknisk sårbarhedsstyring:

“Hold jer informeret om nye sikkerhedsfejl (via leverandøradvarsler, CVE-feeds osv.) for jeres software og hardware. Vurder, hvilke der er relevante (bruger vi denne software? hvor kritisk er fejlen?), og anvend rettelser eller afbødninger uden unødig forsinkelse.”

CSAF hjælper med at modtage strukturerede meddelelser. SBOM’er hjælper med at fastslå, om komponenten er til stede. VEX hjælper med at dokumentere udnyttelighed og status. ISMS’et styrer beslutningen.

Politikbevismateriale før den kritiske meddelelse ankommer

Et VEX-program fejler, hvis den første kritiske meddelelse ankommer, før roller, kriterier og krav til bevismateriale er på plads. Politikker bør allerede definere modtagelse af sårbarhedsmeddelelser, eskalering, registrering, leverandørforpligtelser, undtagelseshåndtering og bevarelse af bevismateriale.

For SMV’er fastlægger Politik for sårbarheds- og patchstyring – SMV overvågningsforpligtelsen:

“Overvåger systemer for sårbarheder og tilgængelige patches ved hjælp af leverandøradvarsler, trusselsmeddelelser og notifikationer fra operativsystemer”

Denne klausul fra Roller og ansvar, politikklausul 4.2.1, gælder direkte for CSAF-modtagelse. CSAF-meddelelser er sårbarhedsmeddelelser fra leverandører eller økosystemer, som skal overvåges, korreleres og triageres.

Den samme SMV-politik fastsætter forventninger til revisionsberedskab:

“Oprethold nøjagtige registreringer over anvendte patches, udestående forhold og undtagelser for at sikre revisionsberedskab”

Fra Mål, politikklausul 3.4, er det her, VEX bliver mere end en teknisk fil. Hvis et team ikke patcher, fordi et produkt er “ikke berørt”, kræver denne undtagelse bevismateriale, godkendelse og sporbarhed.

For enterprise-miljøer er Politik for sårbarheds- og patchstyring eksplicit:

“Overvåg trusselsmeddelelser (f.eks. CVE, CISA KEV, leverandørbulletiner), og eskalér kritiske sårbarheder.”

Fra Roller og ansvar, politikklausul 4.5.1, understøtter denne klausul en struktureret modtagelseskanal for CSAF, CVE, leverandørbulletiner og exploit-intelligens. Den kræver også eskalering, når en VEX-status er “berørt” eller “under undersøgelse” for et kritisk produkt.

Enterprise-politikken angiver også:

“Alle kritiske sårbarheder og højrisikosårbarheder skal registreres i ISMS-risikoregistret og overvåges, indtil de er afhjulpet eller dækket af en godkendt undtagelse.”

Denne klausul fra Styringskrav, politikklausul 5.3, er efterlevelsesankeret. En VEX-erklæring om “ikke berørt” for en kritisk CVE er kun forsvarlig, når den behandles som en godkendt undtagelse med bevismateriale. En VEX-erklæring om “rettet” lukker kun sløjfen, når afhjælpningen er verificeret.

Risikoscore kræver også kontekst. Den samme politik henviser til:

“Risikovurdering (baseret på CVSS, aktivets kritikalitet, trusselsintelligens)”

Fra Risikobehandling og undtagelser, politikklausul 7.2.2, understøtter dette en kombineret triagemodel. CVSS alene er ikke nok. En sårbarhed med middel alvorlighed, der aktivt udnyttes i en kritisk identitetskomponent, kan være mere presserende end et kritisk CVSS-forhold i kode, der ikke kan nås.

Politikker for applikationer og sikker udvikling udvider samme disciplin til udviklingsteams og leverandører. Politik for krav til applikationssikkerhed – SMV kræver, at teams følger:

“kendte sårbarheder og afhjælpningsstatus.”

Fra Krav til implementering af politikken, politikklausul 6.4.2.3, matcher dette præcist VEX-statusser. Den samme politik kræver, at aftaler:

“angiver forpligtelser for offentliggørelse af sårbarheder, responstider og patchning.”

Fra Styringskrav, politikklausul 5.3.2, bliver dette til en praktisk leverandørklausul: lever rettidige meddelelser, identificér berørte versioner, udsted VEX-status, hvor det er muligt, definér tidsfrister for afhjælpning og understøt kundekommunikation.

For sikker udvikling i enterprise-miljøer forventer Politik for sikker udvikling:

“Scanning for kendte sårbarheder (CVE’er, OSS Index osv.)”

Fra Styringskrav, politikklausul 5.4.3, giver dette udviklingsorganisationen en defineret mekanisme til at matche meddelelser med komponenter og udløse VEX-analyse.

Når en sårbarhed bliver en hændelse eller et potentielt juridisk forhold, bliver disciplinen omkring bevismateriale afgørende. Politik for indsamling af bevismateriale og digital efterforskning – SMV angiver:

“Der skal opretholdes en enkel log over beviskæden (chain of custody) (f.eks. en Excel-fil eller et skabelondokument) for hver hændelse.”

Fra Styringskrav, politikklausul 5.3.1, markerer dette grænsen mellem rutinemæssig VEX-triage og hændelsesbevismateriale. Hvis der er mistanke om udnyttelse, kræver logfiler, meddelelsesregistreringer, analysenoter, kommunikation og efterforskningsartefakter sporbarhed.

Kortlægning af VEX og CSAF til ISO 27001, NIS2, DORA, GDPR og CRA

De stærkeste VEX-programmer er ikke enkeltstående sikkerhedstekniske projekter. De er kortlagt ind i det kontrolsystem, organisationen allerede anvender.

Efter ISO/IEC 27001:2022 skal ISMS’et tage højde for interessenter, retlige og kontraktlige forpligtelser, grænseflader og afhængigheder med andre organisationer. Denne omfangslogik er afgørende for VEX, fordi leverandørmeddelelser, kundeforpligtelser, open source-komponenter og udliciterede tjenester alle påvirker sårbarhedsbeslutninger.

De mest relevante Annex A-kontroller omfatter 5.19 Informationssikkerhed i leverandørrelationer, 5.20 Håndtering af informationssikkerhed i leverandøraftaler, 5.21 Styring af informationssikkerhed i IKT-forsyningskæden, 5.22 Overvågning, gennemgang og ændringsstyring af leverandørtjenester, 5.28 Indsamling af bevismateriale og 8.8 Styring af tekniske sårbarheder. Kontrollerne for sikker udvikling 8.25 til 8.29 er også relevante, hvor organisationen udvikler software eller digitale produkter.

NIS2 øger styringspresset. Article 21 kræver passende tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder risikoanalyse, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse, udvikling og vedligeholdelse, sårbarhedshåndtering og offentliggørelse, kontroleffektivitet, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, styring af aktiver og autentifikation. Article 20 kræver, at ledelsesorganer godkender og fører tilsyn med foranstaltninger til cybersikkerhedsrisikostyring. Det gør VEX-metrikker egnede til bestyrelsesrapportering.

DORA finder anvendelse fra 17. januar 2025 for finansielle enheder inden for omfanget. Forordningen kræver et rammeværk for styring af IKT-risiko, identifikation og klassificering af IKT-aktiver, sårbarheder, afhængigheder og IKT-tredjepartstjenester, hændelsesstyring, robusthedstest, styring af tredjepartsrisiko og ledelsestilsyn. For finansielle enheder er VEX-registreringer særligt nyttige, når en leverandørmeddelelse skal knyttes til kritiske eller vigtige funktioner, kontraktlige forpligtelser og hændelsesklassificering.

GDPR bliver relevant, når udnyttelse kan påvirke personoplysninger. En sårbar API, et bibliotek eller en tjeneste, der kan eksponere kunderegistre, kræver vurdering efter kriterier for fortrolighed, integritet, tilgængelighed og underretning ved brud. En VEX-konklusion om “ikke berørt” kan understøtte en beslutning om ikke at underrette, men kun hvis organisationen kan dokumentere, hvorfor der ikke er sket et brud på persondatasikkerheden.

Cyber Resilience Act tilføjer produktstyring. Efterhånden som CRA-forpligtelserne indfases, får producenter og andre økonomiske aktører behov for gentagelige processer for sårbarhedshåndtering, sikkerhedsopdateringer, koordineret offentliggørelse og bevismateriale. CSAF kan strukturere meddelelser. VEX kan tydeliggøre, hvilke produkter og versioner der er berørt, rettet eller ikke berørt.

Hvad Clarysecs tværgående efterlevelsesguide tilføjer

Zenith Controls er værdifuld, fordi den kortlægger teknisk arbejde til revisionsforventninger og overlappende rammeværker. For VEX og CSAF er tre områder vigtigst: sikkerhed i IKT-forsyningskæden, teknisk sårbarhedsstyring og indsamling af bevismateriale.

For sikkerhed i IKT-forsyningskæden identificerer Zenith Controls ISO/IEC 27002:2022 kontrol 5.21 som “Styring af informationssikkerhed i IKT-forsyningskæden.” Den forklarer, at 5.21 udvider leverandørrelationskontrollerne 5.19 og 5.20 til IKT-specifikke risici, herunder usikre softwarekomponenter og tredjeparts- eller open source-biblioteker. Den kobler til sikker engineering, sikker kodning, sikkerhedstestning, adgangsstyring, indsamling af bevismateriale, sikker udviklingslivscyklus og outsourcet udvikling.

Det er præcis her, CSAF og VEX opererer. En leverandørmeddelelse er ikke blot en besked fra en leverandør. Den er bevismateriale for leverandørens cybersikkerhedspraksis. En VEX-erklæring fra en leverandør er ikke blot en bekvemmelighed. Den kan understøtte indkøb, due diligence, overvågning og kunders risikobeslutninger.

For teknisk sårbarhedsstyring identificerer Zenith Controls kontrol 8.8 som “Styring af tekniske sårbarheder.” Den klassificerer kontrollen som forebyggende, understøttende for fortrolighed, integritet og tilgængelighed og knyttet til trussels- og sårbarhedsstyring. Den bemærker også, at sårbarhedsstyring er forbundet med malwarebeskyttelse, konfigurationsstyring, ændringsstyring, trusselsintelligens og overvågning.

Et særligt nyttigt afsnit i Zenith Controls for VEX-styring er:

“Effektiv sårbarhedsstyring prioriterer ud fra virkelige trusler. Trusselsintelligens viser, hvilke sårbarheder der aktivt udnyttes, og styrer prioriteringen af patchning.”

Det er forskellen mellem rå SBOM-match og risikobaseret VEX-triage. Tilstedeværelse alene er ikke nok. Udnyttelighed, aktivets kritikalitet, eksponering og trusselsaktivitet skal forme beslutningen.

For bevismateriale identificerer Zenith Controls kontrol 5.28, “Indsamling af bevismateriale,” som korrigerende og knyttet til detektion og respons. Den kobler 5.28 til hændelseshåndtering, logning, overvågning og hændelsesrapportering. Den kortlægger også styring af bevismateriale til ISO/IEC 27037:2012 for identifikation, indsamling, erhvervelse og bevaring af digitale beviser.

Når en sårbarhed kun er teoretisk, kan rutinemæssige VEX-registreringer være tilstrækkelige. Når der er mistanke om udnyttelse, skal organisationen overgå til håndtering af hændelsesbevismateriale. Logfiler, leverandørkommunikation, kundemeddelelser, patchregistreringer og efterforskningsartefakter kræver integritet, bevaring og sporbarhed.

En praktisk VEX-bevispakke fra alarm til lukning

Vend tilbage til Anyas fintech-platform. En CSAF-meddelelse ankommer om en kritisk sårbarhed i lib-common-utils, som fremgår af SBOM’en for betalingsgatewayen. En disciplineret respons vil oprette én samlet bevispakke, ikke spredte Slack-beskeder og skærmbilleder.

Trin 1: Opret modtagelsesregistreringen for meddelelsen

Opret en sårbarhedssag i ISMS-værktøjet til sporing af bevismateriale. Vedhæft CSAF-meddelelsen, CVE-referencen, leverandørbulletinen, SBOM-matchet og listen over berørte aktiver. Tildel en sårbarhedsejer og en forretningssystemejer. Knyt betalingstjenesten til kundepåvirkning, personoplysninger, finansiel behandling og driftskritikalitet.

Politikgrundlag: Politik for sårbarheds- og patchstyring kræver overvågning af meddelelser og eskalering af kritiske sårbarheder. ISO-grundlag: Annex A kontrol 8.8. NIS2-grundlag: sårbarhedshåndtering og sikker vedligeholdelse. DORA-grundlag: identifikation af IKT-sårbarheder og hændelsesberedskab.

Trin 2: Sæt foreløbig status til under undersøgelse

Den indledende status bør ofte være “under undersøgelse”, især for kritiske meddelelser. Fastlæg en beslutningsfrist, f.eks. 24 timer for eksternt eksponerede eller kritiske tjenester. Registrér midlertidige kontroller, f.eks. skærpet overvågning, midlertidige funktionsbegrænsninger eller WAF-regler. Det forhindrer, at en kritisk meddelelse forsvinder i en ureguleret sagskø.

Trin 3: Udfør analyse af udnyttelighed

Udviklingsteamet bør besvare praktiske spørgsmål:

• Er den sårbare version til stede i produktionsmiljøet?
• Er den sårbare funktion importeret, kaldt eller tilgængelig?
• Er den sårbare konfiguration aktiveret?
• Er komponenten eksponeret for ikke-betroede input?
• Kræves der autentifikation, før den sårbare sti kan nås?
• Er kompenserende kontroller effektive?
• Er der aktiv udnyttelse eller troværdig trusselsintelligens?
• Kan udnyttelse påvirke personoplysninger, finansielle transaktioner eller tjenestens tilgængelighed?

I Anyas tilfælde bekræfter statisk analyse, at komponenten er til stede, men at den sårbare funktion ikke kaldes af betalingsgatewayen. Der findes ingen udførelsessti i produktionsmiljøet. Teamet udarbejder en VEX-erklæring om “ikke berørt” med understøttende bevismateriale.

Hvis analysen havde vist, at et autentificeret administratorjob kunne nå den sårbare funktion, ville den korrekte status være “berørt”, ikke “ikke berørt”. Teamet skulle derefter oprette en risikobehandlingsplan, åbne en ændringssag, patche eller afbøde og først opdatere status til “rettet” efter verifikation.

Trin 4: Knyt sagen til risikoregistret og leverandørregistreringen

Kritiske sager og højrisikosager bør indføres i ISMS-risikoregistret, medmindre de lukkes via en godkendt, dokumenteret undtagelse. Leverandørmeddelelser bør også knyttes til leverandørregistret, kontraktforpligtelser og overvågningsregistreringer.

Dette understøtter Zenith Blueprint trin 23, som instruerer organisationer i at samle leverandører, klassificere dem efter adgang og operationel kontrol, indarbejde sikkerhedsforventninger i kontrakter og definere overvågningsprocedurer for leverandørændringer.

Trin 5: Validér rettelsen eller godkend undtagelsen

For “rettet” vedhæftes patchversion, ændringsregistrering, CI/CD-pipeline-resultat, afhængighedsscanning, container image-digest, udrulningsbevismateriale og regressionstest. For “ikke berørt” vedhæftes analyse af kodevej, konfigurationsbevismateriale, versionsbevismateriale, bevismateriale for kompenserende kontroller og godkendelse.

Hvis kunder bruger self-hosted versioner, eller hvis sårbarheden kan påvirke eksterne brugere, koordineres kommunikationen. Politik for koordineret offentliggørelse af sårbarheder giver modellen:

“Hvor en bekræftet sårbarhed kan påvirke kunder eller brugere af tjenesten, skal kommunikationsteamet, under VRT’s ledelse, udarbejde en sikkerhedsmeddelelse. Meddelelsen skal omfatte et overblik over forholdet uden at offentliggøre exploitdetaljer, de berørte produkter eller versioner, vejledning om afbødning eller instruktioner til download af patch samt kontaktoplysninger til support.”

Fra Implementeringskrav, politikklausul 6.8, kortlægger dette direkte til CSAF-publiceringsdisciplin.

Trin 6: Bevar bevismateriale, hvis der er mistanke om udnyttelse

Hvis logfiler viser forsøg på udnyttelse, skal processen flyttes fra sårbarhedshåndtering til hændelseshåndtering og indsamling af bevismateriale. Start en log over beviskæden (chain of custody), bevar logfiler, registrér SIEM-forespørgsler, eksportér relevante hændelser, tag om nødvendigt snapshot af berørte systemer, og dokumentér, hvem der håndterede hvert artefakt. Knyt hændelsessagen til VEX-registreringen.

Hvad revisorer og tilsynsmyndigheder vil bede om

Revisorer tester ikke al VEX- og CSAF-styring på samme måde. Én samlet bevispakke bør kunne opfylde flere perspektiver.

Zenith Controls indeholder vejledning om revisionsmetodik, der passer til denne tabel. For sikkerhed i IKT-forsyningskæden vil revisorer, der anvender ISO/IEC 19011 og ISO/IEC 27007, undersøge indkøbspolitikker, RFP-skabeloner og leverandørstyringsprocesser for at verificere IKT-specifikke sikkerhedskrav. De vil udtage stikprøver af kontrakter for klausuler om sikker udvikling, offentliggørelse af sårbarheder og softwareautenticitet.

For teknisk sårbarhedsstyring gennemgår revisorer politikken for sårbarhedsstyring, scanningsfrekvens, aktivdækning, risikobaseret prioritering, afhjælpningsfrister og ansvarsområder. For indsamling af bevismateriale tester de, om beviskæde, sikker opbevaring og bevaring blev fulgt i reelle hændelser.

Derfor bør VEX-styring aldrig stoppe ved statusetiketten. Etiketten er resuméet. Bevismaterialesporet er kontrollen.

Ledelsesmetrikker, der gør VEX egnet til bestyrelsen

ISO/IEC 27001:2022 kræver evaluering af performance, intern revision og ledelsens gennemgang. NIS2 kræver ledelsestilsyn. DORA kræver styring af IKT-risiko. VEX og CSAF skaber metrikker, der omsætter udviklingsarbejde til synlighed over ledelsesrisici.

Nyttige metrikker til ledelsens gennemgang omfatter:

• Antal kritiske CSAF-meddelelser modtaget i dette kvartal
• Procentdel matchet til SBOM-komponenter
• Antal og alder på VEX-statusser fordelt på berørt, ikke berørt, rettet og under undersøgelse
• Forfaldne sager med status “under undersøgelse”
• Leverandørmeddelelser uden tilstrækkelige data om berørte versioner
• Kritiske sårbarheder accepteret som godkendte undtagelser
• Tid fra modtagelse af meddelelse til VEX-beslutning
• Tid fra beslutning om berørt til afhjælpning
• Antal sager med potentiel påvirkning af personoplysninger
• Antal udsendte kundemeddelelser

Disse metrikker hjælper ledelsen med at stille bedre spørgsmål. Hvilke leverandører leverer ikke anvendelige sårbarhedsdata? Hvilke produkter har de længste afhjælpningstider? Hvilke teams lader undersøgelser stå åbne? Hvilke sårbarheder kan påvirke personoplysninger eller kritiske funktioner?

Almindelige fejlmønstre, der skal elimineres

Den første fejl er at behandle SBOM-match som analyse af udnyttelighed. Et komponentmatch er et signal, ikke en konklusion.

Den anden fejl er at bruge “ikke berørt” uden begrundelse. Revisorer vil spørge hvorfor. Kunne kodevejen ikke nås? Var den sårbare funktion deaktiveret? Var versionen en anden? Blev komponenten kun brugt ved build-time? Blev konklusionen godkendt af produktsikkerhed?

Den tredje fejl er at lade “under undersøgelse” forblive åben. Denne status er kun nyttig med en ejer, en frist og midlertidige kontroller.

Den fjerde fejl er at adskille leverandørstyring fra sårbarhedsstyring. Leverandørkontrakter bør kræve rettidig offentliggørelse af sårbarheder, responstider, patchforpligtelser, indhold i meddelelser og understøttelse af bevismateriale.

Den femte fejl er at ignorere personoplysninger og kundekommunikation. En sårbarhed, der kan eksponere personoplysninger, kræver GDPR-vurdering. En bekræftet produktsårbarhed, der kan påvirke kunder, kræver disciplineret koordineret offentliggørelse. En afhængighed i en finansiel tjeneste kan kræve DORA-hændelsesanalyse.

Den sjette fejl er svag bevaring af bevismateriale. Zenith Blueprint advarer i trin 23, kontrol 5.28, om at bevismateriale ofte overses:

“det, I kan dokumentere, betyder lige så meget som det, der faktisk skete”

Den sætning indfanger realiteten i 2026. Sikkerhedsteams retter ikke kun sårbarheder. De dokumenterer, at beslutningerne var rettidige, risikobaserede og kontrollerede.

Næste skridt for revisionsklart bevismateriale for sårbarheder

Hvis jeres organisation allerede har SBOM’er, er næste modenhedstrin ikke endnu et regneark over aktiver. Det er styring af sårbarhedsstatus, leverandørmeddelelser og bevismateriale for offentliggørelse.

Start med fire handlinger:

1. Tilføj CSAF- og VEX-modtagelse til jeres procedure for sårbarhedsstyring.
2. Definér godkendelseskriterier for berørt, ikke berørt, rettet og under undersøgelse.
3. Knyt VEX-registreringer til jeres ISMS-risikoregister, leverandørregister, aktivfortegnelse, SBOM-repository og hændelsesproces.
4. Test processen med én nylig kritisk meddelelse, og udarbejd en revisionsklar bevispakke.

Clarysec kan hjælpe jer med at implementere dette hurtigt ved hjælp af Zenith Blueprint, Zenith Controls og det relevante politiksæt, herunder Politik for sårbarheds- og patchstyring, Politik for sårbarheds- og patchstyring – SMV, Politik for krav til applikationssikkerhed – SMV, Politik for sikker udvikling, Politik for indsamling af bevismateriale og digital efterforskning – SMV og Politik for koordineret offentliggørelse af sårbarheder.

Det afgørende spørgsmål i 2026 er ikke “Har vi en SBOM?” Det er “Kan vi dokumentere, for hver alvorlig meddelelse, præcis hvordan vi fastlagde sårbarhedsstatus, behandlede risikoen og kommunikerede resultatet?”

Book en Clarysec-vurdering, eller anmod om det relevante politikværktøjssæt for at omsætte VEX og CSAF til revisionsklart bevismateriale for sårbarheder, før den næste kritiske meddelelse når jeres bestyrelse.