Sooner or later, someone will ask for your SBOM. A customer's procurement team, an assessor working through a compliance framework, or a downstream pipeline that will not deploy without one. Producing a component list at build time is the easy half. The more important part is the follow-up question: which of these components are actually vulnerable, and what are you doing about it?
DefectDojo Pro now answers both questions from data you already have. Any Asset can export its dependency inventory as a standards-compliant SBOM and it’s finding statuses as a machine-readable VEX document. Both are built from the same Dependency Locations that your SBOM imports and scan findings populate, giving you an export that accurately describes what your tooling has observed rather than a spreadsheet someone assembled by hand last quarter. These documents are meant to be consumed by compliance pipelines, downstream tooling, and AI agents, not just read by humans.
Every Asset page carries an Export panel with three options:
|
Export type |
What you get |
|---|---|
|
SBOM |
The component inventory only |
|
VEX |
A standalone document describing the exploitability of this Asset's findings |
|
SBOM with vulnerabilities (VDR) |
The inventory with an embedded vulnerabilities block carrying the VEX analysis |
The same documents are available over the API:
GET /api/v2/sbom/{asset_id}/
GET /api/v2/sbom/{asset_id}/?spec=spdx
GET /api/v2/sbom/{asset_id}/vex/
SBOMs export as CycloneDX 1.6 or SPDX 2.3 JSON. VEX is CycloneDX only, since SPDX has no VEX profile. Components carry their Package URL, group, version, and artifact hashes, plus the license expression whenever the SBOM import recorded one. The Asset page and the API emit the same specification version, so a document exported from either path is interchangeable with the other. Component references in the VEX are the same Package URLs the SBOM uses, which means downstream tools can consume the pair together without translating identifiers.
A VEX document exists to tell consumers which vulnerabilities in an inventory actually matter. In DefectDojo, that determination already happened. It is the triage work your team does every day, and the export translates it directly into VEX analysis states:
|
DefectDojo Status |
VEX Analysis State |
|---|---|
|
Active |
exploitable |
|
Risk Accepted |
exploitable, with a will_not_fix response |
|
Out of Scope |
not_affected |
|
False Positive |
false_positive |
|
Mitigated |
resolved |
Statements are grouped one per vulnerability and analysis state, with every affected component listed underneath. Findings without a vulnerability ID are omitted, because VEX statements are keyed by vulnerability identifier.
One rule is worth calling out. When the same vulnerability and component pair carries conflicting statuses across findings, the least-resolved status wins. Exporting resolved while any observation is still active is the dangerous direction to be wrong in, so DefectDojo refuses to.
Aggregate exports are useful, but regulators and customers usually ask about a specific release. With Asset Versions enabled, both exports accept a version parameter:
GET /api/v2/sbom/{asset_id}/?version=5.2.0
GET /api/v2/sbom/{asset_id}/vex/?version=5.2.0
A versioned SBOM is built from the BOM snapshot recorded for that release: the components that version declared, the licenses recorded for it, and the dependency structure the imported document described, with the version stamped on the document itself. A versioned VEX answers for that release specifically. A finding with a fixed_in record for 5.2.0 reports resolved there, while the same finding stays exploitable at the versions where it was found. One finding row, per-version answers.
Two conservatisms are deliberate. A finding mitigated on the Asset, but with no fixed_in evidence for the requested version, keeps its status for that version, because claiming a fix in a release requires evidence for that release. And nothing is inferred across versions: a finding found in 5.0 and fixed in 5.2 says nothing about 5.1, since version strings carry no ordering.
The same caution applies to the documents themselves. Request a version the Asset does not have and you get a 404, not the aggregate inventory wearing a version label. A document labelled 5.2.0 that does not describe 5.2.0 is the wrong thing to hand a downstream consumer or a regulator.
Both endpoints require V3 Locations to be enabled, and both respect Asset-level permissions: an Asset the requesting user cannot view returns a 404. The export labels in the UI are read live from the server, so when the exporters adopt a newer specification version, the labels follow.
The full endpoint reference, including parameters and per-release behavior, is in the documentation. If you are running DefectDojo Pro with V3 Locations enabled, the Export panel is already on your Asset pages.