Both of you have a part. The supplier decides whether the vulnerable code is exposed in their product and ships a fix. You decide how to protect your own deployment while you wait. Start by asking for an exploitability statement, not a patch, because many listed components turn out to be harmless in context.
Why a listing is not a finding
An SBOM says a component is present. A vulnerability database says that component version has a known flaw. Neither says the flaw can be triggered in this product. CycloneDX describes VEX as a way to convey the exploitability of vulnerable components in the context of the product in which they are used, and says it helps avoid unnecessary mitigation. CISA describes VEX as an attestation that indicates whether a product is affected by a known vulnerability.
So the first message to the supplier should ask for status, not demand a patch.
The four VEX statuses
The OpenVEX specification defines four status values. They give you a common vocabulary even if the supplier does not use the format.
| Status | Meaning in the spec | What you do |
|---|---|---|
| not_affected | No remediation is required | Record the justification, set a review date |
| affected | Actions are recommended to remediate or address it | Ask for a fix timeline, plan mitigations |
| fixed | These product versions contain a fix | Confirm you run, or can upgrade to, that version |
| under_investigation | Not yet known whether the versions are affected | Set a date for the supplier to update |
For not_affected, the spec also defines justification values such as component_not_present and vulnerable_code_not_in_execute_path. Ask for one. A bare "not exploitable" is hard to check.
Your own steps while you wait
- Check where the supplier's software runs in your environment. Is it internet facing? Does it handle sensitive data?
- Check for exploitation signals in public sources, such as whether the flaw appears in CISA's Known Exploited Vulnerabilities catalog. Confirm any claim by opening the catalog yourself.
- Apply compensating controls you control: network restrictions, disabled features, tighter permissions.
- Write the decision down, with date and owner.
Setting a deadline
CISA notes that whether and when to issue VEX is a business decision for most suppliers. You cannot assume it will arrive on its own. Ask politely for an answer by a date, and make the date proportional to exposure. A flaw in an internet facing component deserves a shorter window than one in an internal batch tool.
What if they do not reply
Record the request and the date. If the supplier is Tier 1 for you, escalate through the account owner. If the supplier cannot explain the status of a known flaw, treat the component as affected for your own risk decisions until they can.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how exploitability context changes the priority of the same finding.
Safeguard's reachability analysis and SBOM scanning address the same question for software you build or run, and the free scan is at gold.safeguard.sh/scan.
Quick check
Does a vulnerable component in an SBOM mean the product is vulnerable?
Not necessarily. It means the component is present and has a known flaw. Whether the flaw can be triggered depends on how the product uses it.
Is VEX mandatory for suppliers?
CISA describes the decision to issue VEX as a business decision for most suppliers. Check your contract for any specific terms.
Sources
- Vulnerability Exploitability eXchange (VEX), CycloneDX
- OpenVEX specification
- When to Issue VEX Information, CISA
- Software Bill of Materials (SBOM), CISA
Last reviewed: 19 October 2026.
