Chris Collins

Tools · containers

SBOM and vulnerability report viewer

Open a CycloneDX or SPDX SBOM, or a Trivy, Grype or OSV-Scanner report, and see the components by ecosystem with purls and licences (SPDX expressions parsed, copyleft flagged), the dependency graph, vulnerabilities by severity with fixed-in versions and "upgrade X to Y fixes N" suggestions — and what changed between two SBOMs.

Added

Works with

How to use it

An SBOM is a long JSON file nobody reads, and a scanner report is a longer one. This page reads both and answers the questions you open them for: what’s in here, under which licences, what is vulnerable, and what do I upgrade to fix the most of it. It opens on a real Trivy report of a small image built for these tools; Examples has the same image as CycloneDX and SPDX from syft, and as Grype and OSV-Scanner reports.

What it reads

CycloneDX

JSON, spec 1.4 to 1.7: components (nested too), licences (ids, names and expressions), dependencies, and vulnerabilities with ratings, affects and Trivy’s upgrade recommendations.

SPDX 2.3

JSON and tag-value: packages with purls from externalRefs, declared and concluded licences, and DEPENDS_ON / DEPENDENCY_OF relationships.

syft

its own JSON (-o json), artifacts and dependency-of relationships.

Trivy

trivy image -f json (with --list-all-pkgs to see clean packages too) and -f cyclonedx.

Grype

grype -o json: matches, fix versions and state, CVSS, related CVEs, EPSS and known-exploited flags.

OSV-Scanner

osv-scanner scan … --format json, including container image scans.

How to use it

  1. Paste the file, open it, or drop it on the box. Drop two at once (older first) to compare them.

  2. Components groups packages by ecosystem — Alpine, Debian, RPM, npm, Maven, PyPI, Go, Cargo and the rest — with version, purl, where it was found and its licence, and a count of advisories. Filter by any of them, or download the list as CSV. Maven, npm, Go and Cargo packages can be opened in the dependency tree analyser (as mvn dependency:tree, npm ls --json, go mod graph or cargo tree output, built from the SBOM’s dependency graph) for conflicts, duplicates and "why is this here".

  3. Licences parses each licence as an SPDX expression and puts it in a class: public domain, permissive, weak copyleft (LGPL, MPL, EPL, a GPL with a linking exception), strong copyleft (GPL), network copyleft (AGPL) or restricted (SSPL, BUSL, non-commercial). A OR B counts as the friendlier choice and A AND B as the stricter part. RPM-style names (GPLv2+ and BSD), Python classifiers and common spellings (Apache 2.0) are mapped to SPDX ids. Choose which classes to flag and add licence ids of your own; the flagged list updates. It’s a first pass for a review, not legal advice.

  4. Dependencies shows the graph as a collapsible tree from the top-level packages, with "who depends on…" for any package.

  5. Vulnerabilities lists advisories by severity with the CVSS score, aliases (GHSA ↔ CVE) and the fixed-in versions, and above them the upgrades that fix the most: for each package the lowest fixed version — on the installed release line where one exists — that covers every advisory with a fix, e.g. "upgrade log4j-core 2.14.1 → 2.25.4 fixes 8 of 8". Version order follows each ecosystem’s rules: dpkg’s for Debian, rpm’s for RPM, apk’s for Alpine and Maven’s or SemVer for the rest.

  6. Ask OSV.dev checks the packages against OSV.dev when the SBOM has no vulnerability data (or to compare with what the scanner said). It uses the same request as the dependency tree analyser; Alpine and Debian packages are asked about by source package and release, which is how OSV indexes them. Severities come from the advisory, or from its CVSS vector, scored here.

  7. Compare lines up two SBOMs or reports: packages added, removed, upgraded and downgraded, licence changes, and — when both carry vulnerability data — the advisories fixed and the new ones. The Compare two image versions example is Trivy on two builds of the same image.

To make an SBOM from an image tar without installing anything, open it in the image layers tool and press Open in SBOM viewer.

What I checked it against

The examples are real output of syft 1.55.0, Trivy 0.76.1, Grype 0.121.0 and OSV-Scanner 2.7.0 (their official Docker images, run on 2026-10-29) against two builds of a small test image; long descriptions and reference lists were shortened, nothing else changed. The counts here equal the tools' own: 120 Trivy findings, 77 Grype matches, 120 OSV-Scanner advisories, 21 syft packages, and the three scanners agree on the upgrade targets for the packages they all found. The licence classes, the dpkg/rpm/apk version comparisons and the CVSS 3.1 scores (against NVD’s) are covered by tests.

Privacy

Everything you open is parsed in this page and never uploaded. The last files are kept in your browser’s local storage so they’re still here when you come back; Clear removes them.

The one exception is Ask OSV.dev, and only when you press it: it sends package names, versions and ecosystems to api.osv.dev, Google’s Open Source Vulnerabilities service, then fetches the advisories it returns. Not the file, not its name, not the image. The panel shows the exact request before you send it.

Runs entirely in your browser — network requests go only to the services named on this page.