Quick answer

An SBOM is an inventory that makes software components visible. VEX communicates an assessment of a vulnerability in a particular product context. They can support the same investigation. Neither closes a finding when the evidence cannot be connected to the release actually running in your environment.

Start with four questions. Is the component present in our release? Does the vulnerability apply to this use? Who produced the assessment and when? Who reopens the decision if the conditions change? This guide turns those questions into a worksheet for procurement and vulnerability management teams.

Inventory and a security decision are different outputs

A product SBOM may contain hundreds of dependencies. A scanner can associate one package with a vulnerability record. That match starts an investigation. Similar package names alone do not prove component identity or an affected version. A matching version range does not explain the business impact in your environment.

The CycloneDX SBOM overview describes component inventory. The CycloneDX VEX overview connects exploitability assessment with product context. The worksheet below is an original DSET proposal for applying that distinction. It is not an official certification checklist.

Connect the evidence to the deployed release

Record more than the product family name. Identify the deployed release and its package or image digest where available. Establish which build the SBOM describes. Distinguish direct dependencies from components introduced through other packages. Missing identity or version information must remain visible as uncertainty.

An SBOM from a test build can differ from the production image. A plugin added after the build may be absent from the inventory. Local configuration can differ from the supplier's assessed configuration. Passing schema validation therefore cannot be the only acceptance criterion. A structurally valid document can still contain incomplete or incorrect inventory.

Record an owner and review date. Keep an evidence copy or integrity digest under your retention rules because a document link may change later. If a signature is available then record its verification result and the trusted signer. A valid signature does not itself prove that the technical assessment is correct.

An eight step decision worksheet

Use one copy for each finding. Record missing evidence as an open question instead of silently assuming a favorable answer.

No Review question Required evidence Decision consequence
1 Does the document match the deployed release? Product version and deployment digest Scope remains unverified without a match
2 Is the component present? Component identity and dependency path Document any false match explanation
3 Is the vulnerability match correct? Vulnerability identifier and affected versions Name similarity is insufficient
4 What conditions does VEX cover? Issuer and product scope and technical rationale Reassess differences in local conditions
5 What is the local exposure and impact? Asset owner and access path and business impact Establish local priority
6 What does current threat evidence show? Dated KEV check and EPSS record Separate observed exploitation from probability
7 Can the selected action be verified? Patch or mitigation plan and acceptance test Assign an owner and target date
8 What reopens the decision? Release change or new evidence trigger Prevent an indefinite exception

Download the SBOM and VEX decision worksheet. Use the owner and result and observation fields to connect the worksheet with your finding record.

Do not turn VEX into a permanent exception

VEX assessments can communicate concepts such as affected or not affected and fixed or under investigation. These are conceptual descriptions here. Field names and permitted values depend on the chosen format. Do not assume that CycloneDX and CSAF or OpenVEX use identical fields.

Read the rationale and scope behind a not affected assessment. A component being absent is different from a vulnerable function being unreachable. The latter may change with configuration or a new call path. Do not extend the assessment to an entire product family or to future releases.

A fixed assessment needs a release reference. A supplier publishing a corrected release does not close a local finding while the old release remains deployed. Under investigation does not mean safe. Assign an owner and a follow up time to the uncertainty. An affected assessment still needs an action plan and subsequent verification.

CVSS and EPSS and KEV answer different questions

CVSS provides a common framework for technical severity. Record the version and vector and metric group. A Base score is not interchangeable with an assessment that includes Threat or Environmental metrics. The FIRST CVSS v4.0 user guide explains these distinctions.

EPSS estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. It is not the probability that your organization will be attacked. A percentile is different from the probability value. Record the date alongside the score. The FIRST EPSS FAQ explains these interpretation limits.

KEV tracks vulnerabilities with evidence of known exploitation. Presence in the CISA KEV catalog is an important threat signal. Absence does not prove safety or that exploitation has never occurred. Interpret the entry alongside product identity and local exposure.

Avoid multiplying unrelated values into a single score without a justified model. A decision should explain which evidence changed the action. A global catalog cannot determine your entire local business risk.

Choosing between two findings: a fictional example

A team receives two findings on the same day. The first has high technical severity. Its supplier assessment covers a different release and component presence in the local release remains unverified. The second matches a component confirmed in production. The affected function is externally reachable and evidence of known exploitation exists.

The team can prioritize rapid mitigation and a verified patch plan for the second finding. It does not close the first finding. It assigns a person and a short investigation window to resolve the scope uncertainty. New evidence can change the order. This decision uses more information than a descending severity list.

This is not a customer case or a claim about a particular CVE. It illustrates a decision that preserves uncertainty. Keep the priority and its rationale together in the report.

Evidence to request from a supplier

Request an SBOM matching the deployed release and a short explanation of its generation process. Obtain the issuer and date of the relevant VEX assessment. Ask for technical reasoning behind a not affected conclusion. For a fixed assessment request the corrected release and migration path. Agree how updates will reach your team.

Internally record the asset owner and completed action. After patching verify that the intended release was deployed and that essential functionality still works. A quiet scanner is insufficient by itself. For a temporary mitigation record its effectiveness and reassessment trigger. An exception needs an accountable risk owner.

Frequently asked questions

Does supplying an SBOM make a product secure?

No. It improves visibility. Completeness and alignment with the deployed release still need review. An SBOM is not a security guarantee or a replacement for a test report.

Can a not affected VEX assessment close a finding?

It can inform the decision when product versions and usage conditions match and the technical rationale has been evaluated. Record the decision and reopening trigger. Do not extend the document beyond its scope.

Is a low EPSS score enough to delay a patch?

Not by itself. Consider known exploitation and external exposure and business impact. The estimate is dated and does not measure all of your organization specific risk.

Must every release reopen every decision?

Check whether release and dependency changes affect the scope of earlier decisions. Reopen the affected ones. Keep the continuing validity of other decisions traceable through evidence and scope matching.

Define an assessment with DSET

To connect SBOM and VEX review with supplier acceptance or vulnerability validation share your scope through DSET cybersecurity services. Product versions and sample evidence and expected deliverables help define a measurable engagement. This guide does not claim a particular certification or guaranteed discovery of every vulnerability.

Related reading: CI/CD pipeline security and supply chain and third party risk management.

Editorial review: 11 October 2026. DSET developed the worksheet for this guide. Primary sources for technical definitions are linked in the text.