You’ve done everything right. You’ve generated your Software Bill of Materials (SBOM), you’re scanning it for vulnerabilities, and you’re staying on top of the latest CVEs. But then the alert comes in: a critical vulnerability has been found in a transitive dependency, a library that’s three or four levels deep in your supply chain. Your SBOM is a mess. Now what?
This is the new reality of software development. Our applications are built on a foundation of open-source components, and it’s not enough to just know what’s in our own code. We need to understand the risks that are lurking in our dependencies, and our dependencies’ dependencies.
But how do you separate the signal from the noise? How do you know which vulnerabilities are a real threat to your application, and which are just false positives?
### Introducing VEX
This is where VEX comes in. VEX, or the Vulnerability Exploitability eXchange, is a new standard that’s designed to help you answer this very question. In simple terms, a VEX document is a statement that says, “I’ve looked at this vulnerability, and here’s what I’ve found.”
A VEX document can tell you a number of things about a vulnerability:
* **Is it exploitable?** Does your code actually call the vulnerable function?
* **Is it mitigated?** Have you put any controls in place that would prevent the vulnerability from being exploited?
* **Is it a false positive?** Is the scanner just wrong?
By correlating the information in your SBOM with the information in a VEX document, you can start to get a much clearer picture of your actual risk.
### A Practical Guide to Triaging a Critical Dependency CVE
Let’s walk through a practical example. Your scanner has just found a critical vulnerability in a library called `lib-foo`, which is a transitive dependency of your application. Here’s how you can use VEX to triage this vulnerability:
**Step 1: Generate a VEX document.**
The first step is to generate a VEX document for the vulnerability. There are a number of tools that can help you with this, including Grype, Trivy, and Dependency-Track.
**Step 2: Determine if the vulnerable function is called.**
The next step is to determine if your code actually calls the vulnerable function in `lib-foo`. This is the most important question you need to answer. If your code doesn’t call the vulnerable function, then the vulnerability is not exploitable in your application.
There are a number of ways to do this. You can use a static analysis tool to trace the call graph of your application, or you can use a dynamic analysis tool to monitor your application at runtime.
**Step 3: Look for mitigating controls.**
Even if your code does call the vulnerable function, you may have other controls in place that would prevent the vulnerability from being exploited. For example, you might have a web application firewall (WAF) that would block the exploit, or you might be running your application in a sandboxed environment that would limit the damage that could be done.
**Step 4: Create a VEX statement.**
Once you’ve gathered all of this information, you can create a VEX statement that summarizes your findings. This statement should include the following information:
* The vulnerability ID (e.g., CVE-2025-XXXXX)
* The name of the vulnerable component (e.g., `lib-foo`)
* A statement of whether or not the vulnerability is exploitable in your application
* A description of any mitigating controls you have in place
### Building an Automated Workflow
The real power of VEX comes when you start to automate the process. By integrating VEX into your CI/CD pipeline, you can create a workflow that automatically:
1. Ingests your SBOM
2. Scans it for CVEs
3. Enriches the findings with VEX and EPSS (Exploit Prediction Scoring System) data
4. And auto-generates tickets only for the vulnerabilities that are truly exploitable.
This will free up your developers to focus on the vulnerabilities that really matter, and it will help you to build a more secure and resilient supply chain.
### The Future of Supply Chain Security
The days of simply generating an SBOM and calling it a day are over. In the new world of software supply chain security, we need to be able to operationalize this data to make real-time, risk-based decisions. VEX is a critical tool in this new world, and it’s one that every developer and security professional needs to understand.
0 Comments