Key takeaway
A VEX statement needs a product-specific impact assessment. Preserve its rationale and scope rather than turning a component match into a security conclusion.
Ask which product decision is being preserved
A component inventory can identify software associated with a vulnerability. A product-impact assessment asks another question: does that vulnerability affect this particular product in its stated form? A useful historical archive connects the vulnerability, exact product scope, issuer’s assessment and supporting rationale. It does not turn every inventory match into an incident, or every dismissed match into proof that the product is secure.
OpenVEX defines statements around products, vulnerabilities, impact status and timestamps. Its specification distinguishes statuses such as affected, not_affected, fixed and under_investigation. The status is an assertion to interpret within that structure. Preserve the evidence behind it as well as the compact label, especially when an archive is being simplified for a recipient who did not perform the original assessment.
Reconstruct a scoped not-affected assertion
This hypothetical review uses OpenVEX 0.2.0 as its declared format. Product P release 1.4 has an identified build. Its fictional issuer records vulnerability V-EXAMPLE-7 as not_affected with the justification vulnerable_code_not_present and evidence reference E7. The vulnerability identifier is invented; no live weakness or real software is described.
The completed decision preserves the issuer’s assertion for that build and requests E7 before relying on its factual basis. It does not independently conclude that the code is absent. A second row copies the rationale to all future releases without new evidence. A third gives another product a not_affected status but omits both justification and impact statement. Those are different defects: unsupported scope expansion and an incomplete statement under the selected format.
| Statement | Retained scope and rationale | Completed review decision |
|---|---|---|
| V1 | P release 1.4; identified build; vulnerable_code_not_present; E7 | Preserve scoped issuer assertion; assess E7 separately |
| V2 | P, all future releases; copied V1 rationale | Hold expansion; evidence for one build does not establish future composition |
| V3 | Q release 2.0; not_affected; no justification or impact statement | Incomplete under selected OpenVEX rule; return to technical owner |
Check the chosen format without confusing it with proof
For not_affected statements, the OpenVEX 0.2.0 specification requires a justification or impact statement and recommends its machine-readable justification labels. Those labels make materially different assertions: a missing component is not the same as a present component whose vulnerable code cannot execute. Retain the original label and any explanatory text. Do not normalize every rationale to low risk.
CSAF 2.0 expresses the VEX profile differently. Its profile tests require a corresponding impact statement for each known_not_affected product, represented through the specified flags or threats structure. That is useful comparison evidence, not permission to rename fields between formats and assume they retain identical meaning. Record the format and edition actually used by the archive.
A structural check can find V3’s missing information. It cannot establish whether E7 correctly demonstrates the code condition in V1. Assign that substantive review to the responsible product-security specialist. A complete document and a supported technical determination are separate evidence layers; neither is a blanket promise about every vulnerability in the product.
A changed build needs an applicability decision
In the illustration, release 1.5 adds a different component build. Keep V1 associated with release 1.4 while the owner reviews whether its rationale applies to 1.5. Do not let a product-family alias silently carry the conclusion forward. A later statement may narrow, revise or replace an assessment, but its existence should not erase what the earlier statement actually covered.
The working record should identify the product/version or build, vulnerability, status, issuer, statement timestamp, supporting evidence and applicable format. Keep references to build or analysis evidence inside the authorized system. If only the final label survives, describe a status archive with missing rationale rather than reconstructing a favorable explanation from memory. That limitation can change which questions the history can answer.
Describe the assessment history without publishing the weakness
An initial inventory can state that product-scoped assessments, rationale categories and revision links are retained. It need not reveal current vulnerabilities, exploit paths, customer deployments or restricted source code. Start with fictional rows. The presence of an issuer statement does not establish that the company can license every attachment or that a receiving program wants this category.
The completed review holds V2 and V3, preserves V1 as an issuer assertion and assigns E7 for technical review. Use Readiness to track those tasks and Due diligence to identify the recipient’s intended use. A permissioned introduction through VOID does not provide a security certification, production clearance or authority to disclose actual assessments.