VEX and CSAF: Auditable Vulnerability Evidence

The 07:40 advisory that turns an SBOM into a board problem

At 07:40 on a Tuesday morning in early 2026, Anya, the CISO of a fast-growing FinTech platform, sees a critical supplier advisory arrive in CSAF format. A remote code execution vulnerability has been found in a widely used open-source library. Her Software Bill of Materials confirms the library is embedded in the flagship payment processing application, two internal services and an outsourced analytics component.

By 08:10, her phone is buzzing. Engineering wants to know whether the vulnerable function is reachable. Compliance wants to know whether this touches ISO/IEC 27001:2022, NIS2 or DORA. Legal asks whether the Cyber Resilience Act could require customer or authority communication. A board member, freshly trained on NIS2 management accountability, asks the question everyone is thinking:

Are we affected?

The first engineering answer is technically honest: the package exists, but the vulnerable function may not be called in production. In 2026, that answer is not enough.

The board wants proof. Customers want a clear response. Procurement wants to know whether the supplier met contractual disclosure obligations. The DPO wants to know whether personal data could be exposed. An ISO 27001 auditor will not accept “the developer said so” as retained evidence. A DORA auditor will expect the vulnerability to connect to ICT assets, critical functions and third-party dependencies.

This is where VEX and CSAF stop being technical formats and become governance infrastructure.

CSAF, the Common Security Advisory Framework, structures vulnerability advisories so people and machines can process affected products, versions, remediation guidance, references and status information. VEX, the Vulnerability Exploitability eXchange, provides the decision layer. It tells stakeholders whether a known vulnerability is actually exploitable in a specific product, service or environment.

The practical VEX status outcomes are simple: affected, not affected, fixed and under investigation. The governance behind them is not simple. Each status needs evidence, an owner, a rationale, approval and a review trigger.

The compliance gap is no longer the absence of SBOMs. Many organizations now have SBOMs. The gap is proving how each vulnerability advisory was triaged, who approved the status decision, what evidence supported a “not affected” conclusion, how remediation was prioritized when the product was “affected,” and how the organization preserved that trail for auditors, regulators, customers and management.

Clarysec treats VEX and CSAF as part of the ISMS operating model. In Zenith Blueprint: An Auditor’s 30-Step Roadmap, this belongs in risk management, supplier security, technological controls and evidence phases. In Zenith Controls: The Cross-Compliance Guide, the same topic connects ISO/IEC 27001:2022 controls with ICT supply chain security, vulnerability management, evidence handling, NIS2, DORA, GDPR and NIST expectations.

Why SBOMs create signals, but VEX creates evidence

An SBOM is a list of ingredients. It tells you what is inside a product or service. When a CVE appears in one of those ingredients, the SBOM tells you that you might be affected.

That signal is valuable, but it is not a conclusion.

A mature software environment can generate thousands of SBOM vulnerability matches. Many are real risks. Many are not exploitable because the vulnerable code is not shipped, not imported, not reachable, not configured, not exposed to untrusted input or mitigated by compensating controls. Without a formal process to record the investigation, teams usually fall into one of two bad patterns.

The first is triage burnout. Engineers chase every vulnerability match with equal urgency, even when the component is a build-time dependency, a dormant code path or an internal-only feature protected by layered controls.

The second is undocumented risk acceptance. Teams close tickets with short comments like “not applicable” or “false positive.” That may feel efficient, but to an auditor it is an uncontrolled decision. To a regulator, it may look like an unmanaged vulnerability.

VEX and CSAF solve this by turning vulnerability noise into structured, auditable vulnerability evidence.

A defensible VEX and CSAF governance process answers five questions:

1. Did we receive or identify the advisory?
2. Did we map it to products, assets, suppliers, customers and personal data flows?
3. Did we determine vulnerability status using defined criteria?
4. Did we document the decision, evidence, owner, approval and review trigger?
5. Did we remediate, disclose, monitor or preserve evidence based on risk?

The difference between “not affected” and “ignored” is evidence.

A VEX “not affected” status should be supported by a rationale, such as the vulnerable component is not present, the vulnerable version is not deployed, the vulnerable code path is not executed, the vulnerable configuration is disabled or a compensating control prevents exploitation. “Under investigation” should have a time-bound follow-up, not become a backlog graveyard. “Fixed” should point to a patch, mitigation, version update, test result and deployment record. “Affected” should enter risk treatment, remediation planning, supplier notification, customer communication and, where relevant, incident or breach assessment workflows.

The Clarysec governance model for VEX status decisions

Every CSAF advisory and VEX statement should be treated as a controlled record inside the ISMS, not as an isolated engineering artifact. The workflow can live in a GRC platform, vulnerability management tool, ticketing system, source control workflow or Clarysec evidence workbook. The important point is that status, evidence, approval and risk treatment remain linked.

This table looks simple, but it changes the control environment. A “not affected” statement becomes a mini risk decision for a particular product and environment. A “fixed” status links vulnerability management to change management and testing. An “affected” status triggers treatment, escalation and possible disclosure. An “under investigation” status gives management a visible, time-bound risk.

Zenith Blueprint reinforces this mindset in Step 13 on Risk Treatment Planning and the Statement of Applicability. It explains that control decisions should be justified by risk treatment, legal or contractual requirements, scope relevance and organizational context:

“In the SoA sheet, mark each control as ‘Yes’ (applicable) or ‘No’ (not applicable). Provide a Justification/Notes.”

For VEX, “not affected” follows the same discipline. It is not a casual ticket closure. It is a justified decision that must stand up to review.

Step 19 of Zenith Blueprint addresses technical vulnerability management:

“Stay informed about new security bugs (via vendor alerts, CVE feeds, etc.) for your software and hardware. Assess which are relevant (do we use this software? how critical is the bug?) and promptly apply fixes or mitigations.”

CSAF helps receive structured advisories. SBOMs help determine component presence. VEX helps document exploitability and status. The ISMS governs the decision.

Policy evidence before the critical advisory arrives

A VEX program fails when the first critical advisory arrives before roles, criteria and evidence requirements exist. Policies should already define vulnerability intake, escalation, recording, supplier obligations, exception handling and evidence preservation.

For SMEs, the Vulnerability and Patch Management Policy - SME establishes the monitoring obligation:

“Monitors systems for vulnerabilities and available patches using vendor alerts, threat intelligence advisories, and operating system notifications”

This clause, from Roles and Responsibilities, policy clause 4.2.1, applies directly to CSAF intake. CSAF advisories are vendor or ecosystem vulnerability advisories that must be monitored, correlated and triaged.

The same SME policy sets audit readiness expectations:

“Maintain accurate records of applied patches, outstanding issues, and exceptions to ensure audit readiness”

From Objectives, policy clause 3.4, this is where VEX becomes more than a technical file. If a team does not patch because a product is “not affected,” that exception needs evidence, approval and traceability.

For enterprise environments, the Vulnerability and Patch Management Policy is explicit:

“Monitor threat advisories (e.g., CVE, CISA KEV, vendor bulletins) and escalate critical vulnerabilities.”

From Roles and Responsibilities, policy clause 4.5.1, this clause supports a structured intake channel for CSAF, CVE, vendor bulletins and exploit intelligence. It also requires escalation when a VEX status is “affected” or “under investigation” for a critical product.

The enterprise policy also states:

“All critical and high-risk vulnerabilities must be recorded in the ISMS Risk Register and monitored until remediated or covered by an approved exception.”

This clause, from Governance Requirements, policy clause 5.3, is the compliance anchor. A VEX “not affected” statement for a critical CVE is defensible only when it is treated as an approved exception with evidence. A VEX “fixed” statement closes the loop only when remediation is verified.

Risk scoring also needs context. The same policy refers to:

“Risk assessment (based on CVSS, asset criticality, threat intelligence)”

From Risk Treatment and Exceptions, policy clause 7.2.2, this supports a blended triage model. CVSS alone is not enough. A medium-severity vulnerability actively exploited in a critical identity component may be more urgent than a critical CVSS issue in unreachable code.

Application and secure development policies extend the same discipline into engineering and suppliers. The Application Security Requirements Policy - SME requires teams to track:

“known vulnerabilities and remediation status.”

From Policy Implementation Requirements, policy clause 6.4.2.3, this maps neatly to VEX statuses. The same policy requires agreements to:

“specify obligations for vulnerability disclosure, response times, and patching.”

From Governance Requirements, policy clause 5.3.2, this becomes a practical supplier clause: provide timely advisories, identify affected versions, issue VEX status where possible, define remediation timelines and support customer disclosure.

For enterprise secure development, the Secure Development Policy expects:

“Known vulnerability scanning (CVEs, OSS Index, etc.)”

From Governance Requirements, policy clause 5.4.3, this gives engineering a defined mechanism for matching advisories to components and triggering VEX analysis.

When a vulnerability becomes an incident or potential legal matter, evidence discipline becomes essential. The Evidence Collection and Forensics Policy - SME states:

“A simple chain-of-custody log (e.g., Excel file or template document) must be maintained for each incident.”

From Governance Requirements, policy clause 5.3.1, this is the boundary between routine VEX triage and incident-grade evidence handling. If exploitation is suspected, logs, advisory records, analysis notes, communications and forensic artifacts need traceability.

Mapping VEX and CSAF to ISO 27001, NIS2, DORA, GDPR and CRA

The strongest VEX programs are not standalone security engineering projects. They are mapped into the control system the organization already uses.

Under ISO/IEC 27001:2022, the ISMS must account for interested parties, legal and contractual obligations, interfaces and dependencies with other organizations. That scope logic is essential for VEX because supplier advisories, customer commitments, open-source components and outsourced services all affect vulnerability decisions.

The most relevant Annex A controls include 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements, 5.21 Managing information security in the ICT supply chain, 5.22 Monitoring, review and change management of supplier services, 5.28 Collection of evidence and 8.8 Management of technical vulnerabilities. Secure development controls 8.25 to 8.29 are also relevant where the organization builds software or digital products.

NIS2 increases the governance pressure. Article 21 requires appropriate technical, operational and organizational measures, including risk analysis, incident handling, business continuity, supply chain security, secure acquisition, development and maintenance, vulnerability handling and disclosure, control effectiveness, cyber hygiene, cryptography, HR security, access control, asset management and authentication. Article 20 requires management bodies to approve and oversee cybersecurity risk management measures. That makes VEX metrics suitable for board reporting.

DORA applies from 17 January 2025 for financial entities in scope. It requires an ICT risk management framework, identification and classification of ICT assets, vulnerabilities, dependencies and ICT third-party services, incident management, resilience testing, third-party risk management and management oversight. For financial entities, VEX records are especially useful when a supplier advisory must be tied to critical or important functions, contractual obligations and incident classification.

GDPR enters when exploitation could affect personal data. A vulnerable API, library or service that could expose customer records requires assessment against confidentiality, integrity, availability and breach notification criteria. A VEX “not affected” conclusion may support a decision not to notify, but only if the organization can show why no personal data breach occurred.

The Cyber Resilience Act adds product governance. As CRA obligations phase in, manufacturers and other economic operators need repeatable vulnerability handling, security update, coordinated disclosure and evidence processes. CSAF can structure advisories. VEX can clarify which products and versions are affected, fixed or not affected.

What the Clarysec cross-compliance guide adds

Zenith Controls is valuable because it maps technical work to audit expectations and overlapping frameworks. For VEX and CSAF, three areas matter most: ICT supply chain security, technical vulnerability management and collection of evidence.

For ICT supply chain security, Zenith Controls identifies ISO/IEC 27002:2022 control 5.21 as “Managing information security in the ICT supply chain.” It explains that 5.21 extends supplier relationship controls 5.19 and 5.20 into ICT-specific risks, including insecure software components and third-party or open-source libraries. It connects to secure engineering, secure coding, security testing, access control, evidence collection, secure development lifecycle and outsourced development.

This is precisely where CSAF and VEX operate. A supplier advisory is not just a message from a vendor. It is evidence of supplier cybersecurity practice. A supplier VEX statement is not just a convenience. It can support procurement, due diligence, monitoring and customer risk decisions.

For technical vulnerability management, Zenith Controls identifies control 8.8 as “Management of Technical Vulnerabilities.” It classifies the control as preventive, supporting confidentiality, integrity and availability, and tied to threat and vulnerability management. It also notes that vulnerability management connects to malware protection, configuration management, change management, threat intelligence and monitoring.

A particularly useful Zenith Controls passage for VEX governance is:

“Effective vulnerability management prioritizes based on real-world threats. Threat intelligence informs which vulnerabilities are actively exploited, guiding patch prioritization.”

That is the difference between raw SBOM matching and risk-based VEX triage. Presence alone is not enough. Exploitability, asset criticality, exposure and threat activity must shape the decision.

For evidence, Zenith Controls identifies control 5.28, “Collection of evidence,” as corrective and tied to detect and respond. It connects 5.28 to incident response, logging, monitoring and event reporting. It also maps evidence handling to ISO/IEC 27037:2012 for identification, collection, acquisition and preservation of digital evidence.

When a vulnerability is merely theoretical, routine VEX records may be enough. When exploitation is suspected, the organization must move into incident evidence handling. Logs, supplier communications, customer notices, patch records and forensic artifacts need integrity, preservation and traceability.

A practical VEX evidence pack from alert to closure

Return to Anya’s FinTech platform. A CSAF advisory arrives for a critical vulnerability in lib-common-utils, which appears in the SBOM for the payment gateway. A disciplined response would create one evidence pack, not scattered Slack messages and screenshots.

Step 1: Create the advisory intake record

Open a vulnerability case in the ISMS evidence tracker. Attach the CSAF advisory, CVE reference, supplier bulletin, SBOM match and affected asset list. Assign a vulnerability owner and business system owner. Link the payment service to customer impact, personal data, financial processing and operational criticality.

Policy basis: Vulnerability and Patch Management Policy requires monitoring advisories and escalating critical vulnerabilities. ISO basis: Annex A control 8.8. NIS2 basis: vulnerability handling and secure maintenance. DORA basis: ICT vulnerability identification and incident readiness.

Step 2: Set preliminary status to under investigation

Initial status should often be “under investigation,” especially for critical advisories. Set a decision deadline, such as 24 hours for externally exposed or critical services. Record interim controls, such as heightened monitoring, temporary feature restrictions or WAF rules. This prevents a critical advisory from disappearing into unmanaged backlog.

Step 3: Perform exploitability analysis

Engineering should answer practical questions:

• Is the vulnerable version present in production?
• Is the vulnerable function imported, called or reachable?
• Is the vulnerable configuration enabled?
• Is the component exposed to untrusted input?
• Is authentication required before the vulnerable path can be reached?
• Are compensating controls effective?
• Is there active exploitation or credible threat intelligence?
• Could exploitation affect personal data, financial transactions or service availability?

In Anya’s case, static analysis confirms the component is present, but the vulnerable function is not invoked by the payment gateway. No execution path exists in production. The team prepares a “not affected” VEX statement with supporting evidence.

If the analysis had shown that an authenticated admin job could reach the vulnerable function, the correct status would be “affected,” not “not affected.” The team would then create a risk treatment plan, open a change ticket, patch or mitigate and update the status to “fixed” only after verification.

Step 4: Link the case to the Risk Register and supplier record

Critical and high-risk cases should be entered in the ISMS Risk Register unless they are closed by an approved, evidenced exception. Supplier advisories should also link to the supplier register, contract obligations and monitoring records.

This supports Zenith Blueprint Step 23, which instructs organizations to compile suppliers, classify them by access and operational control, embed security expectations in contracts and define monitoring procedures for supplier changes.

Step 5: Validate the fix or approve the exception

For “fixed,” attach the patch version, change record, CI/CD pipeline result, dependency scan, container image digest, deployment evidence and regression test. For “not affected,” attach code path analysis, configuration evidence, version evidence, compensating control evidence and approval.

If customers use self-hosted versions or the vulnerability could affect external users, coordinate communication. The Coordinated Vulnerability Disclosure Policy provides the model:

“Where a confirmed vulnerability could affect customers or service users, the Communications team, under the direction of the VRT, shall prepare a security advisory. The advisory shall include an overview of the issue, without disclosing exploit details, the affected products or versions, mitigation guidance or patch download instructions, and support contact information.”

From Implementation Requirements, policy clause 6.8, this maps directly to CSAF publication discipline.

Step 6: Preserve evidence if exploitation is suspected

If logs show attempted exploitation, move from vulnerability handling to incident response and evidence collection. Start a chain-of-custody log, preserve logs, record SIEM queries, export relevant events, snapshot affected systems if needed and document who handled each artifact. Link the incident case to the VEX record.

What auditors and regulators will ask for

Auditors do not all test VEX and CSAF governance the same way. A single evidence pack should satisfy multiple lenses.

Zenith Controls includes audit methodology guidance that fits this table. For ICT supply chain security, auditors using ISO/IEC 19011 and ISO/IEC 27007 will examine procurement policies, RFP templates and supplier management processes to verify ICT-specific security requirements. They will sample contracts for secure development, vulnerability disclosure and software authenticity clauses.

For technical vulnerability management, auditors review vulnerability management policy, scan frequency, asset coverage, prioritization based on risk, remediation timelines and responsibilities. For evidence collection, they test whether chain of custody, secure storage and preservation were followed in real incidents.

This is why VEX governance should never end at the status label. The label is the summary. The evidence trail is the control.

Management metrics that make VEX board-ready

ISO/IEC 27001:2022 requires performance evaluation, internal audit and management review. NIS2 requires management oversight. DORA requires governance over ICT risk. VEX and CSAF create metrics that translate engineering work into executive risk visibility.

Useful management review metrics include:

• Number of critical CSAF advisories received this quarter
• Percentage matched to SBOM components
• Number and age of VEX statuses by affected, not affected, fixed and under investigation
• Overdue “under investigation” cases
• Supplier advisories without sufficient affected version data
• Critical vulnerabilities accepted as approved exceptions
• Time from advisory intake to VEX decision
• Time from affected decision to remediation
• Number of cases with potential personal data impact
• Number of customer advisories issued

These metrics help management ask better questions. Which suppliers fail to provide actionable vulnerability data? Which products have the longest remediation times? Which teams leave investigations open? Which vulnerabilities may affect personal data or critical functions?

Common failure patterns to eliminate

The first failure is treating SBOM matching as exploitability analysis. A component match is a signal, not a conclusion.

The second failure is using “not affected” without a rationale. Auditors will ask why. Was the code path unreachable? Was the vulnerable feature disabled? Was the version different? Was the component only used at build time? Was the conclusion approved by product security?

The third failure is letting “under investigation” remain open. This status is useful only with an owner, deadline and interim controls.

The fourth failure is separating supplier governance from vulnerability governance. Supplier contracts should require timely vulnerability disclosure, response times, patching obligations, advisory content and evidence support.

The fifth failure is ignoring personal data and customer communication. A vulnerability that could expose personal data needs GDPR assessment. A confirmed product vulnerability that could affect customers needs coordinated disclosure discipline. A financial service dependency may require DORA incident analysis.

The sixth failure is weak evidence preservation. Zenith Blueprint warns in Step 23, control 5.28, that evidence is often overlooked:

“what you can prove matters just as much as what actually happened”

That sentence captures the 2026 reality. Security teams are not only fixing vulnerabilities. They are proving that decisions were timely, risk-based and controlled.

Next steps for auditable vulnerability evidence

If your organization already has SBOMs, the next maturity step is not another inventory spreadsheet. It is governance over vulnerability status, supplier advisories and disclosure evidence.

Start with four actions:

1. Add CSAF and VEX intake to your vulnerability management procedure.
2. Define approval criteria for affected, not affected, fixed and under investigation.
3. Link VEX records to your ISMS Risk Register, supplier register, asset inventory, SBOM repository and incident process.
4. Test the process with one recent critical advisory and produce an audit-ready evidence pack.

Clarysec can help you implement this quickly using Zenith Blueprint, Zenith Controls and the relevant policy set, including the Vulnerability and Patch Management Policy, Vulnerability and Patch Management Policy - SME, Application Security Requirements Policy - SME, Secure Development Policy, Evidence Collection and Forensics Policy - SME and Coordinated Vulnerability Disclosure Policy.

The winning question in 2026 is not “Do we have an SBOM?” It is “Can we prove, for every serious advisory, exactly how we determined vulnerability status, treated the risk and communicated the result?”

Book a Clarysec assessment or request the relevant policy toolkit to turn VEX and CSAF into audit-ready vulnerability evidence before the next critical advisory reaches your board.