Can your supplier’s SBOM and VEX support patch decisions?

Supplier documents can support patch decisions when you can establish who published them, connect them to the software you run, and demonstrate how your tools use and update the resulting decision.

A software bill of materials (SBOM) records software components and their relationships. Vulnerability Exploitability eXchange (VEX) communicates a product’s or component’s status with respect to a specific vulnerability. Review them together to answer a concrete question: can this evidence support the disposition of this finding on this deployed release?

The EU Cyber Resilience Act separates two dates: Article 14 reporting applies from September 11, 2026; general application begins December 11, 2027. Annex I, Part II(1) requires covered manufacturers to document vulnerabilities and components, including preparing an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. This does not establish a general customer entitlement to SBOM or VEX delivery. Cyber Resilience Act, Article 71 and Annex I

Specify customer delivery, access, and update commitments during procurement. The review below proposes buyer acceptance conditions; it is neither a universal document specification nor a determination of regulatory compliance.

Define what you will accept

Agree on the intended use first: investigation support, a reviewed ticket decision, or automated handling. Apply the following checks before allowing supplier evidence to close a finding or defer action.

Start with one SBOM and a relevant VEX statement for a release you operate. Passing this sample supports acceptance only for the tested scope; it does not establish that every product or integration behaves the same way.

Establish origin and release identity

Retrieve the records through a supplier portal or distribution channel whose ownership you have verified. Confirm that the named author and publisher are appropriate for the product. If a third party prepared the records, obtain the supplier’s confirmation that it endorses them for the stated release.

Where signatures are supplied or contractually required, verify them against a trusted supplier identity. Retain the original files, retrieval location, time, and verification result. A hash calculated after download identifies your retained copy and helps detect later changes; it does not establish who authored it.

Match the documents against technical deployment evidence: installed version, build or release identifier, platform, enabled modules, and deployment form. For containers, include the image digest where available. For hosted software, request a documented mapping between your service instance and the supplier’s release designation.

A configuration management database (CMDB) is a record of managed configuration items and their relationships. Use it or another asset inventory to connect the release to an owner. Check procurement or support entitlement when it determines the supplied edition, release channel, or access to updates. Missing entitlement paperwork alone does not invalidate a reproducible technical release match.

Verify scope and component mapping

Ask which bundled, optional, runtime, and container components the SBOM includes. Record dependency depth and known omissions. Component names may differ between sources; components themselves may be repackaged, modified, forked, or statically linked. Request identifiers and supplier explanations that resolve those differences.

Choose a known component finding and trace it from the advisory to the SBOM component, then to the supplier release and deployed asset. Preserve the original identifiers alongside any accepted aliases or mapping rules. Leave ambiguous matches unresolved.

Joint guidance recommends consuming SBOM data within supply-chain risk, vulnerability-management, and asset-management tools. That supports testing the entire handoff, rather than accepting a downloadable file as proof of operational usefulness. A Shared Vision of Software Bill of Materials for Cybersecurity

Translate VEX status into the right action

The community-developed minimum requirements published by CISA describe VEX elements independently of a particular format. They are guidance, not a regulatory mandate. The table separates status meaning and supporting information from the buyer’s proposed ticket response. Minimum Requirements for VEX

Preserve identifiable authorship, document and statement references, versions, and first-issued and last-updated timestamps. Validate how the agreed format represents these elements, including any permitted inheritance. Do not assume that every format uses the same field names or status labels.

As additional buyer conditions, request enough technical explanation to assess applicability, a contact for questions, and a follow-up date for unresolved statements. These conditions supplement the format’s requirements.

Keep product status separate from your deployment’s compensating controls. A firewall, network placement, or customer authentication control does not automatically make an affected product “not affected.” Record those controls separately when considering a temporary deferral. Where a supplier’s assessment depends on product configuration, confirm the precise conditions and whether they apply to your deployment.

Version checks and configuration review may resolve some questions. If they cannot substantiate the claim, request further supplier evidence or arrange appropriately scoped validation. Refer unresolved integration questions to the responsible security or application team.

Demonstrate the complete workflow

Run this exercise in a test workflow before enabling automatic ticket decisions:

1. Retrieve the sample through the verified supplier channel and preserve its origin and revision metadata.
2. Parse and validate the agreed format and version. Check that your tools retain product identifiers, component relationships, status, supporting information, and timestamps. Unsupported fields or parsing errors must remain visible.
3. Import a component finding and demonstrate its association with the correct deployed release. Include another release outside the statement’s scope to check that the decision does not spread to unrelated assets.
4. Apply the VEX statement and inspect the ticket outcome. Confirm the supporting evidence, affected assets, reviewer or automation rule, and resulting action.
5. Import a revised statement and demonstrate that the workflow reopens or changes the previous decision while preserving its history.

For example, in a clearly labeled test case, an initially accepted “not affected” statement could be revised to “affected” for the same release. The workflow should recognize the newer statement, withdraw the previous disposition, and route the required action to an owner. Keep synthetic test records separate from supplier publications.

Agree who publishes corrections, what triggers updates, how customers are notified, and how superseded records remain traceable. Request an example of a corrected publication. A new vulnerability may require a new VEX assessment without changing the composition of an unchanged software release; request an SBOM correction when its contents or scope need correction.

Record the acceptance decision

Record the accepted product and release scope, original documents, verified source, mapping results, import-test results, VEX disposition, reviewer, review date, supplier contact, and recheck triggers. Attach this evidence to the vulnerability record.

Use three explicit outcomes: accepted for the stated use, accepted for investigation only, or returned for correction. If the automation test fails, retain manual review until the failure is resolved.

Reassess when the product or relevant configuration changes, the supplier revises its statement, new advisory information challenges the decision, or an agreed review date arrives. These are buyer review rules, not a universal VEX expiration mechanism.

An SBOM does not itself prove exploitability. A supplier VEX statement does not independently verify your deployment. Keep the acceptance decision bounded by the evidence actually reviewed.

FAQ

Is an SBOM with only top-level dependencies sufficient?

Only for investigations its scope supports. If a finding concerns a transitive dependency that you cannot map, request more detail and continue triage. Do not infer absence from an incomplete inventory.

Can “not affected” justify closing a finding?

It can support a documented non-applicability decision when origin, release scope, justification, and deployment evidence have been checked. Automatic closure also requires a successful workflow test and a functioning revision process.

What if the scanner and supplier disagree?

Preserve both records and reconcile product identity, component mapping, and the technical assessment. Keep the discrepancy unresolved until reconciled or explicitly handled through risk acceptance by the accountable owner. Record compensating controls separately. Risk acceptance may authorize a deferral, but it does not prove the supplier’s statement correct.

Further reading

• Penetration test preparation
• Reporting and risk