I've been thinking about software supply chain security for a long time: long enough that I sometimes joke I wasn't the one who invented any of this, I was just the guy who refused to shut up about it.
My work at NTIA and later at CISA put me at the center of the SBOM movement as it was taking shape, and VEX (which stands for Vulnerability Exploitability eXchange) was something we identified early on as a critical missing piece of the puzzle. One common early concern expressed around SBOM was that parties looking at SBOMs would be worried about a potentially vulnerable dependency,
For those less familiar: VEX is, at its core, a binding of three things. A software product. A known vulnerability. And a status: do you need to care about the vulnerability, or not? Think of it as a machine-readable security advisory, one that's structured enough to be automated and specific enough to actually answer the questions that matter.
One skeptic I've come across described it this way: "All VEX is, is someone on the internet told me I don't have to care." And honestly? That's fair. But that kind of applies to the entire vulnerability ecosystem. All of open source is someone on the internet building something that you're resting your entire product on. Trust, provenance, and traceability are the work, VEX just gives us a structure for it.
The way I like to explain VEX's relationship to SBOMs: an SBOM turns on your warning dashboard lights. VEX, from a trusted source, lets you turn them off efficiently, so you can focus on what's actually important.
Editor’s Note: This blog is based on a recent webinar Allan conducted with FOSSA: “A Practical Guide to VEX in 2026.” You can view the full on-demand recording at this page.
VEX Workflows for Software Producers
The signal-to-noise problem in vulnerability management is real, and it's getting worse. The number of published CVEs keeps climbing. When Log4J hit, I watched companies field phone calls all day from customers whose products were written in C, where, of course, there was no Log4J exposure. That kind of noise is expensive and exhausting.
VEX is the mechanism that lets producers communicate clearly: here's what's relevant, here's what isn't, and here's why. The work that informs VEX documents — evaluating whether a vulnerability actually matters for your product — is work that a good security team is already doing. VEX just makes it legible and shareable.
For software producers, the workflow breaks down into a handful of steps:
1. Track your exposure. If you have an SBOM program (and you should), you already have a foundation. Combine that with your vulnerability feeds: the CVE feed, Google's OSV database, private feeds. Use all of them. Know what's in your product, and what might be a cause for concern.
2. Do the analysis. This is the hard work, and it requires judgment and a pretty detailed understanding of your product. Some of it can be accelerated with tooling, but you need to be careful. It's easy, especially with modern AI tools, to assert something isn't reachable, and then have the next version of Claude find a way to reach it. Be rigorous.
3. Document the determination. This is where VEX comes in. The determination itself is the hard part. VEX gives you a set of options to explain why a vulnerability isn’t a concern, as well as a way to communicate that you have fixed an issue, or that you’re still working on it. Documenting it is comparatively easy, but critical. Capture who made the decision, when, and why.
4. Establish a publishing policy. You don't need to issue a VEX for every CVE that comes out. CISA has published good guidance on this: issue a VEX when it's in your SBOM, when your audience (customers, leadership) will care about it, or when it could damage trust in your sector. You can publish via API, through a standard project repo directory, through an RSS feed. The goal is predictability.
5. Close the loop. The only thing worse than no data in security is stale data. Make sure you have a process for updating statements as circumstances change; these may include when a vulnerability that was under investigation gets resolved, something gets added to the KEV list, or a new version is patched.
VEX can help manage risk and expectations for both AppSec teams and product security teams, but it’s very important to recognize that those two audiences are subtly different. If your focus is internal DevSecOps, you're building a shared ground truth for your team, and overproducing data is fine if your processes are solid. If you're in a product security environment, you need to think carefully about what your customers actually need. Data crossing organizational boundaries should be both appropriately sanitized and understandable without full local context. Product Security and AppSec can represent different workflows with different outputs, and it's worth being intentional about which you're building.
VEX Workflows for Software Consumers
The challenge for software consumers isn't just getting VEX data. Rather, it's integrating it meaningfully into how you make security decisions.
1. Collect. Different vendors may share VEX data slightly differently. VEX documents can be published in four different formats (Common Security Advisory Framework and OpenVEX, as well as CycloneDX and SPDX). For large enterprise suppliers, you may need custom ingestion harnesses. The goal is to land everything in a common place, ideally the same system where you're managing your SBOMs.
2. Correlate. What are your vulnerability scanners flagging? What are other threat intelligence sources focusing on? VEX data is one input, and you should use it alongside the others. You're turning off warning dashboard lights, but you need to do it deliberately.
3. Establish trust levels in advance. When you receive a VEX statement, you need a framework for evaluating it. Is this a random person on the internet, or is this the actual maintainer of the software? If it's the maintainer and you don't trust their "not affected" claim, what are your alternatives? Think this through before you need it.
4. Integrate into prioritization. VEX feeds into your vulnerability management workflow — helping you decide what to patch, what to deprioritize, and what other mitigations to bring online while you wait. For high-risk environments, you might pre-configure responses: a KEV (CISA’s Known Exploited Vulnerabilities list) kill switch that yanks something from production automatically the moment it hits the list, or a network segmentation playbook that triggers when something moves to "affected."
5. Measure outcomes. VEX is also a metric. How quickly are you responding? Are you protecting your organization? Some of the most forward-thinking companies I've spoken with are planning to use their VEX records as annual customer communications — here's everything we triaged and cleared on your behalf, here's the unnecessary patching cycles we saved you from.
It's also worth being clear-eyed about trust hierarchies for different justification types. There are five main reasons a vendor might say a product is "not affected" by a vulnerability: the component isn't present; the vulnerable code isn't included in the build; the vulnerable code isn't in the execution path; the code can't be controlled by an attacker; or existing mitigations (like input sanitization) prevent exploitation. The first two are relatively verifiable. The last three require more judgment — and for high-assurance environments, they may not be accepted at all. I’ve spoken with leaders in some sectors who have said that they simply won’t trust claims from certain vendors. Know what your organization's threshold is before you're in the middle of a crisis.
Actionable Recommendations
Here's the practical guidance I give to organizations that are ready to start or scale a VEX program:
Step zero: Be an internal ambassador. We did a good job socializing SBOMs. VEX is still catching up. Make sure everyone in your organization understands what it is and why it matters. It's a weird name, but it's a catchy one.
Get it into your CI/CD pipeline. The right place to implement VEX is where you're already tracking your SBOM — ideally in your build and deployment systems. That's where the data is freshest and where automation has the most leverage.
Integrate with ticketing and workflow systems. Once you have VEX data flowing, it needs to connect to how your team actually works. Does a new statement move something up or down in priority? Who signed off on a determination? Can you trace a VEX assertion back to the person who made it before you publish it to a customer?
Update as you go. VEX isn't a one-time exercise. It's a continuous documentation of the work your security team is already doing. Build the habit of updating statements as determinations change.
Choose the right format for your use case. CSAF (Common Security Advisory Framework) is the most powerful option for complex enterprise product hierarchies. It handles product trees and version ranges well, though it requires tooling investment. CycloneDX VEX is tightly integrated with the SBOM world and works well for AppSec and DevSecOps pipelines. SPDX 3.0 is graph-based and highly flexible, with strong linking capabilities across supply chain artifacts. OpenVEX is the lightweight option. It’s simple to implement, easy for open source maintainers, and writable by hand if needed. The right choice depends on your audience and your existing tooling.
Think about regulatory context. VEX isn't currently required by any regulation directly — but it's increasingly important as supporting evidence under frameworks that are. The EU Cyber Resilience Act is driving vulnerability reporting obligations that VEX makes dramatically easier to fulfill. The FDA is actively analyzing SBOMs on medical device submissions; being able to accompany those with VEX statements that explain why flagged components don't represent a safety risk is a genuine compliance advantage. Don't wait for explicit mandates. Get ahead of them.
Conclusion
The software supply chain problem isn't going away. Vulnerability volumes are rising. AI is accelerating both the discovery of vulnerabilities and the complexity of assessing them. The organizations that will manage this well are the ones building structured, documented, continuously updated processes — not the ones scrambling to respond to the next Log4J at 2 a.m.
VEX is a key part of how we scale supply chain analysis to meet that challenge. It's not magic. It's not a regulatory mandate. It's not going to fix anything by itself. But it gives us a shared language for documenting the work we should already be doing, and it makes that documentation actionable, machine-readable, and shareable across the ecosystem.
You can start a VEX program today. The tooling is there. The formats are there. The regulatory tailwinds are there. The main thing left to do is start.
And then tell more people about VEX.
To learn more about how FOSSA supports VEX workflow automations, you can get in touch with their team by filling out the form on this page.
Allan Friedman is a leading expert in software supply chain security and led the SBOM and VEX communities at NTIA and CISA. He currently works in an advisory capacity helping organizations implement practical security programs.