.svg)
What's in your own software?
You’re shipping features fast, pulling in third-party components, nested dependencies, random transitive packages from some dev’s weekend project... and you’re calling it secure?
Security reviews miss half of what’s actually running in prod. Dev teams move fast, and security doesn’t have the tools or the time to track every component or assess what’s actually exploitable. When the next zero-day hits, you’ll have no idea where it is, what it touches, or how to prove you’re not exposed.
It's a business risk as much as it is bad hygiene.
At this point, every security program has an SBOM somewhere. Your CI pipeline probably spits one out for every build. Vendors send them along with every update. Compliance teams check the box and move on. But when you look closer, you realize an SBOM is just a list, a static record of what went into the software.
The moment a new CVE shows up, all eyes are on the SBOM. You search for the component, confirm it’s in use, and the panic starts. Tickets open across every affected service. Patching sprints begin. Releases get delayed. And after burning through cycles, you find out the vulnerable function wasn’t even loaded at runtime, the feature it lives in was turned off, and no exploit path exists in your environment.
This is what happens when SBOMs are treated as security controls instead of inventory references. You see what's present, but you can’t tell what matters, so the result becomes a never-ending stream of alerts, false urgency, and wasted effort.
To be clear, SBOMs still serve a purpose. They help you:
But the second you're flooded with CVEs, none of that helps you decide what’s actually exploitable. You’re still stuck reviewing every alert manually, chasing down theoretical risks that have no real impact.
But with VEX, not as a replacement for SBOM, but as the critical layer of context you’ve been missing. With a well-formed VEX document, you can quickly assess:
That context is what lets you move fast without wasting time. You stop delaying features for issues that don’t matter, focus response on what’s real, and you finally get out of the cycle of reacting to every CVE like it’s a breach waiting to happen.
So yes, you need SBOMs. But stopping there leaves you guessing. The last thing you need is more lists. You need answers. And without VEX, you’re not getting them.
Once you’ve got an SBOM, the next thing you need is clarity about what can actually be exploited. That’s what VEX is designed to give you. It’s a structured way to declare whether a known vulnerability in a component is exploitable in a specific context. It doesn’t scan, it doesn’t fix, and it doesn’t guess. It gives you a signal, assuming you know how to interpret it.
VEX is designed to answer a simple but critical question: is this known issue exploitable in the way we’ve implemented or deployed this component? It gives you a structured and machine-readable way to track that. Think of the Log4j chaos. Just spotting it in your codebase wasn’t enough. What mattered was whether it was actually reachable, whether the vulnerable function was active, and whether the JVM was configured in a way that prevented exploitation. In cases where teams had already applied mitigations like runtime flags, a properly issued VEX told them they weren’t at risk.
That’s the upside. But here’s where things start to break down. VEX only works when the underlying assumptions are correct. It doesn’t run scans or verify your configuration. It just declares a status like “not affected” or “fixed” based on how a vulnerability interacts with the component in a specific context. If your environment doesn’t match that context, or if a mitigation mentioned in the VEX isn’t actually present in your deployment, then the VEX is useless. Worse, it creates false confidence.
So before relying on any VEX data, your team needs to confirm a few critical things:
It’s tempting to treat VEX like a green light, especially when it saves time and unblocks a release, but it’s only accurate when the implementation matches the declaration. That’s where teams trip up. They trust the VEX without checking the setup. They assume mitigations are applied without confirming them. And they move on before verifying whether the context actually fits.
Used correctly, VEX is one of the most effective tools you have to focus your remediation efforts and avoid wasting time on non-issues. But that value depends on validation. You still need to check your runtime, your config, and your architecture. Otherwise, you’re just accepting risk blindly.
Security teams can define policies, review artifacts, and evaluate risk posture, but they don’t own the build process. That’s why SBOM and VEX only work when engineering teams treat them as part of the development lifecycle instead of something external or optional. The thing is if your dev and DevOps teams aren’t generating accurate SBOMs and supplying real exploitability context, then VEX becomes useless and your entire supply chain visibility breaks down.
One of the most common mistakes teams make is treating SBOMs like static documents. Something generated once per release, stored somewhere, and forgotten. That doesn’t work. Every build needs to produce an SBOM, and that SBOM must reflect exactly what’s been compiled, containerized, or deployed. To get this right:
The SBOM must remain coupled with the artifact it represents. That way, when a new CVE surfaces, your security team can pinpoint which version of which artifact contains the vulnerable component.
It’s not enough to know a vulnerable package exists. But is it actually being used? Is the affected functionality enabled? Are deployment controls already mitigating the issue? That context starts with the people writing and assembling the code. To support meaningful VEX accuracy, developers must:
This context allows security teams or automation tools to validate whether a known CVE is relevant, and under what conditions it becomes a real risk.
The entire point of VEX is to document whether a vulnerability is exploitable in a given environment, and if it isn’t, then why not. That requires clear and explicit documentation of mitigations, especially when you’re relying on configuration changes or architecture-level controls. Your team needs to:
A VEX statement saying “component not affected due to runtime config” only holds up if that runtime config is present, enforced, and verifiable.
For SBOM and VEX to be operationally useful, they must be part of the build and deploy pipeline, instead of something generated manually or bolted on during release review. The entire point is to map vulnerabilities to actual software artifacts and their real-world configurations. That means every artifact must have a corresponding SBOM generated at build time and any VEX logic must be tied to the current state of that artifact’s usage.
Here’s what that looks like in a CI/CD context:
When these pieces are in place, you stop reacting to CVEs with guessing. Instead, your teams can ask: which version of the service is deployed in prod, which exact packages are present, and what is the exploitability status in that context?
CI/CD integration is what makes SBOM and VEX actionable. Without it, you're left trying to match vulnerabilities against outdated snapshots and undocumented runtime behavior, which defeats the entire point of supply chain risk visibility.
If software from a vendor runs in your environment, you’re responsible for the risk. Use this checklist to hold suppliers to the same standards you apply internally, and cut through vague promises or incomplete documentation.
Make sure every vendor provides:
Red flag: “We’ll send the SBOM on request” — this usually means they’re not maintaining it properly.
Require that vendors also deliver VEX documents that:
Red flag: “We reviewed the CVE and it doesn’t apply” — without evidence, this statement is useless.
Ask vendors to show:
Red flag: VEX documents that only reflect vendor opinion with no traceable data source or validation logic.
Tie SBOM and VEX delivery to enforceable contract obligations:
Bottom line: If your vendors can’t show you what’s in their software and why it’s safe, they’re not ready to be in your environment.
It’s not enough to generate SBOMs and collect VEX files. The only way they reduce real risk is when they’re fully embedded into your pipeline, generated automatically, validated continuously, and tied directly into how your teams manage vulnerabilities and deploy software.
Start by integrating SBOM creation into your existing build process. Every artifact should have an SBOM generated at build time, using tools that are compatible with your stack. Depending on your language and ecosystem:
This makes the SBOM reproducible, traceable, and always in sync with what’s deployed.
VEX only adds value when it matches how the software actually behaves in your environment. That means validating exploitability assumptions. In practice, this looks like:
Security tooling should not accept VEX at face value. Your pipeline needs logic that verifies the conditions behind each VEX statement are actually enforced in your environment.
The end goal is to reduce alert fatigue without skipping real risk. That means pulling SBOM and VEX data into the systems your teams already use to triage and remediate. To get there:
This helps your teams stop wasting time on noise and focus on vulnerabilities that truly matter in your context.
Operationalizing SBOM and VEX is only as strong as the environment around it. If your build systems are exposed or your pipeline is misconfigured, then the entire process can be compromised. This is where lessons from DevSecOps come into play. Key actions include:
These practices need to run every time software is built and shipped.
But only if you make them actionable.
Attackers don’t wait for you to prepare a checklist weeks before an audit. They exploit gaps in your build process, your dependencies, and your vendor relationships while you’re launching features. That means SBOM plus VEX is now a core control if you want to stay ahead of risk instead of scrambling after it.
One risk many security leaders overlook is complacency. Once you see an SBOM and a VEX document, it’s easy to assume you’re safe. Reality is vulnerability status changes constantly with new CVEs, dependency updates, and configuration drift. Unless you embed SBOM/VEX validation into your pipeline and treat it as living documentation, you’ll end up blind to newly exploitable changes.
On the opportunity side, supply‑chain security is becoming a hygiene standard for compliance frameworks and customer trust. Organizations treating it as infrastructure now will gain a competitive advantage in regulation-heavy industries. Over the next 12 to 18 months expect more mandates around supply-chain risk transparency and stronger pressure from clients to prove provenance and exploitability posture before you deploy.
If you're ready to turn supply‑chain risk from a liability into a managed vector, you don’t have to go it alone. At we45 we help organizations embed SBOM and VEX into their pipelines by enforcing build provenance, enabling real‑time vulnerability management, and aligning supply‑chain practices with compliance frameworks. When you’re ready, we’ll help you bring clarity and control to your supply chain security.
An SBOM (Software Bill of Materials) is merely a static inventory list of components and dependencies within the software. The main problem is that it treats every vulnerability (CVE) found in a listed component as an alert, leading to "alert fatigue," false urgency, and wasted effort. You know what's present, but the SBOM alone cannot tell you what is actually exploitable in your specific runtime environment. You end up chasing down theoretical risks that have no real impact, delaying releases, and starting patching sprints unnecessarily.
VEX (Vulnerability Exploitability eXchange) provides the critical layer of context missing from an SBOM. It is a structured declaration of whether a known vulnerability in a component is exploitable in a specific product or deployment context. A well-formed VEX document allows you to quickly assess if the vulnerable component is loaded at runtime, if the attack path is reachable in your architecture, or if exploitability is already mitigated by configuration, isolation, or compensating controls. This context allows teams to focus their response only on real, actionable risks.
The critical question VEX is designed to answer is: Is this known issue exploitable in the way we've implemented or deployed this component? It provides a structured, machine-readable way to track this exploitability status.
VEX only works if its underlying assumptions are correct. The risk of trusting it blindly is that it creates false confidence. VEX declares a status (e.g., "not affected") based on a specific context, but it does not scan or verify your live configuration. If your deployment environment does not match the context referenced in the VEX, or if a mentioned mitigation is not actually enforced, the VEX is inaccurate and potentially useless. Your team must confirm the correct component version is used and that all necessary mitigations are present and enforced in your runtime environment.
Developers and DevOps teams must treat SBOM and VEX as integral parts of the development lifecycle, not as external or optional steps. This involves three key actions: Generate SBOMs Automatically: Integrate SBOM generation directly into CI/CD pipelines for every build, using standardized formats like CycloneDX or SPDX, and including all direct and transitive dependencies. Map Exploitability at the Development Level: Developers must understand and track how dependencies are used, which features are enabled, and what runtime controls (like feature flags or sandboxing) are in place, as this context is necessary for meaningful VEX accuracy. Make Mitigations Explicit and Traceable: Clearly document and enforce mitigation logic in code, configuration files, or build metadata so that the VEX statement is verifiable in production.
Vendors should use valid VEX status types to explicitly communicate the exploitability of known vulnerabilities. These status types include: Not_affected Affected Fixed Under_investigation
Operationalizing SBOM and VEX involves embedding them into the build and deploy pipeline: Automate Generation: Every build job must include an SBOM generation step using tools like Syft or Trivy, storing the SBOM alongside the artifact. Tightly Version and Link: The SBOM must be tightly versioned and linked to the exact artifact and commit it represents. Derive and Validate VEX: VEX should be derived as part of a policy validation step, which includes checking consistency between the VEX status (e.g., "not affected") and the actual runtime configuration (e.g., JVM flags, deployment manifests). Centralize Data: Publish all SBOMs and VEX outputs to a centralized, queryable system for downstream security tools and compliance scanners.
CI/CD integration is essential because it makes SBOM and VEX actionable and prevents them from becoming stale. It ensures that every artifact has a current SBOM generated at build time and that VEX logic is tied to the current state of that artifact's usage and its real-world configuration. Without this integration, teams are left reacting to vulnerabilities based on outdated snapshots, which defeats the purpose of gaining supply chain risk visibility.
Customers must set clear requirements for their software suppliers: SBOMs: Require a machine-readable SBOM (SPDX or CycloneDX) with every release, generated automatically during the build process, covering full dependency coverage, and provided via a queryable repository, not ad hoc documents. VEX: Require VEX documents that explicitly list known vulnerabilities, use valid VEX status types, include the technical reasoning behind the status (e.g., disabled features, runtime config), and are updated on a consistent cadence. Evidence: Demand evidence of how the VEX determination was made, based on build context or runtime validation, not just vendor opinion. SLA: Tie the delivery and update of both SBOM and VEX to enforceable security SLA and contract obligations.
%20Vulnerabilities%20What%20Every%20Enterprise%20Should%20Know.png)
