Output Formats & SBOM

SCANOSS-CLI writes results in three formats, chosen with -f, --format on scan or enrich.

Available Output Formats

Format	Description	Use Case
raw (default)	The neutral SCANOSS inventory: components tagged by `scope`, per-component layers inline, and a flat vulnerabilities list, wrapped in a versioned envelope.	SCANOSS ecosystem, full detail
SPDX	SPDX 2.3	Licence compliance, SPDX-based tooling
CycloneDX	CycloneDX 1.7, with licences, evidence, and vulnerabilities	SBOM exchange, vulnerability tracking

scanoss-cli scan ./my-project --api-key "$SCANOSS_API_KEY" --format raw       --output results.json
scanoss-cli scan ./my-project --api-key "$SCANOSS_API_KEY" --format spdx      --output sbom-spdx.json
scanoss-cli scan ./my-project --api-key "$SCANOSS_API_KEY" --format cyclonedx --output sbom-cdx.json

What Each Format Can Represent

By default a scan reports only the components it detected. The --include flag (on scan and enrich) opts into extra decoration layers gathered on top of that: Dependencies, Vulnerabilities, Licenses, Cryptography, and Geoprovenance, for example --include deps,vulns,licenses. Not every output format can carry every layer, though. A layer the chosen format can’t represent is skipped up front, with a notice, rather than silently dropped after the fact:

Format	Layers Rendered
`raw`	Every layer: Dependencies, Vulnerabilities, Licenses, Cryptography, Geoprovenance.
`cyclonedx`	Everything except Cryptography and Geoprovenance.
`spdx`	Only Dependencies and Licenses — no Vulnerabilities, Cryptography, or Geoprovenance.

Component Collapsing

Components that share the same identity (PURL + version) are collapsed into one, so the same package listed in both package.json and package-lock.json, or both detected in source and declared in a manifest, is emitted once. Different versions of the same PURL are kept as separate entries. In SPDX output, multiple licenses found on one component are combined with AND.

Converting Between Formats

The sbom command converts offline, no API call, no source tree required. It reads a file, detects what it is from its content, and writes it in the target format:

# SPDX -> CycloneDX
scanoss-cli sbom bom.spdx.json --format cyclonedx --output bom.cdx.json

# CycloneDX -> SPDX
scanoss-cli sbom bom.cdx.json --format spdx --output bom.spdx.json

# A raw scan result -> CycloneDX or SPDX
scanoss-cli sbom results.json --format cyclonedx --output bom.cdx.json

Recognised inputs: a SCANOSS raw inventory (the scan raw output), CycloneDX, or SPDX (JSON), auto-detected from content. Targets: cyclonedx or spdx.

Conversion is best-effort: data the target format can’t represent is dropped, with a warning. SPDX 2.3 has no vulnerability model, for example, so converting to spdx omits any vulnerabilities the source document carried.

Refreshing an Existing SBOM

To add or update layers on an SBOM you already have, without a full re-scan, use enrich rather than sbom (which only converts container format, it doesn’t call the API). See Enrich & Dependencies.

Documentation

Links

Available Output Formats

What Each Format Can Represent

Component Collapsing

Converting Between Formats

Refreshing an Existing SBOM

​Available Output Formats

​What Each Format Can Represent

​Component Collapsing

​Converting Between Formats

​Refreshing an Existing SBOM

Available Output Formats

What Each Format Can Represent

Component Collapsing

Converting Between Formats

Refreshing an Existing SBOM