devopscodepro
Language
Runs entirely in your browser — nothing leaves this page.

SBOM viewer

Inspect CycloneDX and SPDX JSON SBOMs: components, versions and a license summary with filtering.

or paste the JSON below
parsed locally — the SBOM never leaves your browser

Reading an SBOM

CycloneDX and SPDX JSON files are normalised into one component table: name, version, licence and package URL, with a licence summary and a filter across every column.

The file is parsed in your browser. That matters for an SBOM, which is a complete inventory of what runs in your product.

Reading one is how you answer questions a build log cannot: which transitive dependency pulled in a GPL library, whether the version you patched actually shipped, and what an auditor will find before they ask.

Does this tell me which components are vulnerable?

No — that is a scanner's job, and it needs a vulnerability database plus a matching engine. This tool answers what is in the artefact: which versions shipped, under which licences, and whether the inventory is what you expected.

CycloneDX or SPDX — which should I generate?

Both are read here, so pick by tooling. CycloneDX tends to fit security workflows and is what most scanners emit; SPDX has the stronger licence-compliance heritage. Consistency across your pipeline matters more than the choice.

Why are XML SBOMs not accepted?

JSON only, deliberately. Both formats define a JSON serialisation, every generator can emit it, and supporting one representation well beats supporting two badly.

Why do so many components show no licence?

That is a finding, not a display bug. Components without declared licence metadata are exactly the ones a compliance review has to resolve by hand, which is why they are grouped under unknown.

Related tools: Dockerfile analyzer, Kubernetes CVEs and K8s manifest validator.