Exports and SBOM

Sooner or later someone outside engineering asks for the list. A customer wants a software bill of materials before signing, an auditor wants evidence that dependencies are monitored, or an incident review wants to know exactly what was in a release. The Export Data page produces those artefacts from the same inventory the console shows.

Export Data, with the filters and columns that shape the output.

Export Types

Type	Shape	Use it for
Packages	One row per package version, with advisory counts	Inventory reporting, dependency reviews, feeding a GRC system
CVEs	One row per advisory, with the packages it affects	Vulnerability reporting and remediation tracking
SBOM	A CycloneDX software bill of materials	Customer and regulatory SBOM requests, release records

Packages and CVEs are two views of the same facts. Choose by the question being asked: a dependency review wants a package-centric list, while a vulnerability report wants an advisory-centric one.

Packages and CVEs Exports

Narrow the export with the same search, project, and ecosystem filters used elsewhere in the console, then choose the columns to include. Exports are produced as CSV or JSON.

CSV is the right answer when a person will open the file, and it is what most spreadsheet-based compliance processes expect. JSON is the right answer when a system will read it.

Pick the columns deliberately. An export with every column is harder to review than one carrying only what the recipient asked for, and a compliance reviewer working through fifty columns is a reviewer likely to miss the two that mattered.

The Packages page also has its own Export control that takes the current view and filters straight out, which is quicker when you already have the table filtered the way you want it.

SBOM Export

SBOMs are generated in CycloneDX format.

Choose a single project for one SBOM file, or All Projects to generate a ZIP archive containing one SBOM per project. Per-project files are usually what you want, since an SBOM is a statement about a specific deliverable rather than about your whole estate.

Include Vulnerabilities adds known advisory information to the SBOM. Whether to include it depends on the recipient:

• Include it for internal release records and incident reviews, where the vulnerability position at a point in time is exactly the useful part.
• Consider excluding it for an SBOM being sent outside the organisation, where an inventory is being requested rather than a security assessment, and where a snapshot of open findings can be stale and misleading by the time it is read.

An SBOM is a point-in-time statement. Generate it as part of the release process rather than reconstructing one months later, and keep it alongside whatever else you retain about that release.

Practical Notes

• Exports respect the workspace you are in. An export from a development workspace describes development, not production.
• Coverage of an export is coverage of the inventory behind it. Dependencies installed through a path that bypasses the proxy do not appear unless the package scanner reports them. See Package Scanner for closing that gap in environments that cannot route through the proxy.
• Exported files carry the same data your workspace holds, including package names and versions that may be internally sensitive. Handle them accordingly before sending them outside the organisation.