Connect the two with a short, six step story: an advisory arrives, you search your SBOMs, you decide whether the vulnerable code is reachable, you fix or mitigate, you tell affected customers, and you update your records. Describe your real steps and owners, not a perfect process.
Why the link matters
CISA's 2026 minimum elements guidance says that after learning new vulnerability information, an organization can assess whether its SBOMs contain or reference a vulnerable component, and that this significantly improves response time compared to organizations without SBOMs. It also says its conclusion that an SBOM is "data about software components" only turns into insight once it is analyzed (see Sources).
A buyer asking about your SBOM is usually really asking: will you find out fast, and will you tell me?
The six steps
- Intake. Where do advisories come from? Name your sources, such as advisory feeds and your scanner's rescans.
- Search. Check your SBOMs for the affected component and version. If you keep one per release, you can tell which versions are affected.
- Assess. Decide whether the vulnerable function is actually reachable in your code and whether your configuration exposes it. Record the reasoning.
- Act. Update, patch, mitigate or accept, according to your own policy. Name the owner.
- Notify. Tell customers who are affected, in the way your agreements describe. You can issue a VEX statement to say whether a product is affected or not.
- Record. Update the SBOM or status record so your history is accurate.
VEX in one paragraph
VEX stands for Vulnerability Exploitability eXchange. CISA's document on minimum requirements for VEX describes it as specifying the minimum elements to create a VEX document. The OpenVEX project describes its specification as designed to be minimal, compliant, interoperable and embeddable, and not tied to a specific SBOM format (see Sources). In practice, VEX is how you tell a buyer "this advisory does not affect us, and here is why."
What not to promise
Do not state a fixed fix time unless you measure and meet it. Do not promise to notify "immediately." Say what you actually do, such as "we assess within our normal business days and notify affected customers once we have a confirmed status."
A short script
"When an advisory lands, we search our stored SBOMs for the component. We check whether our code reaches the vulnerable function, decide how to respond, and notify customers who are affected. If we are not affected, we can send a VEX statement explaining why."
Evidence to offer
- A redacted example of a past advisory and your recorded decision.
- Your intake sources and owner.
- Your notification approach.
If you have not handled a real one yet, run a tabletop with a recent public advisory and keep the notes.
Where Safeguard fits
Safeguard offers reachability analysis, zero day discovery and autonomous remediation with fix pull requests (off by default, with every category on Manual), plus SBOM and dependency scanning. Those can support steps two through four. See the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow how a finding is judged exploitable or not, which is step three of the story.
Quick check
Do I need VEX to have a response story?
No. VEX is a useful way to communicate status, but you can start with a clear internal process and plain written notices.
What if we have never handled an advisory?
Run a tabletop on a recent public advisory and write down the steps and decision. It gives you a real example to show.
Sources
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA
- Minimum Requirements for Vulnerability Exploitability eXchange (VEX), CISA
- OpenVEX specification
Last reviewed: 19 October 2026.
