VEX helps a manufacturer answer a narrower question than an SBOM can answer: does a known vulnerability in a component actually affect this specific product or release, and what evidence supports that conclusion? A Vulnerability Exploitability eXchange record makes that product-specific status machine-readable. It can strengthen vulnerability handling and retained evidence for Cyber Resilience Act (CRA) work, but the CRA does not require VEX by name and a VEX status is not a conformity decision.
What VEX adds to an SBOM
A software bill of materials (SBOM) describes software components and their relationships. That inventory is essential for discovering where a vulnerable component may be present, but component presence and product impact are different facts.
A vulnerability database can identify a CVE against a component version. The product team still has to determine what that means in the product's actual context. The vulnerable function may not be included in the built artifact, may not be reachable in the deployed configuration, may be protected by a relevant mitigation, or may be directly exposed. The result can also differ between product variants and releases.
VEX is designed to communicate this contextual analysis in a structured form. CycloneDX describes VEX as a way to convey exploitability of a vulnerable component in the context of the product in which it is used. CSAF 2.0 defines a VEX profile whose main purpose is to state whether a particular product is or is not affected by a vulnerability and why.
This distinction also explains why vulnerability information should not simply be treated as permanent SBOM content. Vulnerability knowledge changes over time, while an SBOM should remain a reliable statement of what a particular artifact or release contains. BSI TR-03183 Part 2 recommends handling vulnerability information through dedicated formats such as CSAF, including its VEX profile, rather than making the SBOM itself the changing vulnerability record.
How VEX maps to CRA vulnerability handling
The CRA requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements, including by drawing up an SBOM covering at least top-level dependencies. It also requires vulnerabilities to be addressed and remediated without delay in relation to the risks posed to the product, together with effective security testing and review.
Article 13 adds a broader documentation obligation. Manufacturers must systematically document relevant cybersecurity aspects, including vulnerabilities of which they become aware and relevant information received from third parties, and update the cybersecurity risk assessment where applicable.
VEX can support that operating model because it gives the product team a structured place to record a vulnerability impact decision against an identified product scope. It does not replace the CRA duties behind the decision. A not affected status does not remove the need to investigate the vulnerability, retain the reasoning, reconsider the conclusion when relevant facts change, or remediate when the product is actually affected.
The practical value is therefore traceability: the manufacturer can show which vulnerability was assessed, which product or release was in scope, what conclusion was reached, and why.
Treat vulnerability status as a lifecycle state
A VEX decision should be treated as a current state in a vulnerability workflow, not as a permanent label attached to a CVE.
A useful lifecycle can look like this:
- Candidate identified. A scanner, supplier advisory, security researcher or other source associates a vulnerability with a component in the product.
- Under investigation. The team confirms component identity, product scope and whether the vulnerable behaviour is relevant in the product context.
- Impact determined. The product is recorded as affected or not affected, with supporting rationale and evidence.
- Action tracked. If affected, remediation, mitigation or another documented response is assigned and followed through the relevant releases.
- Fixed or superseded. A corrected release can be linked to the decision and the earlier affected state retained as history.
- Reassessment triggered. New exploit information, a configuration change, a new component version or a new product release can require the decision to be reopened.
This avoids a common failure mode in vulnerability management: a status is entered once, the context disappears, and nobody can later tell whether the conclusion still applies to the current product.
Scope every VEX decision to the product and release
The same component version can have different exploitability outcomes in different products. Even inside one product family, an optional feature, build flag, operating environment, mitigation or configuration can change the result.
For that reason, the decision record should identify the narrowest practical scope. Capture at least:
- the product and variant;
- the release, version or artifact identity;
- the component name and version or another stable component identifier;
- the vulnerability identifier and source;
- the current impact status;
- the date of the analysis and the decision owner; and
- the exact releases or version ranges to which the status applies.
Avoid using an organisation-wide statement such as “CVE-XXXX is not affected” when the analysis was performed only for one product release. A VEX record is useful precisely because it can preserve the relationship between the vulnerability and the affected product context.
A not-affected decision needs a reason
A not affected result is operationally valuable only when another reviewer can understand why it was assigned.
The CSAF VEX profile makes this expectation explicit. For a product listed as known_not_affected, CSAF requires a corresponding impact statement, either as a machine-readable flag or as a human-readable justification explaining why the vulnerability cannot be exploited. CycloneDX likewise supports analysis information such as state, justification, response, detail and affected product references.
The supporting reasoning may involve evidence such as:
- the vulnerable code is not present in the shipped artifact;
- the relevant function is not reachable in the product's supported configuration;
- an architectural or runtime control prevents the required attack path;
- the component is present only in a build-time context and not in the delivered product; or
- the reported vulnerable version does not match the component actually used in the release.
These are examples of questions to investigate, not automatic exemptions. The strength of the conclusion depends on the evidence. A package name mismatch, an assumption about reachability or an undocumented configuration should not be converted into a durable not affected decision without verification.
Retain the evidence behind the status
The VEX document should not be the only record of the analysis. It is the structured conclusion; the underlying evidence should remain retrievable.
Depending on the product and vulnerability, useful evidence can include:
- the release-specific SBOM or component inventory used to establish presence;
- build metadata or artifact hashes tying the component to the exact release;
- configuration records showing whether the relevant feature is enabled;
- static or dynamic analysis showing whether vulnerable code is present or reachable;
- reproduction or negative test results;
- architecture or threat-model records explaining the attack path;
- supplier or maintainer information used in the assessment;
- mitigation details and verification results;
- the reviewer, approval or decision record; and
- the remediation release or security-update evidence when the product is affected.
The evidence should make it possible to reproduce the reasoning later. This is particularly important when a decision is challenged by a new advisory, a different scanner result or a product change months after the original analysis.
VEX and remediation are complementary
VEX is sometimes discussed mainly as a way to suppress false positives, but its more important role is to communicate a product-specific status consistently.
If the product is affected, the VEX record should not become an endpoint. The CRA requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed to the product. The vulnerability record should therefore connect to the remediation decision, affected releases, security update and verification evidence.
Likewise, a fixed state should be tied to a release that actually contains the correction. If a vulnerable release remains supported, its earlier state and the corresponding update path should remain visible rather than being overwritten by the newest release's result.
This distinction matters for auditability: “fixed in version 4.2” is not the same statement as “version 4.1 is no longer affected.” The old release may still exist in the field and may still need an update.
Choose a VEX format by the exchange workflow
There is no CRA rule requiring one VEX syntax. The choice should follow the systems and organisations that need to produce and consume the information.
CycloneDX can represent vulnerability analysis alongside product and component context in its broader BOM model. Its VEX capability supports product-specific exploitability information and analysis fields that can travel with CycloneDX-based workflows.
CSAF is an advisory framework, and its VEX profile provides structured product status for vulnerabilities, including fixed, known_affected, known_not_affected and under_investigation. It also defines requirements around product identity and justification for a not-affected conclusion.
The engineering decision is less about which label is more familiar and more about interoperability. Check whether suppliers, customers, vulnerability-management tooling and downstream automation can preserve the product identity, version scope, status and rationale you need. Converting between formats is only useful when that meaning survives the conversion.
A practical VEX workflow for CRA readiness
A repeatable process can be kept relatively small:
- Ingest the vulnerability candidate. Preserve the source and the identifier rather than relying only on a scanner's display text.
- Resolve component identity. Confirm that the component and version correspond to what is actually present in the product release.
- Resolve product scope. Identify every release or variant that requires a separate impact decision.
- Investigate exploitability. Evaluate the vulnerable behaviour in the actual architecture, configuration and intended product context.
- Record the status and rationale. Use a machine-readable VEX state and retain the evidence supporting it.
- Link the response. If affected, connect remediation, mitigation, verification and security-update work to the decision.
- Share the appropriate result. Provide downstream consumers with the product-specific status where the supply-chain or customer workflow requires it.
- Reassess on change. Reopen the decision when relevant vulnerability intelligence, product configuration, component versions or releases change.
- Preserve history. Keep superseded decisions so the organisation can reconstruct what was known and decided for a particular release at a particular time.
This workflow keeps VEX in its proper role: a structured exchange and evidence layer around an engineering vulnerability decision.
VEX becomes difficult to govern when status, evidence and release scope live in separate tools. AA-sec is designed around traceability between SBOM and component data, vulnerability work, security evidence, decisions and exact product or lifecycle context, which aligns with keeping vulnerability decisions tied to the right release. AA-sec does not determine exploitability or CRA conformity; those remain engineering and legal decisions for the manufacturer.
Key takeaway
VEX is useful for CRA readiness because it turns a product-specific vulnerability impact conclusion into a structured, exchangeable record. Its value depends on the quality of the analysis behind it: precise product and release scope, a clear status, evidence-backed rationale, a link to remediation when required, and a mechanism to revisit the decision when facts change.
Keep the boundary clear. An SBOM tells you where to investigate; VEX records the current product-specific conclusion; the manufacturer's vulnerability-handling process provides the analysis, remediation and retained evidence that the CRA requires.