CISA · Minimum Requirements for VEX
Product-vulnerability scope, statement metadata, statuses and conditional information such as justification or an impact statement.
Read the minimum requirements →Working sheet 03 · Product assurance · No email gate
SBOM and VEX: make the vulnerability claim reviewable.
Review one product configuration, one component and one vulnerability. Connect the inventory record to the exploitability rationale, supplier evidence and the response decision your team actually owns.
A supplier statement and an accepted product decision are separate records. Record the claim as received, then assemble its supporting evidence. A completed checkbox records evidence availability; release and response decisions remain with the authorised product owner. The CSV is a human review record, not a machine-readable VEX document.
One product · one component · one vulnerability
Keep the context with the evidence.
Use identifiers and repository references rather than credentials or confidential source material. Values and notes are saved in this browser profile on this device when storage is available; they are not sent to CUP. Export a separate copy for each review.
The status field records the source claim using the four concepts in CISA's minimum requirements. Record the exact format and value in the notes if your source uses different terminology. An absent or unmapped status remains unresolved.
Twelve review checkpoints
From component presence to an accountable response.
For each checkpoint, record the evidence reference, accountable owner, unresolved gap and next review date. Use the final two checkpoints to record the response decision and its reassessment conditions.
Local saving and export become available when the worksheet loads.
| Checkpoint | Evidence to assemble | Decision to resolve | Review status and notes |
|---|---|---|---|
| 01 · Product and released state | Product identifier, version, build or firmware digest, configured features and deployed or planned release state. | Does the claim cover this exact product configuration and software baseline? | |
| 02 · SBOM provenance and component identity | SBOM author, generation date, covered artefact, component identifiers, dependency relationship and inventory limitations. | Can the inventory record be tied to the reviewed artefact, including bundled or transitive components? | |
| 03 · Vulnerability matching | Vulnerability record, affected-version rationale, vendor advisory and evidence for forks, backports or build-specific changes. | Is this a supported component match or only a name/version heuristic? | |
| 04 · VEX issuer and statement revision | Statement author, document identifier, timestamp, revision history, product identifiers and source-authenticity checks. | Who made the claim, what authority do they have, and is a newer statement available? | |
| 05 · Status and scope of the claim | Exact source format, status and covered product-vulnerability pair; meaning of unknown or under-investigation states. | What does this status assert for this scope, and what remains unresolved? | |
| 06 · Technical justification | For a not-affected claim: justification or impact statement, supporting code-path or reachability analysis and reviewable test references. | Can an independent reviewer reproduce why the vulnerability is said not to affect this product? | |
| 07 · Configuration and attack preconditions | Enabled features, input paths, privilege assumptions, interfaces and environmental conditions used in the assessment. | Would a different configuration or reachable interface invalidate the rationale? | |
| 08 · Mitigation dependency | Applicable inline controls, required configuration, deployment evidence, bypass assumptions and monitoring owner. | Does the claim depend on a control whose actual presence and continued operation can be demonstrated? | |
| 09 · Fixed artefact and verification | Vendor fix reference, corrected build or digest, backport evidence, deployment state and regression-test results. | Is the fix present in the reviewed artefact rather than merely available or cryptographically signed? | |
| 10 · Supplier evidence and constraints | Requested clarification, supplier response owner, support status, remediation constraints and escalation date. | What decision remains with the product owner if supplier evidence or a supported fix is unavailable? | |
| 11 · Owned product response | Named decision owner, affected scope, remediation or mitigation plan, interim restrictions and communication record. | What action is authorised now, what uncertainty is accepted, and who owns that decision? | |
| 12 · Reassessment and supersession | Review date, change triggers, superseding statement, retained prior rationale and the owner who reopens the assessment. | Which change to code, configuration, threat evidence or mitigation would require a new decision? |
Primary references · reviewed 1 November 2026
Keep the review separate from the source specification.
The checkpoint questions are CUP engineering prompts. For machine-readable statements, use the applicable format specification and its current validation rules.
CycloneDX · VEX
Exploitability information in the context of the product that contains a component. Use the relevant specification for format-specific states.
Read CycloneDX guidance →OpenVEX · Specification
Statement structure and status-specific expectations for product-vulnerability assertions.
Read the OpenVEX specification →