VEX en CSAF: auditbaar bewijs voor kwetsbaarheden

Het advies van 07:40 dat een SBOM tot een bestuursvraagstuk maakt

Om 07:40 op een dinsdagochtend begin 2026 ziet Anya, de CISO van een snelgroeiend FinTech-platform, een kritiek leveranciersadvies in CSAF-formaat binnenkomen. In een veelgebruikte open-sourcebibliotheek is een kwetsbaarheid voor remote code execution vastgesteld. Haar Software Bill of Materials bevestigt dat de bibliotheek is ingebed in de belangrijkste applicatie voor betalingsverwerking, twee interne diensten en een uitbestede analyticscomponent.

Om 08:10 trilt haar telefoon voortdurend. Engineering wil weten of de kwetsbare functie bereikbaar is. Compliance wil weten of dit raakt aan ISO/IEC 27001:2022, NIS2 of DORA. Juridische Zaken vraagt of de Cyber Resilience Act communicatie met klanten of autoriteiten kan vereisen. Een bestuurslid, net getraind op managementverantwoordelijkheid onder NIS2, stelt de vraag die iedereen bezighoudt:

Zijn wij affected?

Het eerste antwoord van engineering is technisch eerlijk: het pakket is aanwezig, maar de kwetsbare functie wordt mogelijk niet aangeroepen in productie. In 2026 is dat antwoord onvoldoende.

Het bestuur wil bewijs. Klanten willen een helder antwoord. Inkoop wil weten of de leverancier aan de contractuele openbaarmakingsverplichtingen heeft voldaan. De DPO wil weten of persoonsgegevens kunnen worden blootgesteld. Een ISO 27001-auditor accepteert “de ontwikkelaar zei het” niet als bewaard bewijs. Een DORA-auditor verwacht dat de kwetsbaarheid wordt gekoppeld aan ICT-activa, kritieke functies en afhankelijkheden van derden.

Dit is het punt waarop VEX en CSAF niet langer alleen technische formaten zijn, maar governance-infrastructuur worden.

CSAF, het Common Security Advisory Framework, structureert kwetsbaarheidsadviezen zodat mensen en machines affected producten, versies, remediatierichtlijnen, referenties en statusinformatie kunnen verwerken. VEX, de Vulnerability Exploitability eXchange, levert de besluitvormingslaag. Het vertelt stakeholders of een bekende kwetsbaarheid daadwerkelijk exploiteerbaar is in een specifiek product, een specifieke dienst of een specifieke omgeving.

De praktische VEX-statusuitkomsten zijn eenvoudig: affected, not affected, fixed en under investigation. De governance daarachter is niet eenvoudig. Elke status vereist bewijs, een eigenaar, een onderbouwing, goedkeuring en een trigger voor herbeoordeling.

Het compliancehiaat is niet langer het ontbreken van SBOM’s. Veel organisaties hebben inmiddels SBOM’s. Het hiaat zit in het aantonen hoe elk kwetsbaarheidsadvies is getriageerd, wie het statusbesluit heeft goedgekeurd, welk bewijs een conclusie “not affected” ondersteunde, hoe remediatie is geprioriteerd wanneer het product “affected” was, en hoe de organisatie dat spoor heeft bewaard voor auditors, toezichthouders, klanten en management.

Clarysec behandelt VEX en CSAF als onderdeel van het ISMS-bedrijfsmodel. In Zenith Blueprint: An Auditor’s 30-Step Roadmap hoort dit thuis in de fasen risicobeheer, leveranciersbeveiliging, technische beheersmaatregelen en bewijsvoering. In Zenith Controls: The Cross-Compliance Guide verbindt hetzelfde onderwerp beheersmaatregelen uit ISO/IEC 27001:2022 met beveiliging van de ICT-toeleveringsketen, kwetsbaarheidsbeheer, bewijsbehandeling, NIS2, DORA, GDPR en NIST-verwachtingen.

Waarom SBOM’s signalen creëren, maar VEX bewijs creëert

Een SBOM is een ingrediëntenlijst. Die vertelt wat er in een product of dienst zit. Wanneer een CVE in een van die ingrediënten verschijnt, geeft de SBOM aan dat u mogelijk affected bent.

Dat signaal is waardevol, maar het is geen conclusie.

Een volwassen softwareomgeving kan duizenden SBOM-matches met kwetsbaarheden genereren. Veel daarvan zijn echte risico’s. Veel zijn niet exploiteerbaar omdat de kwetsbare code niet wordt meegeleverd, niet wordt geïmporteerd, niet bereikbaar is, niet is geconfigureerd, niet is blootgesteld aan niet-vertrouwde invoer of wordt gemitigeerd door compenserende beheersmaatregelen. Zonder een formeel proces om het onderzoek vast te leggen, vervallen teams meestal in een van twee ongewenste patronen.

Het eerste patroon is triage-uitputting. Engineers onderzoeken elke kwetsbaarheidsmatch met dezelfde urgentie, zelfs wanneer de component een afhankelijkheid tijdens de build is, een slapend codepad bevat of een uitsluitend interne functie betreft die door gelaagde beheersmaatregelen wordt beschermd.

Het tweede patroon is ongedocumenteerde risicoacceptatie. Teams sluiten tickets met korte opmerkingen zoals “niet van toepassing” of “false positive”. Dat kan efficiënt aanvoelen, maar voor een auditor is het een onbeheerst besluit. Voor een toezichthouder kan het lijken op een onbeheerde kwetsbaarheid.

VEX en CSAF lossen dit op door kwetsbaarheidsruis om te zetten in gestructureerd, auditbaar kwetsbaarheidsbewijs.

Een verdedigbaar governanceproces voor VEX en CSAF beantwoordt vijf vragen:

1. Hebben wij het advies ontvangen of geïdentificeerd?
2. Hebben wij het gekoppeld aan producten, activa, leveranciers, klanten en gegevensstromen met persoonsgegevens?
3. Hebben wij de kwetsbaarheidsstatus vastgesteld op basis van gedefinieerde criteria?
4. Hebben wij het besluit, het bewijs, de eigenaar, de goedkeuring en de trigger voor herbeoordeling gedocumenteerd?
5. Hebben wij op basis van risico geremedieerd, openbaar gemaakt, gemonitord of bewijs bewaard?

Het verschil tussen “not affected” en “genegeerd” is bewijs.

Een VEX-status “not affected” moet worden ondersteund door een onderbouwing, bijvoorbeeld dat de kwetsbare component niet aanwezig is, de kwetsbare versie niet is uitgerold, het kwetsbare codepad niet wordt uitgevoerd, de kwetsbare configuratie is uitgeschakeld of een compenserende beheersmaatregel exploitatie voorkomt. “Under investigation” moet een tijdgebonden opvolging hebben en mag geen kerkhof voor achterstallige taken worden. “Fixed” moet verwijzen naar een patch, mitigatie, versie-update, testresultaat en uitrolregistratie. “Affected” moet leiden tot risicobehandeling, remediatieplanning, leveranciersmelding, klantcommunicatie en, waar relevant, workflows voor incident- of inbreukbeoordeling.

Het governancemodel van Clarysec voor VEX-statusbesluiten

Elk CSAF-advies en elke VEX-verklaring moet binnen het ISMS als een gecontroleerde registratie worden behandeld, niet als een losstaand engineeringartefact. De workflow kan plaatsvinden in een GRC-platform, een tool voor kwetsbaarheidsbeheer, een ticketsysteem, een workflow voor broncodebeheer of een Clarysec-bewijswerkboek. Het belangrijkste is dat status, bewijs, goedkeuring en risicobehandeling gekoppeld blijven.

Deze tabel oogt eenvoudig, maar verandert de beheersingsomgeving. Een verklaring “not affected” wordt een klein risicobesluit voor een specifiek product en een specifieke omgeving. Een status “fixed” koppelt kwetsbaarheidsbeheer aan wijzigingsbeheer en testen. Een status “affected” triggert behandeling, escalatie en mogelijke openbaarmaking. Een status “under investigation” geeft het management een zichtbaar, tijdgebonden risico.

Zenith Blueprint versterkt deze denkwijze in Stap 13 over planning van risicobehandeling en de Verklaring van Toepasselijkheid. Het legt uit dat besluiten over beheersmaatregelen moeten worden gerechtvaardigd door risicobehandeling, wettelijke of contractuele eisen, scoperelevantie en organisatorische context:

“Markeer in het SoA-blad elke beheersmaatregel als ‘Yes’ (van toepassing) of ‘No’ (niet van toepassing). Geef een Justification/Notes.”

Voor VEX volgt “not affected” dezelfde discipline. Het is geen informele ticketafsluiting. Het is een onderbouwd besluit dat een beoordeling moet kunnen doorstaan.

Stap 19 van Zenith Blueprint behandelt beheer van technische kwetsbaarheden:

“Blijf op de hoogte van nieuwe beveiligingsfouten (via leveranciersmeldingen, CVE-feeds enz.) voor uw software en hardware. Beoordeel welke relevant zijn (gebruiken wij deze software? hoe kritiek is de fout?) en pas fixes of mitigaties tijdig toe.”

CSAF helpt bij het ontvangen van gestructureerde adviezen. SBOM’s helpen bij het vaststellen of componenten aanwezig zijn. VEX helpt exploiteerbaarheid en status te documenteren. Het ISMS beheerst het besluit.

Beleidsbewijs vóórdat het kritieke advies binnenkomt

Een VEX-programma faalt wanneer het eerste kritieke advies binnenkomt voordat rollen, criteria en bewijsvereisten bestaan. Beleid moet al bepalen hoe kwetsbaarheden worden ontvangen, geëscaleerd en geregistreerd, welke leveranciersverplichtingen gelden, hoe uitzonderingen worden afgehandeld en hoe bewijs wordt bewaard.

Voor mkb-organisaties stelt het Beleid voor kwetsbaarheden- en patchbeheer - mkb de monitoringverplichting vast:

“Bewaakt systemen op kwetsbaarheden en beschikbare patches met behulp van leveranciersmeldingen, adviezen op basis van dreigingsinformatie en meldingen van besturingssystemen”

Deze clausule, uit Rollen en verantwoordelijkheden, beleidsclausule 4.2.1, is rechtstreeks van toepassing op CSAF-intake. CSAF-adviezen zijn kwetsbaarheidsadviezen van leveranciers of ecosystemen die moeten worden gemonitord, gecorreleerd en getriageerd.

Hetzelfde mkb-beleid stelt verwachtingen voor auditgereedheid:

“Onderhoud nauwkeurige registraties van toegepaste patches, openstaande kwesties en uitzonderingen om auditgereedheid te waarborgen”

Uit Doelstellingen, beleidsclausule 3.4, blijkt waar VEX meer wordt dan een technisch bestand. Als een team niet patcht omdat een product “not affected” is, vereist die uitzondering bewijs, goedkeuring en traceerbaarheid.

Voor enterprise-omgevingen is het Beleid voor kwetsbaarheden- en patchbeheer expliciet:

“Monitor dreigingsadviezen (bijv. CVE, CISA KEV, leveranciersbulletins) en escaleer kritieke kwetsbaarheden.”

Uit Rollen en verantwoordelijkheden, beleidsclausule 4.5.1, ondersteunt deze clausule een gestructureerd intakekanaal voor CSAF, CVE, leveranciersbulletins en exploit intelligence. De clausule vereist ook escalatie wanneer een VEX-status “affected” of “under investigation” is voor een kritiek product.

Het enterprise-beleid stelt ook:

“Alle kritieke en hoog-risico kwetsbaarheden moeten worden geregistreerd in het ISMS-risicoregister en worden gemonitord totdat zij zijn geremedieerd of onder een goedgekeurde uitzondering vallen.”

Deze clausule, uit Governancevereisten, beleidsclausule 5.3, is het complianceanker. Een VEX-verklaring “not affected” voor een kritieke CVE is alleen verdedigbaar wanneer deze wordt behandeld als een goedgekeurde uitzondering met bewijs. Een VEX-verklaring “fixed” sluit de lus alleen wanneer remediatie is geverifieerd.

Risicoscore vereist ook context. Hetzelfde beleid verwijst naar:

“Risicobeoordeling (op basis van CVSS, criticaliteit van bedrijfsmiddelen, dreigingsinformatie)”

Uit Risicobehandeling en uitzonderingen, beleidsclausule 7.2.2, ondersteunt dit een gecombineerd triagemodel. CVSS alleen is niet genoeg. Een kwetsbaarheid met middelhoge ernst die actief wordt misbruikt in een kritieke identiteitscomponent kan urgenter zijn dan een kritieke CVSS-kwestie in niet-bereikbare code.

Applicatie- en veilige-ontwikkelingsbeleid trekken dezelfde discipline door naar engineering en leveranciers. Het Beleid voor vereisten voor applicatiebeveiliging - mkb vereist dat teams het volgende volgen:

“bekende kwetsbaarheden en remediatiestatus.”

Uit Vereisten voor beleidsimplementatie, beleidsclausule 6.4.2.3, sluit dit netjes aan op VEX-statussen. Hetzelfde beleid vereist dat overeenkomsten:

“verplichtingen specificeren voor openbaarmaking van kwetsbaarheden, responstermijnen en patching.”

Uit Governancevereisten, beleidsclausule 5.3.2, wordt dit een praktische leveranciersclausule: lever tijdige adviezen, identificeer affected versies, geef waar mogelijk een VEX-status af, definieer remediatietermijnen en ondersteun openbaarmaking richting klanten.

Voor veilige ontwikkeling in enterprise-omgevingen verwacht het Beleid voor veilige ontwikkeling:

“Scannen op bekende kwetsbaarheden (CVE’s, OSS Index enz.)”

Uit Governancevereisten, beleidsclausule 5.4.3, geeft dit engineering een gedefinieerd mechanisme om adviezen aan componenten te koppelen en VEX-analyse te starten.

Wanneer een kwetsbaarheid een incident of potentiële juridische kwestie wordt, is bewijsdiscipline essentieel. Het Beleid voor bewijsverzameling en forensisch onderzoek - mkb stelt:

“Voor elk incident moet een eenvoudig chain-of-custody-logboek (bijv. Excel-bestand of sjabloondocument) worden bijgehouden.”

Uit Governancevereisten, beleidsclausule 5.3.1, vormt dit de grens tussen routinematige VEX-triage en bewijsbehandeling op incidentniveau. Als exploitatie wordt vermoed, hebben logboeken, adviesregistraties, analysenotities, communicatie en forensische artefacten traceerbaarheid nodig.

VEX en CSAF koppelen aan ISO 27001, NIS2, DORA, GDPR en CRA

De sterkste VEX-programma’s zijn geen losstaande security-engineeringprojecten. Zij worden gekoppeld aan het beheersingssysteem dat de organisatie al gebruikt.

Onder ISO/IEC 27001:2022 moet het ISMS rekening houden met belanghebbenden, wettelijke en contractuele verplichtingen, interfaces en afhankelijkheden met andere organisaties. Die scopelogica is essentieel voor VEX, omdat leveranciersadviezen, klanttoezeggingen, open-sourcecomponenten en uitbestede diensten allemaal invloed hebben op kwetsbaarheidsbesluiten.

De meest relevante Annex A-beheersmaatregelen omvatten 5.19 Informatiebeveiliging in leveranciersrelaties, 5.20 Adresseren van informatiebeveiliging binnen leveranciersovereenkomsten, 5.21 Beheer van informatiebeveiliging in de ICT-toeleveringsketen, 5.22 Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten, 5.28 Verzameling van bewijsmateriaal en 8.8 Beheer van technische kwetsbaarheden. Beheersmaatregelen voor veilige ontwikkeling 8.25 tot en met 8.29 zijn ook relevant wanneer de organisatie software of digitale producten bouwt.

NIS2 verhoogt de governancedruk. Article 21 vereist passende technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige inkoop, ontwikkeling en onderhoud, afhandeling en openbaarmaking van kwetsbaarheden, doeltreffendheid van beheersmaatregelen, cyberbeveiligingshygiëne, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen en authenticatie. Article 20 vereist dat bestuursorganen maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren en daarop toezicht houden. Dat maakt VEX-metrieken geschikt voor rapportage aan het bestuur.

DORA is vanaf 17 januari 2025 van toepassing op financiële entiteiten binnen de reikwijdte. Het vereist een ICT-risicobeheerkader, identificatie en classificatie van ICT-activa, kwetsbaarheden, afhankelijkheden en ICT-diensten van derden, incidentbeheer, weerbaarheidstesten, risicobeheer voor derden en toezicht door het management. Voor financiële entiteiten zijn VEX-registraties bijzonder nuttig wanneer een leveranciersadvies moet worden gekoppeld aan kritieke of belangrijke functies, contractuele verplichtingen en incidentclassificatie.

GDPR speelt een rol wanneer exploitatie persoonsgegevens kan raken. Een kwetsbare API, bibliotheek of dienst die klantregistraties kan blootstellen vereist een beoordeling aan de hand van vertrouwelijkheid, integriteit, beschikbaarheid en criteria voor melding van inbreuken. Een VEX-conclusie “not affected” kan een besluit om niet te melden ondersteunen, maar alleen als de organisatie kan aantonen waarom geen inbreuk in verband met persoonsgegevens heeft plaatsgevonden.

De Cyber Resilience Act voegt productgovernance toe. Naarmate CRA-verplichtingen gefaseerd ingaan, hebben fabrikanten en andere marktdeelnemers herhaalbare processen nodig voor afhandeling van kwetsbaarheden, beveiligingsupdates, gecoördineerde openbaarmaking en bewijsvoering. CSAF kan adviezen structureren. VEX kan verduidelijken welke producten en versies affected, fixed of not affected zijn.

Wat de cross-compliance guide van Clarysec toevoegt

Zenith Controls is waardevol omdat het technisch werk koppelt aan auditverwachtingen en overlappende raamwerken. Voor VEX en CSAF zijn drie gebieden het belangrijkst: beveiliging van de ICT-toeleveringsketen, beheer van technische kwetsbaarheden en verzameling van bewijsmateriaal.

Voor beveiliging van de ICT-toeleveringsketen identificeert Zenith Controls ISO/IEC 27002:2022 beheersmaatregel 5.21 als “Beheer van informatiebeveiliging in de ICT-toeleveringsketen.” Het legt uit dat 5.21 leveranciersrelatiebeheersmaatregelen 5.19 en 5.20 uitbreidt naar ICT-specifieke risico’s, waaronder onveilige softwarecomponenten en bibliotheken van derden of open source. Het verbindt dit met secure engineering, veilige programmeerpraktijken, beveiligingstesten, toegangscontrole, bewijsverzameling, de veilige ontwikkelingslevenscyclus en uitbestede ontwikkeling.

Precies daar werken CSAF en VEX. Een leveranciersadvies is niet slechts een bericht van een leverancier. Het is bewijs van de cyberbeveiligingspraktijk van de leverancier. Een VEX-verklaring van een leverancier is niet alleen handig. Zij kan inkoop, due diligence, monitoring en klantrisicobesluiten ondersteunen.

Voor beheer van technische kwetsbaarheden identificeert Zenith Controls beheersmaatregel 8.8 als “Beheer van technische kwetsbaarheden.” Het classificeert de beheersmaatregel als preventief, ondersteunend aan vertrouwelijkheid, integriteit en beschikbaarheid, en gekoppeld aan dreigings- en kwetsbaarheidsbeheer. Het merkt ook op dat kwetsbaarheidsbeheer verband houdt met malwarebescherming, configuratiebeheer, wijzigingsbeheer, dreigingsinformatie en monitoring.

Een bijzonder bruikbare passage uit Zenith Controls voor VEX-governance is:

“Effectief kwetsbaarheidsbeheer prioriteert op basis van dreigingen uit de praktijk. Dreigingsinformatie geeft aan welke kwetsbaarheden actief worden misbruikt en stuurt daarmee de prioritering van patches.”

Dat is het verschil tussen ruwe SBOM-matching en risicogebaseerde VEX-triage. Aanwezigheid alleen is onvoldoende. Exploiteerbaarheid, criticaliteit van bedrijfsmiddelen, blootstelling en dreigingsactiviteit moeten het besluit bepalen.

Voor bewijsmateriaal identificeert Zenith Controls beheersmaatregel 5.28, “Verzameling van bewijsmateriaal,” als corrigerend en gekoppeld aan detecteren en reageren. Het verbindt 5.28 met incidentrespons, logging, monitoring en gebeurtenisrapportage. Het koppelt bewijsbehandeling ook aan ISO/IEC 27037:2012 voor identificatie, verzameling, verwerving en bewaring van digitaal bewijsmateriaal.

Wanneer een kwetsbaarheid slechts theoretisch is, kunnen routinematige VEX-registraties voldoende zijn. Wanneer exploitatie wordt vermoed, moet de organisatie overschakelen naar bewijsbehandeling voor incidenten. Logboeken, leverancierscommunicatie, klantmeldingen, patchregistraties en forensische artefacten vereisen integriteit, bewaring en traceerbaarheid.

Een praktisch VEX-bewijspakket van alert tot afsluiting

Terug naar Anya’s FinTech-platform. Er komt een CSAF-advies binnen voor een kritieke kwetsbaarheid in lib-common-utils, die in de SBOM voor de payment gateway voorkomt. Een gedisciplineerde respons levert één bewijspakket op, geen versnipperde Slack-berichten en screenshots.

Stap 1: Maak de intake-registratie voor het advies aan

Open een kwetsbaarheidszaak in de ISMS-bewijstracker. Voeg het CSAF-advies, de CVE-referentie, het leveranciersbulletin, de SBOM-match en de lijst met affected assets toe. Wijs een kwetsbaarheidseigenaar en een systeemeigenaar vanuit de business toe. Koppel de betalingsdienst aan klantimpact, persoonsgegevens, financiële verwerking en operationele criticaliteit.

Beleidsbasis: het Beleid voor kwetsbaarheden- en patchbeheer vereist monitoring van adviezen en escalatie van kritieke kwetsbaarheden. ISO-basis: Annex A-beheersmaatregel 8.8. NIS2-basis: afhandeling van kwetsbaarheden en veilig onderhoud. DORA-basis: identificatie van ICT-kwetsbaarheden en incidentparaatheid.

Stap 2: Stel de voorlopige status in op under investigation

De initiële status moet vaak “under investigation” zijn, zeker voor kritieke adviezen. Stel een beslistermijn vast, bijvoorbeeld 24 uur voor extern blootgestelde of kritieke diensten. Leg tijdelijke beheersmaatregelen vast, zoals verscherpte monitoring, tijdelijke functiebeperkingen of WAF-regels. Dit voorkomt dat een kritiek advies in een onbeheerde backlog verdwijnt.

Stap 3: Voer een exploitability-analyse uit

Engineering moet praktische vragen beantwoorden:

• Is de kwetsbare versie aanwezig in productie?
• Is de kwetsbare functie geïmporteerd, aangeroepen of bereikbaar?
• Is de kwetsbare configuratie ingeschakeld?
• Is de component blootgesteld aan niet-vertrouwde invoer?
• Is authenticatie vereist voordat het kwetsbare pad bereikbaar is?
• Zijn compenserende beheersmaatregelen effectief?
• Is er actieve exploitatie of geloofwaardige dreigingsinformatie?
• Kan exploitatie persoonsgegevens, financiële transacties of beschikbaarheid van de dienst raken?

In Anya’s geval bevestigt statische analyse dat de component aanwezig is, maar dat de kwetsbare functie niet door de payment gateway wordt aangeroepen. Er bestaat geen uitvoeringspad in productie. Het team stelt een VEX-verklaring “not affected” op met ondersteunend bewijs.

Als de analyse had aangetoond dat een geauthenticeerde admin-job de kwetsbare functie kon bereiken, zou de juiste status “affected” zijn, niet “not affected”. Het team zou dan een risicobehandelingsplan opstellen, een wijzigingsticket openen, patchen of mitigeren en de status pas na verificatie bijwerken naar “fixed”.

Stap 4: Koppel de zaak aan het risicoregister en de leveranciersregistratie

Kritieke en hoog-risico zaken moeten in het ISMS-risicoregister worden opgenomen, tenzij zij worden gesloten via een goedgekeurde, met bewijs onderbouwde uitzondering. Leveranciersadviezen moeten ook worden gekoppeld aan het leveranciersregister, contractuele verplichtingen en monitoringregistraties.

Dit ondersteunt Zenith Blueprint Stap 23, waarin organisaties worden geïnstrueerd leveranciers te inventariseren, te classificeren op basis van toegang en operationele beheersing, beveiligingsverwachtingen in contracten op te nemen en monitoringprocedures voor leverancierswijzigingen te definiëren.

Stap 5: Valideer de fix of keur de uitzondering goed

Voor “fixed” voegt u de patchversie, wijzigingsregistratie, CI/CD-pijplijnresultaat, afhankelijkhedenscan, containerimagedigest, uitrolbewijs en regressietest toe. Voor “not affected” voegt u analyse van het codepad, configuratiebewijs, versiebewijs, bewijs voor compenserende beheersmaatregelen en goedkeuring toe.

Als klanten self-hosted versies gebruiken of de kwetsbaarheid externe gebruikers kan raken, coördineer dan de communicatie. Het Beleid voor gecoördineerde openbaarmaking van kwetsbaarheden biedt het model:

“Wanneer een bevestigde kwetsbaarheid klanten of gebruikers van diensten kan raken, stelt het communicatieteam, onder leiding van het VRT, een beveiligingsadvies op. Het advies bevat een overzicht van de kwestie, zonder exploitdetails openbaar te maken, de affected producten of versies, mitigatierichtlijnen of instructies voor het downloaden van patches, en contactinformatie voor ondersteuning.”

Uit Implementatievereisten, beleidsclausule 6.8, sluit dit rechtstreeks aan op CSAF-publicatiediscipline.

Stap 6: Bewaar bewijs als exploitatie wordt vermoed

Als logboeken poging tot exploitatie laten zien, schakel dan over van afhandeling van kwetsbaarheden naar incidentrespons en bewijsverzameling. Start een chain-of-custody-logboek, bewaar logboeken, leg SIEM-query’s vast, exporteer relevante gebeurtenissen, maak waar nodig een momentopname van affected systemen en documenteer wie elk artefact heeft behandeld. Koppel de incidentzaak aan de VEX-registratie.

Waar auditors en toezichthouders om zullen vragen

Auditors testen VEX- en CSAF-governance niet allemaal op dezelfde manier. Eén bewijspakket moet meerdere invalshoeken kunnen bedienen.

Zenith Controls bevat richtlijnen voor auditmethodologie die bij deze tabel passen. Voor beveiliging van de ICT-toeleveringsketen onderzoeken auditors die ISO/IEC 19011 en ISO/IEC 27007 gebruiken inkoopbeleid, RFP-sjablonen en leveranciersmanagementprocessen om te verifiëren of ICT-specifieke beveiligingsvereisten zijn opgenomen. Zij nemen steekproeven uit contracten op clausules voor veilige ontwikkeling, openbaarmaking van kwetsbaarheden en softwareauthenticiteit.

Voor beheer van technische kwetsbaarheden beoordelen auditors beleid voor kwetsbaarheidsbeheer, scanfrequentie, dekking van bedrijfsmiddelen, risicogebaseerde prioritering, remediatietermijnen en verantwoordelijkheden. Voor bewijsverzameling toetsen zij of chain-of-custody, veilige opslag en bewaring bij echte incidenten zijn gevolgd.

Daarom mag VEX-governance nooit ophouden bij het statuslabel. Het label is de samenvatting. Het bewijsspoor is de beheersmaatregel.

Managementmetrieken die VEX bestuursgeschikt maken

ISO/IEC 27001:2022 vereist prestatie-evaluatie, interne audit en directiebeoordeling. NIS2 vereist toezicht door het management. DORA vereist governance over ICT-risico. VEX en CSAF creëren metrieken die engineeringwerk vertalen naar zichtbaarheid van risico’s voor het bestuur.

Nuttige metrieken voor de directiebeoordeling zijn onder meer:

• Aantal kritieke CSAF-adviezen dat dit kwartaal is ontvangen
• Percentage dat is gematcht met SBOM-componenten
• Aantal en ouderdom van VEX-statussen per affected, not affected, fixed en under investigation
• Achterstallige zaken met status “under investigation”
• Leveranciersadviezen zonder voldoende gegevens over affected versies
• Kritieke kwetsbaarheden die als goedgekeurde uitzonderingen zijn geaccepteerd
• Tijd vanaf adviesintake tot VEX-besluit
• Tijd vanaf affected-besluit tot remediatie
• Aantal zaken met potentiële impact op persoonsgegevens
• Aantal uitgegeven klantadviezen

Deze metrieken helpen het management betere vragen te stellen. Welke leveranciers leveren geen bruikbare kwetsbaarheidsgegevens? Welke producten hebben de langste remediatietijden? Welke teams laten onderzoeken openstaan? Welke kwetsbaarheden kunnen persoonsgegevens of kritieke functies raken?

Veelvoorkomende faalpatronen die moeten worden geëlimineerd

Het eerste faalpatroon is SBOM-matching behandelen als exploitability-analyse. Een componentmatch is een signaal, geen conclusie.

Het tweede faalpatroon is “not affected” gebruiken zonder onderbouwing. Auditors zullen vragen waarom. Was het codepad onbereikbaar? Was de kwetsbare functie uitgeschakeld? Was de versie anders? Werd de component alleen tijdens de build gebruikt? Was de conclusie goedgekeurd door product security?

Het derde faalpatroon is “under investigation” open laten staan. Deze status is alleen nuttig met een eigenaar, deadline en tijdelijke beheersmaatregelen.

Het vierde faalpatroon is leveranciersgovernance scheiden van kwetsbaarheidsgovernance. Leverancierscontracten moeten tijdige openbaarmaking van kwetsbaarheden, responstermijnen, patchverplichtingen, adviesinhoud en ondersteuning met bewijs vereisen.

Het vijfde faalpatroon is persoonsgegevens en klantcommunicatie negeren. Een kwetsbaarheid die persoonsgegevens kan blootstellen vereist een GDPR-beoordeling. Een bevestigde productkwetsbaarheid die klanten kan raken vereist discipline voor gecoördineerde openbaarmaking. Een afhankelijkheid van financiële diensten kan DORA-incidentanalyse vereisen.

Het zesde faalpatroon is zwakke bewaring van bewijs. Zenith Blueprint waarschuwt in Stap 23, beheersmaatregel 5.28, dat bewijsmateriaal vaak over het hoofd wordt gezien:

“wat u kunt bewijzen is net zo belangrijk als wat er daadwerkelijk is gebeurd”

Die zin vat de realiteit van 2026 samen. Beveiligingsteams lossen niet alleen kwetsbaarheden op. Zij tonen aan dat besluiten tijdig, risicogebaseerd en beheerst waren.

Volgende stappen voor auditbaar kwetsbaarheidsbewijs

Als uw organisatie al SBOM’s heeft, is de volgende volwassenheidsstap niet nog een inventarisatiespreadsheet. Het is governance over kwetsbaarheidsstatus, leveranciersadviezen en bewijs voor openbaarmaking.

Begin met vier acties:

1. Voeg CSAF- en VEX-intake toe aan uw procedure voor kwetsbaarheidsbeheer.
2. Definieer goedkeuringscriteria voor affected, not affected, fixed en under investigation.
3. Koppel VEX-registraties aan uw ISMS-risicoregister, leveranciersregister, inventaris van bedrijfsmiddelen, SBOM-repository en incidentproces.
4. Test het proces met één recent kritiek advies en produceer een auditgereed bewijspakket.

Clarysec kan u helpen dit snel te implementeren met Zenith Blueprint, Zenith Controls en de relevante beleidsset, waaronder het Beleid voor kwetsbaarheden- en patchbeheer, Beleid voor kwetsbaarheden- en patchbeheer - mkb, Beleid voor vereisten voor applicatiebeveiliging - mkb, Beleid voor veilige ontwikkeling, Beleid voor bewijsverzameling en forensisch onderzoek - mkb en Beleid voor gecoördineerde openbaarmaking van kwetsbaarheden.

De winnende vraag in 2026 is niet “Hebben wij een SBOM?” maar “Kunnen wij voor elk ernstig advies exact aantonen hoe wij de kwetsbaarheidsstatus hebben vastgesteld, het risico hebben behandeld en het resultaat hebben gecommuniceerd?”

Boek een Clarysec-assessment of vraag de relevante policy toolkit aan om VEX en CSAF om te zetten in auditgereed kwetsbaarheidsbewijs, voordat het volgende kritieke advies uw bestuur bereikt.