SCA SBOM Exports

Overview

ZeroPath’s SBOM service generates export-ready CycloneDX, SPDX, VEX, and ML-BOM documents directly from the SCA and AI inventories your scans already produced. An SBOM built from the SCA inventory reuses the same normalized dependency graph that powers alerting, so the artifact matches what you see in the UI. The same inventory drives dependency coverage and per-package license data, so an SBOM is only as complete as the scan behind it. The pre-scan snapshot fallback described below uses a standard component scanner and may differ, and does not apply to the VEX or ML-BOM formats — see Data Sources.

Request

Accepts a request tied to a scan. You can optionally specify an SCA scan for richer inventory data; by default the scan’s own SCA inventory is used. SBOM, SPDX and VEX exports need that inventory to still be retained (see Retained inventories); ML-BOM exports never do.

Process

The job is queued and processed asynchronously; poll its status or receive a webhook when it finishes.

Build

The SBOM is built from the chosen data source (preferably the SCA inventory).

Upload

Uploads the JSON artifact to managed object storage and returns a pre-signed download URL.

Track

Tracks status, attempt count, and expiration so you can poll or receive webhook updates.

Request Flow

Submit

Choose the repository and scan, desired format (CycloneDX JSON, SPDX JSON, standalone VEX, or ML-BOM), and, for CycloneDX JSON, whether to include embedded VEX data. Jobs can be created through the UI or API. The API accepts either a specific scan identifier or a repository and branch, in which case the latest finished scan for that branch is used automatically.

Process

ZeroPath processes the job, hydrates the dependency inventory, and generates the artifact. Automatic retries handle any interruptions.

Store

Finished SBOMs are uploaded to ZeroPath’s artifact bucket with a time-limited retention policy (24 hours by default, configurable per tenant).

Retrieve

The API returns a signed URL; optional webhooks fire when the job transitions to Succeeded or Failed.

From a repository’s Inventory tab, Export SBOM stages the artifact for the scan shown on that tab (the selected branch’s latest finished scan). The branch selection on the Inventory tab flows directly into the export, so the artifact always matches what you are viewing.

Retained inventories

Every SCA scan writes a full dependency inventory. ZeroPath automatically retires superseded inventories at scan completion: the newest finished inventory per branch and the inventory attached to the newest completed full scan are kept; all earlier generations are retired inline (packages that active findings still reference are preserved). The scan record itself, its findings, and their full history are never deleted.

A CycloneDX, SPDX or VEX export pinned to a retired scan is refused at request time with 412 PRECONDITION_FAILED (“SCA inventory for scan … was retired on …; export the latest scan”). A job that was already queued when the retirement happened fails on its next attempt with the same message: “The dependency inventory for this scan was retired on <date> because a newer scan superseded it. Export the latest scan.”
ML-BOM exports are unaffected: they are built from the AI inventory, which is not retired.
scans.getScan returns scaScan.inventoryRetiredAt and sca.listManifestsForRepository returns inventoryRetiredAt, so an integration can pick an exportable scan without guessing from an empty package list; a retired scan’s manifest list contains only the packages findings still reference.

Formats & VEX Support

CycloneDX JSON
SPDX JSON
Embedded VEX
Standalone VEX
ML-BOM

Best for tooling that expects component graphs, dependency relationships, and embedded VEX. When VEX is requested, each vulnerability carries a CycloneDX analysis.state: not_affected when the vulnerable code path is not reachable, exploitable when it is reachable and confirmed, or in_triage when it is reachable but not yet validated. ZeroPath also includes CWE references, a CVSS rating when the advisory carries real CVSS data, and KEV/EPSS exploit intelligence as zeropath:-namespaced properties.When the scan has AI Inventory data, this export is automatically enriched with the AI/ML components ZeroPath detected — no separate request required. See Artifact Contents for what that adds.

Aligns with procurement/legal workflows. ZeroPath includes annotations for direct vs transitive dependencies, license declarations, and dependency relationships (DEPENDS_ON, DESCRIBES). SPDX does not carry VEX or AI Inventory data — use CycloneDX JSON, standalone VEX, or ML-BOM for those.

A CycloneDX document that carries only vulnerabilities[] — no components, no dependency graph — for tooling that consumes exploitability statements separately from the component inventory. Built entirely from the SCA inventory, so it always requires a completed SCA scan; there is no repository-snapshot path for this format. Downloads as {codeScanId}-vex.json.

A CycloneDX 1.6 machine-learning bill of materials scoped to one repository’s AI Inventory: LLM SDKs, agent frameworks, and similar detected packages as library components, model files as machine-learning-model components, and agent configs, prompt templates, and datasets as data components. Each component carries zeropath:ai:* properties for the fields ZeroPath actually knows about it — kind, usage, tier, provider, model format, detection source, manifest/file path, and reachability — so an absent property means that field is not known, not empty.Built entirely from the AI inventory, so it always requires a completed code scan; a repository that has only ever run standalone SCA scans returns a clear error until a full scan runs. An empty AI inventory produces a valid document with no components rather than an error. Downloads as {codeScanId}-mlbom.json.

Data Sources

Preferred: SCA Inventory
Fallback: Repository Snapshot

Uses the canonical inventory built by the ZeroPath SCA service, so it includes direct/transitive classification, license data, application ownership, and previously validated vulnerability context.
SBOMs generated from inventory are consistent: the package set, ordering, and dependency edges match the UI and alerting exactly. Document-level identifiers such as the CycloneDX serial number and timestamp are unique per generation.
VEX data is available because the inventory knows which packages are reachable, not reachable, or still in triage.

Artifact Contents

Every CycloneDX JSON and SPDX JSON export includes:

Repository metadata (name, commit SHA, scan timestamp).
One entry per manifest path (package-lock.json, requirements.txt, go.mod, pom.xml, Podfile, etc.).
Normalized ecosystems and Package URLs (PURL) for each dependency.
Direct vs transitive annotations plus a summary of the dependency path so teams know how a package entered the build. Maven transitive dependencies now include full parent-child dependency-path chains.
License information per package, sourced from manifest fields and external metadata. These fields are informational, not legal advice.
Dependency relationships (CycloneDX dependencies, SPDX relationships).
Optional VEX blocks (embedded, via CycloneDX JSON’s VEX option) showing current status, ZeroPath vulnerability IDs, CVSS/EPSS ratings, CWEs, and remediation hints. Standalone VEX carries the same vulnerability entries without the component graph.

CycloneDX JSON additionally carries AI Inventory enrichment when the scan has AI Inventory data: AI/ML-flagged packages carry zeropath:ai:* properties (kind, usage, tier, provider, model format, detection source, manifest/file path, and reachability — each present only when known), and file-derived AI signals with no package identity — model files, agent configs — appear as additional components. SPDX is not enriched this way; use ML-BOM for a dedicated, per-repository AI/ML inventory.

Vulnerability intelligence properties

KEV and EPSS — see Exploit intelligence: KEV and EPSS for what these signals mean — appear on each CycloneDX vulnerability entry (embedded or standalone VEX) as properties in the zeropath: namespace:

Property	Meaning
`zeropath:kev`	`"true"` or `"false"` — whether the CVE is in the CISA KEV catalog.
`zeropath:kev:dateAdded`	ISO date CISA added the CVE to KEV. Present only when `zeropath:kev` is `"true"`.
`zeropath:kev:knownRansomware`	`"true"` or `"false"` — tied to a known ransomware campaign. Present only when `zeropath:kev` is `"true"`.
`zeropath:epss:score`	EPSS exploit probability, `0`–`1`, as a string.
`zeropath:epss:percentile`	EPSS percentile rank, `0`–`1`, as a string.

A property is included only when ZeroPath actually knows the value: absence means not known, never a fabricated “not exploited” or a zero score. EPSS additionally appears as a CycloneDX rating alongside any CVSS rating, so tools that only read ratings[] still see it:

{
  "method": "other",
  "source": { "name": "EPSS", "url": "https://www.first.org/epss/" },
  "score": 0.42
}

Storage & Access

SBOMs are stored in ZeroPath-managed object storage with an automatic expiration policy (24 hours by default; can be extended for enterprise tenants).
Download links are pre-signed URLs that carry the same expiration. Pull the artifact into your own storage if you need longer retention.
Every job records organization, repository, requester, format, and expiration so you always know who generated which SBOM.

Adoption Guide

Run at Least One SCA Scan

This unlocks inventory-backed SBOMs and VEX exports. Scheduled scans keep the inventory current.

Submit SBOM Requests per Release

Kick off a job whenever you cut a release branch, tag, or artifact that needs provenance.

Choose the Right Format

Use CycloneDX JSON (with embedded or standalone VEX) for engineering/security workflows, SPDX for procurement/legal stakeholders, and ML-BOM when you need a per-repository AI/ML inventory on its own.

Integrate Delivery

Plug pre-signed URLs into CI/CD approvals, artifact registries, or audit tickets so reviewers can fetch the document automatically.

Mirror Long-Lived Artifacts

If policy requires multi-year retention, copy the SBOM into your own storage before the link expires.

Organization SBOM export

Reports → Generate → Organization SBOM exports one SBOM per repository you can view, zipped with a manifest.json.

Which repositories. Every repository of the organization you can view. The top bar’s tag and team filter does not narrow it. A personal API token covers the repositories its owner can view; service tokens cannot request an export.
Which inventory. For each repository, the newest dependency inventory on its default branch (the configured scan branch, else the provider’s default) from a scan that finished without an error, whose inventory has not been retired, and that no running full scan is about to replace.
Formats. CycloneDX 1.6 JSON or SPDX 2.3 JSON, built exactly as the per-repository export builds them. No VEX, ML-BOM or XML.
The archive. organization-sbom-{YYYY-MM-DD}-{cyclonedx|spdx}.zip, with sboms/{slug}--{id8}.cdx.json (or .spdx.json) per included repository and manifest.json. {slug} is the manifest’s repository, the name ZeroPath shows for the repository, in lower case with each run of characters other than a-z, 0-9, ., _ and - replaced by one -; {id8} is the first 8 characters of its repositoryId.
Storage. Kept until you delete the report, unlike per-repository artifacts, which expire after 24 hours.

manifest.json (schema version 1) records when it was generated, the organization, who requested the export, its scope, the format, and for every repository either an included entry (repositoryId, repository, defaultBranch, scannedBranch, scaScanId, commitSha — null when the scan recorded none, scanDate, file, sha256, components) or a skipped entry (repositoryId, repository, defaultBranch — null when the default branch is unknown, reason, detail) with one of these reasons:

Reason	Detail
`DEFAULT_BRANCH_UNKNOWN`	ZeroPath doesn’t know this repository’s default branch, so it has no default-branch inventory to export.
`NO_INVENTORY_ON_DEFAULT_BRANCH`	No finished dependency scan of the default branch ({branch}) has an inventory to export.
`INVENTORY_RETIRED_DURING_EXPORT`	A newer scan of {branch} replaced this inventory while the export ran. Generate the export again to include it.
`SCAN_DELETED_DURING_EXPORT`	The scan this inventory came from was removed while the export ran. Generate the export again to include it.

Troubleshooting Tips

"VEX requires SCA inventory"

Applies to both embedded VEX (the CycloneDX JSON option) and the standalone VEX format. Rerun the job with a completed SCA scan selected, or disable VEX for snapshot-based exports.

"The dependency inventory for this scan was retired"

The SCA inventory for the selected scan was superseded by a newer scan on the same branch and has been retired. Export the latest scan instead. This check happens at request time so no job is queued — selecting the latest scan and re-submitting is all that is needed. See Retained inventories.

"ML-BOM export requires a code scan"

Shown when a repository has only ever run standalone SCA scans and never a full/code scan. AI Inventory is anchored to a code scan, so run a full scan for the repository and retry the export.

"Repository snapshot failed"

Usually caused by missing SCM credentials or a deleted branch/tag. Re-run after fixing access or target a different commit.

Incomplete dependency list

Verify the latest SCA scan finished successfully and that manifests were included (shown on the repository’s Inventory tab). SBOMs mirror whatever the scan captured.

Jobs stuck in Pending or Processing

SBOM jobs update their status automatically when generation completes or fails, even if you close the browser or navigate away before the result appears. Jobs whose worker was interrupted (for example, by an infrastructure restart) and exhausted all retries are automatically detected and failed per polling cycle, so they no longer block later exports. If such a job fails, the error message will say “SBOM generation was interrupted and has used all of its retries. Re-run the export.” An export that can no longer finish shows Failed with the reason: “This SBOM export can no longer finish: its generation job no longer exists. Export the SBOM again.” or “This SBOM export can no longer finish: its stored settings can’t be read. Export the SBOM again.” If a job still shows as pending after ten minutes without one of these messages, contact support.

Generation failed with an error message

A failed SBOM job shows the same failure message in History and in the export dialog: a sentence describing what went wrong, not the raw error. Common causes include:

Artifact download failed — the generated SBOM could not be retrieved from storage. This is usually transient; retry the job.
Artifact missing — generation completed but no downloadable file was produced. Re-run with a scan that has inventory data.
Generation failed — an error occurred during SBOM assembly.
Timeout — the job did not finish within the allowed window. This can happen for very large repositories; contact support if it persists.

Comparing Results with Other SBOM Tools

When comparing ZeroPath SBOMs against tools like Syft, Trivy, or Grype, you may notice differences in package counts.

Why Package Counts Differ

Factor	ZeroPath	Other Tools (e.g., Syft)
Dev dependencies	Declared dev deps are recorded from the manifest; transitive expansion targets the production graph	Often include every installed dev transitive (e.g. from `node_modules`)
Data source	Lockfiles and manifests	May also scan `node_modules` directory, binaries, or container layers
Optional/peer dependencies	Declared ones recorded from the manifest; their subtrees included when resolution covers them	May include unresolved optional deps
Workspace/monorepo packages	Scoped to the target manifest	May include all workspace packages

Getting Started

Assets

Findings

Scanning

SCA

Platform

Developer Tools

Integrations

Authentication

Overview

Request Flow

Retained inventories

Formats & VEX Support

Data Sources

Artifact Contents

Vulnerability intelligence properties

Storage & Access

Adoption Guide

Organization SBOM export

Troubleshooting Tips

Comparing Results with Other SBOM Tools

Why Package Counts Differ

​Overview

​Request Flow

​Retained inventories

​Formats & VEX Support

​Data Sources

​Artifact Contents

​Vulnerability intelligence properties

​Storage & Access

​Adoption Guide

​Organization SBOM export

​Troubleshooting Tips

​Comparing Results with Other SBOM Tools

​Why Package Counts Differ

Overview

Request Flow

Retained inventories

Formats & VEX Support

Data Sources

Artifact Contents

Vulnerability intelligence properties

Storage & Access

Adoption Guide

Organization SBOM export

Troubleshooting Tips

Comparing Results with Other SBOM Tools

Why Package Counts Differ