Introduction
ZeroPath now generates reachability-aware SBOMs, VEX, and AI-BOM documents straight from the inventory your scans already built. Every export, whether CycloneDX, SPDX, a standalone VEX document, or an AI-BOM, says the same thing your dashboard says. And the vulnerability verdicts are driven by whether the vulnerable code is actually reachable in your application.
A Component List Isn't an Answer
A Software Bill of Materials tells you what's in your software. It doesn't tell you what to do about it. Feed a raw SBOM into a scanner and you get back every CVE that has ever touched any version of any dependency you ship, most of which your code never calls. Security teams drown, and auditors get a document nobody can act on.
VEX, the Vulnerability Exploitability eXchange, was meant to fix this by recording which vulnerabilities affect a product. But in practice, VEX statements get written by hand, and "is this exploitable?" is answered from memory. A generic SBOM generator can list your packages. It has no idea which of them your code reaches.
ZeroPath closes that gap. Our SBOMs are built from the same inventory that powers reachability analysis, so every vulnerability ships with a verdict grounded in whether the vulnerable code path is actually invoked.
Reachability Decides the Verdict
For each vulnerable dependency, ZeroPath emits a CycloneDX VEX statement in one of three states:
-
not_affected: the vulnerable code path isn't reachable from your application. ZeroPath attaches the justification code_not_reachable, the exact claim a component-listing tool can't make.
-
exploitable: the vulnerable path is reachable and the finding is confirmed. Fix these first.
-
in_triage: reachable, but not yet validated.
Unreachable vulnerabilities aren't dropped. They ship as not_affected so an auditor can see you evaluated them rather than missed them. Every CVE also carries CISA KEV (known-exploited) and FIRST EPSS (exploit probability) as machine-readable properties, so a finding that is reachable, known-exploited, and high-EPSS sorts to the top of the queue.
Reachability is an AI-assisted signal, not a proof of safety, and ZeroPath says so in the document itself. It's the strongest lever for cutting SBOM noise, but a "not reachable" verdict lowers priority rather than closing a critical, KEV-listed advisory on its own.
One Inventory, Every Format
The same normalized inventory produces every document, so they can't contradict each other:
-
CycloneDX 1.6 for engineering and security tooling: component graph, dependency relationships, and optional embedded VEX.
-
SPDX 2.3 for procurement and legal: license declarations and relationships in the format their tools already expect.
-
A standalone CycloneDX VEX document for teams that consume exploitability separately from the component list.
-
An AI-BOM, covered next.
These documents are assembled from your stored inventory, not a fresh third-party scan kicked off at export time. That's why the package set, ordering, and dependency edges match your UI exactly.
An AI-BOM for the AI You Actually Ship
Your dependency scanner doesn't recognize a model file, an agent config, or an MCP server. ZeroPath does. When a scan finds AI in your codebase, from LLM SDKs and agent frameworks to vector databases, model weights, prompt templates, and MCP servers, it sorts each one across seventeen component kinds and exports a standards-format CycloneDX ML-BOM. One scan produces two bills of materials: your dependency SBOM and its AI-native companion, built for the inventory expectations in the EU AI Act and the NIST AI Risk Management Framework.
License Clarity That Doesn't Block Your Build
Every package's license is sorted into one of five obligation buckets: permissive, weak copyleft, strong copyleft, network copyleft, and unknown. We split network copyleft (AGPL and Affero) out from ordinary strong copyleft (GPL) on purpose. For anyone running a hosted service, AGPL's network-use trigger is the obligation most likely to bite, and a coarse "copyleft: yes or no" flag hides exactly that.
The classification is deterministic and informational. It exists to help legal and engineering teams find obligations fast, not to act as legal advice, and ZeroPath never fails a build or blocks a release on license grounds.
The No-Fabrication Rule
Decisions built on invented data are worse than decisions built on no data. ZeroPath's SBOMs never fabricate. There are no placeholder CVSS scores, no guessed versions, and no "not exploited" claim we can't back up. When a license lookup fails, that package is marked license-unknown, never quietly listed as having no license. When ZeroPath doesn't know something, it leaves the field out and says so. For a document that goes to an auditor, a customer, or your own incident responders, a visible gap is more useful than a confident guess.
Getting Started
Reachability-aware SBOMs are available now. If you're already on ZeroPath:
-
Run at least one SCA scan on a repository. This builds the inventory that VEX and AI-BOM draw from.
-
Open the repository, choose Generate SBOM, and pick CycloneDX, SPDX, standalone VEX, or AI-BOM.
-
Wire the download into your release pipeline, audit tickets, or customer trust portal.
If you're new to ZeroPath, book a demo to see reachability-aware supply chain security end to end. Most teams are scanning within five minutes of connecting GitHub.
Read the docs → zeropath.com/docs/sca/sbom-exports
ZeroPath is the AI-native application security platform that autonomously finds, verifies, and fixes exploitable vulnerabilities, consolidating SAST, SCA, secrets, and IaC into a single reasoning engine.
