VEX och CSAF: revisionsbart bevisunderlag för sårbarheter

Säkerhetsmeddelandet 07:40 som gör en SBOM till en styrelsefråga

Klockan 07:40 en tisdagsmorgon i början av 2026 ser Anya, informationssäkerhetschef för en snabbväxande FinTech-plattform, att ett kritiskt leverantörsmeddelande kommer in i CSAF-format. En sårbarhet för fjärrkörning av kod har upptäckts i ett allmänt använt bibliotek med öppen källkod. Hennes Software Bill of Materials bekräftar att biblioteket är inbäddat i den centrala betalningsapplikationen, två interna tjänster och en outsourcad analyskomponent.

Klockan 08:10 vibrerar telefonen oavbrutet. Utvecklingsteamet vill veta om den sårbara funktionen kan nås. Funktionen för regelefterlevnad vill veta om detta berör ISO/IEC 27001:2022, NIS2 eller DORA. Den juridiska funktionen frågar om Cyber Resilience Act kan kräva kommunikation till kunder eller myndigheter. En styrelseledamot, nyligen utbildad i ledningens ansvar enligt NIS2, ställer frågan som alla tänker på:

Är vi berörda?

Det första tekniska svaret från utvecklingsteamet är korrekt: paketet finns, men den sårbara funktionen kanske inte anropas i produktion. År 2026 räcker inte det svaret.

Styrelsen vill ha bevis. Kunder vill ha ett tydligt svar. Upphandling vill veta om leverantören har uppfyllt sina avtalsenliga informationsskyldigheter. Dataskyddsombudet vill veta om personuppgifter kan exponeras. En ISO 27001-revisor accepterar inte ”utvecklaren sa det” som dokumenterat underlag. En DORA-revisor förväntar sig att sårbarheten kopplas till IKT-tillgångar, kritiska funktioner och tredjepartsberoenden.

Det är här VEX och CSAF slutar vara tekniska format och blir styrningsinfrastruktur.

CSAF, Common Security Advisory Framework, strukturerar säkerhetsmeddelanden om sårbarheter så att människor och maskiner kan behandla berörda produkter, versioner, vägledning för åtgärdande, referenser och statusinformation. VEX, Vulnerability Exploitability eXchange, tillhandahåller beslutslagret. Det visar intressenter om en känd sårbarhet faktiskt är exploaterbar i en viss produkt, tjänst eller miljö.

De praktiska VEX-statusvärdena är enkla: berörd, inte berörd, åtgärdad och under utredning. Styrningen bakom dem är inte enkel. Varje status behöver underlag, ägare, motivering, godkännande och en utlösande händelse för granskning.

Efterlevnadsgapet handlar inte längre om avsaknad av SBOM:er. Många organisationer har nu SBOM:er. Gapet ligger i att kunna visa hur varje säkerhetsmeddelande om sårbarheter triagerades, vem som godkände statusbeslutet, vilket underlag som stödde slutsatsen ”inte berörd”, hur åtgärdande prioriterades när produkten var ”berörd” och hur organisationen bevarade detta revisionsspår för revisorer, tillsynsmyndigheter, kunder och ledning.

Clarysec behandlar VEX och CSAF som en del av ISMS-operativmodellen. I Zenith Blueprint: en revisors 30-stegsplan hör detta hemma i riskhantering, leverantörssäkerhet, tekniska kontroller och bevisfaser. I Zenith Controls: vägledning för korsvis efterlevnad kopplas samma ämne till ISO/IEC 27001:2022-kontroller, IKT-säkerhet i leveranskedjan, hantering av sårbarheter, hantering av bevismaterial, NIS2, DORA, GDPR och NIST-förväntningar.

Varför SBOM:er skapar signaler, men VEX skapar underlag

En SBOM är en ingrediensförteckning. Den visar vad som finns i en produkt eller tjänst. När en CVE förekommer i en av dessa ingredienser visar SBOM:en att ni kan vara berörda.

Den signalen är värdefull, men den är inte en slutsats.

En mogen programvarumiljö kan generera tusentals SBOM-baserade sårbarhetsträffar. Många är verkliga risker. Många är inte exploaterbara eftersom den sårbara koden inte levereras, inte importeras, inte kan nås, inte är konfigurerad, inte är exponerad för icke betrodd indata eller är riskreducerad genom kompenserande kontroller. Utan en formell process för att dokumentera utredningen hamnar team vanligtvis i ett av två dåliga mönster.

Det första är triageutmattning. Ingenjörer jagar varje sårbarhetsträff med samma brådska, även när komponenten är ett byggtidsberoende, en vilande kodväg eller en funktion som endast används internt och skyddas av flera kontrollager.

Det andra är odokumenterad riskacceptans. Team stänger ärenden med korta kommentarer som ”ej tillämpligt” eller ”falsk positiv”. Det kan kännas effektivt, men för en revisor är det ett okontrollerat beslut. För en tillsynsmyndighet kan det se ut som en ohanterad sårbarhet.

VEX och CSAF löser detta genom att omvandla sårbarhetsbrus till strukturerat, revisionsbart sårbarhetsunderlag.

En försvarbar styrningsprocess för VEX och CSAF besvarar fem frågor:

1. Tog vi emot eller identifierade vi säkerhetsmeddelandet?
2. Kartlade vi det mot produkter, tillgångar, leverantörer, kunder och dataflöden med personuppgifter?
3. Fastställde vi sårbarhetsstatus med definierade kriterier?
4. Dokumenterade vi beslutet, underlaget, ägaren, godkännandet och den utlösande händelsen för granskning?
5. Åtgärdade, offentliggjorde, övervakade eller bevarade vi underlag baserat på risk?

Skillnaden mellan ”inte berörd” och ”ignorerad” är underlag.

En VEX-status ”inte berörd” ska stödjas av en motivering, till exempel att den sårbara komponenten inte finns, att den sårbara versionen inte är driftsatt, att den sårbara kodvägen inte körs, att den sårbara konfigurationen är inaktiverad eller att en kompenserande kontroll förhindrar exploatering. ”Under utredning” ska ha en tidsbegränsad uppföljning och får inte bli en begravningsplats i backloggen. ”Åtgärdad” ska peka på en patch, riskreducerande åtgärd, versionsuppdatering, testresultat och driftsättningsunderlag. ”Berörd” ska gå in i riskbehandling, åtgärdsplanering, leverantörsavisering, kundkommunikation och, där relevant, arbetsflöden för incident- eller personuppgiftsincidentbedömning.

Clarysecs styrningsmodell för VEX-statusbeslut

Varje CSAF-meddelande och VEX-uttalande bör behandlas som en kontrollerad post inom ISMS, inte som en isolerad teknisk artefakt från utvecklingsteamet. Arbetsflödet kan finnas i en GRC-plattform, ett verktyg för hantering av sårbarheter, ett ärendehanteringssystem, ett arbetsflöde för källkodsstyrning eller en Clarysec-arbetsbok för underlag. Det viktiga är att status, underlag, godkännande och riskbehandling förblir kopplade.

Tabellen ser enkel ut, men den förändrar kontrollmiljön. Ett uttalande om ”inte berörd” blir ett mindre riskbeslut för en viss produkt och miljö. Statusen ”åtgärdad” kopplar hantering av sårbarheter till ändringshantering och testning. Statusen ”berörd” utlöser behandling, eskalering och eventuellt offentliggörande. Statusen ”under utredning” ger ledningen en synlig, tidsbegränsad risk.

Zenith Blueprint förstärker detta synsätt i steg 13 om planering av riskbehandling och Statement of Applicability. Den förklarar att kontrollbeslut ska motiveras av riskbehandling, rättsliga eller avtalsenliga krav, relevans för omfattningen och organisatoriskt sammanhang:

”I SoA-bladet markerar du varje kontroll som ’Ja’ (tillämplig) eller ’Nej’ (inte tillämplig). Ange en motivering/anteckningar.”

För VEX följer ”inte berörd” samma disciplin. Det är inte en informell ärendestängning. Det är ett motiverat beslut som måste tåla granskning.

Steg 19 i Zenith Blueprint behandlar hantering av tekniska sårbarheter:

”Håll dig informerad om nya säkerhetsbrister (via leverantörsaviseringar, CVE-flöden osv.) för er programvara och hårdvara. Bedöm vilka som är relevanta (använder vi den här programvaran? hur kritisk är bristen?) och tillämpa skyndsamt korrigeringar eller riskreducerande åtgärder.”

CSAF hjälper till att ta emot strukturerade säkerhetsmeddelanden. SBOM:er hjälper till att fastställa om komponenten finns. VEX hjälper till att dokumentera exploaterbarhet och status. ISMS styr beslutet.

Policyunderlag innan det kritiska säkerhetsmeddelandet kommer

Ett VEX-program misslyckas när det första kritiska säkerhetsmeddelandet kommer innan roller, kriterier och krav på underlag finns på plats. Policyer bör redan definiera mottagning av sårbarhetsinformation, eskalering, registrering, leverantörsskyldigheter, undantagshantering och bevarande av underlag.

För små och medelstora företag fastställer Policy för sårbarhets- och patchhantering – SME övervakningsskyldigheten:

”Övervakar system avseende sårbarheter och tillgängliga patchar med hjälp av leverantörsaviseringar, hotinformation och operativsystemsaviseringar”

Denna klausul, från Roller och ansvar, policyklausul 4.2.1, gäller direkt för CSAF-intag. CSAF-meddelanden är leverantörs- eller ekosystemmeddelanden om sårbarheter som ska övervakas, korreleras och triageras.

Samma SME-policy anger förväntningar på revisionsberedskap:

”Upprätthåll korrekta poster över tillämpade patchar, utestående frågor och undantag för att säkerställa beredskap för revision”

Från Mål, policyklausul 3.4, är detta punkten där VEX blir mer än en teknisk fil. Om ett team inte patchar eftersom en produkt är ”inte berörd” behöver detta undantag underlag, godkännande och spårbarhet.

För större verksamhetsmiljöer är Policy för sårbarhets- och patchhantering tydlig:

”Övervaka hotråd (t.ex. CVE, CISA KEV, leverantörsbulletiner) och eskalera kritiska sårbarheter.”

Från Roller och ansvar, policyklausul 4.5.1, stödjer denna klausul en strukturerad intagskanal för CSAF, CVE, leverantörsbulletiner och exploateringsinformation. Den kräver också eskalering när en VEX-status är ”berörd” eller ”under utredning” för en kritisk produkt.

Företagspolicyn anger också:

”Alla kritiska sårbarheter och högrisk-sårbarheter ska registreras i ISMS-riskregister och övervakas tills de har åtgärdats eller omfattas av ett godkänt undantag.”

Denna klausul, från Styrningskrav, policyklausul 5.3, är efterlevnadsankaret. Ett VEX-uttalande om ”inte berörd” för en kritisk CVE är försvarbart endast när det behandlas som ett godkänt undantag med underlag. Ett VEX-uttalande om ”åtgärdad” stänger loopen först när åtgärdandet är verifierat.

Riskpoängsättning behöver också sammanhang. Samma policy hänvisar till:

”Riskbedömning (baserad på CVSS, tillgångens kritikalitet, hotinformation)”

Från Riskbehandling och undantag, policyklausul 7.2.2, stödjer detta en sammansatt triagemodell. CVSS räcker inte ensamt. En sårbarhet med medelhög allvarlighetsgrad som aktivt utnyttjas i en kritisk identitetskomponent kan vara mer brådskande än ett kritiskt CVSS-problem i kod som inte kan nås.

Policyer för applikationer och säker utveckling utvidgar samma disciplin till utvecklingsteam och leverantörer. Policy för applikationssäkerhetskrav – SME kräver att team följer:

”kända sårbarheter och status för åtgärdande.”

Från Krav för genomförande av policyn, policyklausul 6.4.2.3, mappar detta tydligt mot VEX-statusar. Samma policy kräver att avtal:

”anger skyldigheter för sårbarhetsrapportering, svarstider och patchning.”

Från Styrningskrav, policyklausul 5.3.2, blir detta en praktisk leverantörsklausul: tillhandahåll skyndsamma säkerhetsmeddelanden, identifiera berörda versioner, utfärda VEX-status där det är möjligt, definiera tidsramar för åtgärdande och stöd kundernas offentliggörande.

För säker utveckling i större verksamheter förväntar sig Policy för säker utveckling:

”Skanning efter kända sårbarheter (CVE:er, OSS Index osv.)”

Från Styrningskrav, policyklausul 5.4.3, ger detta utvecklingsteamet en definierad mekanism för att matcha säkerhetsmeddelanden mot komponenter och utlösa VEX-analys.

När en sårbarhet blir en incident eller ett potentiellt juridiskt ärende blir bevisdisciplin avgörande. Policy för bevisinsamling och forensik – SME anger:

”En enkel logg över beviskedjan (t.ex. Excel-fil eller malldokument) ska upprätthållas för varje incident.”

Från Styrningskrav, policyklausul 5.3.1, är detta gränsen mellan rutinmässig VEX-triage och incidentklassad hantering av bevismaterial. Om exploatering misstänks behöver loggar, poster över säkerhetsmeddelanden, analysanteckningar, kommunikation och forensiska artefakter spårbarhet.

Mappning av VEX och CSAF mot ISO 27001, NIS2, DORA, GDPR och CRA

De starkaste VEX-programmen är inte fristående projekt inom säkerhetsteknik. De mappas in i det kontrollsystem som organisationen redan använder.

Enligt ISO/IEC 27001:2022 ska ISMS beakta intressenter, rättsliga och avtalsenliga skyldigheter, gränssnitt och beroenden med andra organisationer. Den omfattningslogiken är avgörande för VEX eftersom leverantörsmeddelanden, kundåtaganden, komponenter med öppen källkod och utlagda tjänster alla påverkar sårbarhetsbeslut.

De mest relevanta Annex A-kontrollerna omfattar 5.19 Informationssäkerhet i leverantörsrelationer, 5.20 Hantering av informationssäkerhet i leverantörsavtal, 5.21 Hantering av informationssäkerhet i IKT-leveranskedjan, 5.22 Övervakning, granskning och ändringshantering av leverantörstjänster, 5.28 Insamling av bevismaterial och 8.8 Hantering av tekniska sårbarheter. Kontroller för säker utveckling, 8.25 till 8.29, är också relevanta när organisationen bygger programvara eller digitala produkter.

NIS2 ökar styrningstrycket. Article 21 kräver lämpliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning, utveckling och underhåll, sårbarhetshantering och offentliggörande, kontrolleffektivitet, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och autentisering. Article 20 kräver att ledningsorgan godkänner och övervakar riskhanteringsåtgärder för cybersäkerhet. Det gör VEX-mätetal lämpliga för styrelserapportering.

DORA gäller från den 17 januari 2025 för finansiella entiteter inom omfattningen. Förordningen kräver ett ramverk för IKT-riskhantering, identifiering och klassificering av IKT-tillgångar, sårbarheter, beroenden och IKT-tredjepartstjänster, incidenthantering, resiliensprovning, hantering av tredjepartsrisker och ledningens tillsyn. För finansiella entiteter är VEX-poster särskilt användbara när ett leverantörsmeddelande måste kopplas till kritiska eller viktiga funktioner, avtalsenliga skyldigheter och incidentklassificering.

GDPR blir relevant när exploatering kan påverka personuppgifter. Ett sårbart API, bibliotek eller en sårbar tjänst som kan exponera kundregister kräver bedömning mot kriterier för konfidentialitet, riktighet, tillgänglighet och incidentanmälan. En VEX-slutsats om ”inte berörd” kan stödja ett beslut att inte anmäla, men endast om organisationen kan visa varför ingen personuppgiftsincident inträffade.

Cyber Resilience Act tillför produktstyrning. När CRA-skyldigheter fasas in behöver tillverkare och andra ekonomiska aktörer repeterbara processer för sårbarhetshantering, säkerhetsuppdateringar, samordnat offentliggörande och underlag. CSAF kan strukturera säkerhetsmeddelanden. VEX kan klargöra vilka produkter och versioner som är berörda, åtgärdade eller inte berörda.

Vad Clarysecs vägledning för korsvis efterlevnad tillför

Zenith Controls är värdefull eftersom den mappar tekniskt arbete mot revisionsförväntningar och överlappande ramverk. För VEX och CSAF är tre områden viktigast: IKT-säkerhet i leveranskedjan, hantering av tekniska sårbarheter och insamling av bevismaterial.

För IKT-säkerhet i leveranskedjan identifierar Zenith Controls ISO/IEC 27002:2022 kontroll 5.21 som ”Hantering av informationssäkerhet i IKT-leveranskedjan”. Den förklarar att 5.21 utvidgar leverantörsrelationskontrollerna 5.19 och 5.20 till IKT-specifika risker, inklusive osäkra programvarukomponenter och tredjepartsbibliotek eller bibliotek med öppen källkod. Den kopplar till säker engineering, säker kodning, säkerhetstestning, åtkomstkontroll, bevisinsamling, säker utvecklingslivscykel och outsourcad utveckling.

Det är exakt här CSAF och VEX verkar. Ett leverantörsmeddelande är inte bara ett meddelande från en leverantör. Det är underlag för leverantörens cybersäkerhetspraxis. Ett VEX-uttalande från leverantören är inte bara en bekvämlighet. Det kan stödja upphandling, leverantörsgranskning, övervakning och kunders riskbeslut.

För hantering av tekniska sårbarheter identifierar Zenith Controls kontroll 8.8 som ”Hantering av tekniska sårbarheter”. Den klassificerar kontrollen som förebyggande, med stöd för konfidentialitet, riktighet och tillgänglighet, och kopplad till hot- och sårbarhetshantering. Den noterar också att hantering av sårbarheter kopplar till skydd mot skadlig kod, konfigurationshantering, ändringshantering, hotinformation och övervakning.

Ett särskilt användbart avsnitt i Zenith Controls för VEX-styrning är:

”Effektiv hantering av sårbarheter prioriterar utifrån verkliga hot. Hotinformation visar vilka sårbarheter som utnyttjas aktivt och vägleder prioritering av patchning.”

Det är skillnaden mellan rå SBOM-matchning och riskbaserad VEX-triage. Förekomst räcker inte. Exploaterbarhet, tillgångens kritikalitet, exponering och hotaktivitet måste forma beslutet.

För bevismaterial identifierar Zenith Controls kontroll 5.28, ”Insamling av bevismaterial”, som korrigerande och kopplad till detektera och respondera. Den kopplar 5.28 till incidentrespons, loggning, övervakning och händelserapportering. Den mappar också hantering av bevismaterial till ISO/IEC 27037:2012 för identifiering, insamling, inhämtning och bevarande av digital bevisning.

När en sårbarhet endast är teoretisk kan rutinmässiga VEX-poster räcka. När exploatering misstänks måste organisationen gå över till hantering av incidentbevis. Loggar, leverantörskommunikation, kundmeddelanden, patchposter och forensiska artefakter behöver integritet, bevarande och spårbarhet.

Ett praktiskt VEX-underlagspaket från larm till stängning

Återvänd till Anyas FinTech-plattform. Ett CSAF-meddelande kommer in för en kritisk sårbarhet i lib-common-utils, som förekommer i SBOM:en för betalningsgatewayen. En disciplinerad respons skulle skapa ett samlat underlagspaket, inte utspridda Slack-meddelanden och skärmdumpar.

Steg 1: Skapa intagsposten för säkerhetsmeddelandet

Öppna ett sårbarhetsärende i ISMS-spåraren för underlag. Bifoga CSAF-meddelandet, CVE-referensen, leverantörsbulletinen, SBOM-träffen och listan över berörda tillgångar. Tilldela en ansvarig för sårbarhetshantering och en verksamhetssystemägare. Koppla betalningstjänsten till kundpåverkan, personuppgifter, finansiell behandling och operativ kritikalitet.

Policygrund: Policy för sårbarhets- och patchhantering kräver övervakning av säkerhetsmeddelanden och eskalering av kritiska sårbarheter. ISO-grund: Annex A-kontroll 8.8. NIS2-grund: sårbarhetshantering och säkert underhåll. DORA-grund: identifiering av IKT-sårbarheter och incidentberedskap.

Steg 2: Sätt preliminär status till under utredning

Initial status bör ofta vara ”under utredning”, särskilt för kritiska säkerhetsmeddelanden. Sätt en beslutsfrist, exempelvis 24 timmar för externt exponerade eller kritiska tjänster. Registrera interimistiska kontroller, till exempel skärpt övervakning, tillfälliga funktionsbegränsningar eller WAF-regler. Detta förhindrar att ett kritiskt säkerhetsmeddelande försvinner in i en ohanterad backlogg.

Steg 3: Genomför exploaterbarhetsanalys

Utvecklingsteamet bör besvara praktiska frågor:

• Finns den sårbara versionen i produktion?
• Är den sårbara funktionen importerad, anropad eller nåbar?
• Är den sårbara konfigurationen aktiverad?
• Är komponenten exponerad för icke betrodd indata?
• Krävs autentisering innan den sårbara vägen kan nås?
• Är kompenserande kontroller effektiva?
• Förekommer aktiv exploatering eller trovärdig hotinformation?
• Kan exploatering påverka personuppgifter, finansiella transaktioner eller tjänstens tillgänglighet?

I Anyas fall bekräftar statisk analys att komponenten finns, men den sårbara funktionen anropas inte av betalningsgatewayen. Ingen exekveringsväg finns i produktion. Teamet tar fram ett VEX-uttalande om ”inte berörd” med stödjande underlag.

Om analysen hade visat att ett autentiserat administratörsjobb kunde nå den sårbara funktionen skulle korrekt status vara ”berörd”, inte ”inte berörd”. Teamet skulle då ta fram en riskbehandlingsplan, öppna ett ändringsärende, patcha eller riskreducera och uppdatera statusen till ”åtgärdad” först efter verifiering.

Steg 4: Koppla ärendet till riskregister och leverantörspost

Kritiska fall och högriskfall bör föras in i ISMS-riskregister om de inte stängs genom ett godkänt undantag med underlag. Leverantörsmeddelanden bör också kopplas till leverantörsregister, avtalsförpliktelser och övervakningsposter.

Detta stödjer Zenith Blueprint steg 23, som instruerar organisationer att sammanställa leverantörer, klassificera dem efter åtkomst och operativ kontroll, införa säkerhetsförväntningar i avtal och definiera övervakningsrutiner för leverantörsförändringar.

Steg 5: Validera korrigeringen eller godkänn undantaget

För ”åtgärdad” bifogas patchversion, ändringspost, CI/CD-pipelineresultat, beroendeskanning, digest för containeravbildning, driftsättningsunderlag och regressionstest. För ”inte berörd” bifogas kodvägsanalys, konfigurationsunderlag, versionsunderlag, underlag för kompenserande kontroll och godkännande.

Om kunder använder självhostade versioner eller om sårbarheten kan påverka externa användare ska kommunikationen samordnas. Policy för samordnad sårbarhetsrapportering ger modellen:

”När en bekräftad sårbarhet kan påverka kunder eller tjänsteanvändare ska kommunikationsteamet, under ledning av VRT, ta fram ett säkerhetsmeddelande. Meddelandet ska innehålla en översikt över problemet, utan att avslöja exploateringsdetaljer, berörda produkter eller versioner, vägledning för riskreducering eller instruktioner för nedladdning av patch samt kontaktuppgifter till support.”

Från Krav för genomförande av policyn, policyklausul 6.8, mappar detta direkt till disciplinen för CSAF-publicering.

Steg 6: Bevara underlag om exploatering misstänks

Om loggar visar försök till exploatering ska ärendet flyttas från sårbarhetshantering till incidentrespons och bevisinsamling. Starta en logg över beviskedjan, bevara loggar, registrera SIEM-frågor, exportera relevanta händelser, ta ögonblicksbilder av berörda system vid behov och dokumentera vem som hanterade varje artefakt. Koppla incidentärendet till VEX-posten.

Vad revisorer och tillsynsmyndigheter kommer att efterfråga

Revisorer testar inte styrning av VEX och CSAF på samma sätt. Ett enda underlagspaket bör tillgodose flera perspektiv.

Zenith Controls innehåller vägledning för revisionsmetodik som passar denna tabell. För IKT-säkerhet i leveranskedjan kommer revisorer som använder ISO/IEC 19011 och ISO/IEC 27007 att granska upphandlingspolicyer, RFP-mallar och leverantörshanteringsprocesser för att verifiera IKT-specifika säkerhetskrav. De kommer att stickprova avtal för klausuler om säker utveckling, sårbarhetsrapportering och programvaruautenticitet.

För hantering av tekniska sårbarheter granskar revisorer sårbarhetshanteringspolicy, skanningsfrekvens, tillgångstäckning, riskbaserad prioritering, tidsfrister för åtgärdande och ansvar. För bevisinsamling testar de om beviskedja, säker lagring och bevarande följdes i verkliga incidenter.

Det är därför VEX-styrning aldrig ska sluta vid statusetiketten. Etiketten är sammanfattningen. Underlagsspåret är kontrollen.

Ledningsmätetal som gör VEX redo för styrelsen

ISO/IEC 27001:2022 kräver utvärdering av prestation, internrevision och ledningens genomgång. NIS2 kräver ledningens tillsyn. DORA kräver styrning av IKT-risk. VEX och CSAF skapar mätetal som översätter utvecklingsteamets arbete till synlig risk för ledningen.

Användbara mätetal för ledningens genomgång omfattar:

• Antal kritiska CSAF-meddelanden som tagits emot detta kvartal
• Andel som matchats mot SBOM-komponenter
• Antal och ålder för VEX-statusar per berörd, inte berörd, åtgärdad och under utredning
• Försenade ärenden med status ”under utredning”
• Leverantörsmeddelanden utan tillräckliga uppgifter om berörda versioner
• Kritiska sårbarheter som accepterats som godkända undantag
• Tid från mottagning av säkerhetsmeddelande till VEX-beslut
• Tid från beslut om berörd status till åtgärdande
• Antal ärenden med potentiell påverkan på personuppgifter
• Antal utfärdade kundmeddelanden

Dessa mätetal hjälper ledningen att ställa bättre frågor. Vilka leverantörer underlåter att tillhandahålla användbara sårbarhetsdata? Vilka produkter har längst åtgärdstider? Vilka team lämnar utredningar öppna? Vilka sårbarheter kan påverka personuppgifter eller kritiska funktioner?

Vanliga felmönster att eliminera

Det första felet är att behandla SBOM-matchning som exploaterbarhetsanalys. En komponentträff är en signal, inte en slutsats.

Det andra felet är att använda ”inte berörd” utan motivering. Revisorer kommer att fråga varför. Var kodvägen omöjlig att nå? Var den sårbara funktionen inaktiverad? Var versionen en annan? Användes komponenten endast vid byggtid? Godkändes slutsatsen av produktansvarig för säkerhet?

Det tredje felet är att låta ”under utredning” förbli öppet. Denna status är användbar endast med ägare, tidsfrist och interimistiska kontroller.

Det fjärde felet är att separera leverantörsstyrning från sårbarhetsstyrning. Leverantörsavtal bör kräva skyndsam sårbarhetsrapportering, svarstider, patchningsskyldigheter, innehåll i säkerhetsmeddelanden och stöd för underlag.

Det femte felet är att ignorera personuppgifter och kundkommunikation. En sårbarhet som kan exponera personuppgifter kräver GDPR-bedömning. En bekräftad produktsårbarhet som kan påverka kunder kräver disciplin för samordnad sårbarhetsrapportering. Ett beroende i en finansiell tjänst kan kräva DORA-incidentanalys.

Det sjätte felet är svagt bevarande av underlag. Zenith Blueprint varnar i steg 23, kontroll 5.28, för att bevismaterial ofta förbises:

”vad du kan bevisa är lika viktigt som vad som faktiskt hände”

Den meningen fångar verkligheten 2026. Säkerhetsteam åtgärdar inte bara sårbarheter. De visar att besluten var skyndsamma, riskbaserade och kontrollerade.

Nästa steg för revisionsbart sårbarhetsunderlag

Om din organisation redan har SBOM:er är nästa mognadssteg inte ännu ett inventeringskalkylblad. Det är styrning av sårbarhetsstatus, leverantörsmeddelanden och underlag för offentliggörande.

Börja med fyra åtgärder:

1. Lägg till CSAF- och VEX-intag i er sårbarhetshanteringsrutin.
2. Definiera godkännandekriterier för berörd, inte berörd, åtgärdad och under utredning.
3. Koppla VEX-poster till ert ISMS-riskregister, leverantörsregister, tillgångsförteckning, SBOM-lagringsplats och incidentprocess.
4. Testa processen med ett nyligen inkommet kritiskt säkerhetsmeddelande och ta fram ett revisionsklart underlagspaket.

Clarysec kan hjälpa er att genomföra detta snabbt med Zenith Blueprint, Zenith Controls och den relevanta policyuppsättningen, inklusive Policy för sårbarhets- och patchhantering, Policy för sårbarhets- och patchhantering – SME, Policy för applikationssäkerhetskrav – SME, Policy för säker utveckling, Policy för bevisinsamling och forensik – SME och Policy för samordnad sårbarhetsrapportering.

Den avgörande frågan 2026 är inte ”Har vi en SBOM?” Den är ”Kan vi visa, för varje allvarligt säkerhetsmeddelande, exakt hur vi fastställde sårbarhetsstatus, behandlade risken och kommunicerade resultatet?”

Boka en Clarysec-bedömning eller begär relevant policyverktygslåda för att omvandla VEX och CSAF till revisionsbart sårbarhetsunderlag innan nästa kritiska säkerhetsmeddelande når styrelsen.