SBOM Lens: An Open Viewer for Real-World SPDX Cascades

An SBOM viewer sounds like a solved problem. It stops being one the moment your SPDX documents look like the ones coming out of actual delivery pipelines: a release document referencing component SBOMs, which in turn reference container image SBOMs, quickly stacking up to four levels and thousands of packages. That is exactly where we kept capitulating in customer projects, falling back to jq and a text editor. So we built SBOM Lens, a free viewer for SPDX SBOMs, released as open source under Apache-2.0. This article opens our series on making the software supply chain visible, and explains why the tool exists and which decisions shaped it.

The problem: SBOMs get generated, not read

Over the past few years the industry has learned to produce SBOMs. CI pipelines generate them with Syft or Trivy, compliance departments demand them, and regulation such as the EU Cyber Resilience Act turns them into a legal requirement. What is missing is the other half: tools that let humans actually look at the documents, understand them and answer questions. Which OpenSSL version ships in this release? Do two components deliver the same library in different versions? What changed since the last release?

Generating SBOMs with tools like Syft or Trivy is well covered. The reading side is thin: most viewers handle exactly one document. SPDX can do more, linking documents via ExternalDocumentRef. Release SBOMs from real pipelines use this extensively, at which point a single-document viewer shows you the top level and a pile of dead references.

What SBOM Lens does differently

SBOM Lens treats cascading documents as the normal case, not an edge case. You drop the release document plus its component SBOMs into the browser; the tool resolves the references, by checksum first, then by namespace, and renders one continuous tree across all document boundaries: release, component, container image, package. Missing documents show up as actionable placeholders instead of error messages.

Five views answer the questions that actually come up in projects. Explore shows the tree with a detail pane and raw source. Map visualizes how the cascade is wired. Inventory produces the parts list as a sortable table with CSV and JSON export. Conflicts groups packages that ship in more than one version. Diff compares two releases and outputs the changes as copyable Markdown for release notes.

On top of that, every document gets a quality report oriented on the NTIA minimum elements: author, timestamp, namespace and relationship checks, plus per-package coverage of versions, suppliers and checksums. Deliberately presented as plain numbers, without an invented score. An SBOM with 60 percent supplier coverage is not a “grade C”; it is a document missing 40 percent of its supplier fields.

Three decisions that shaped the tool

The first decision: client-only. SBOM Lens is a static web app that parses documents exclusively in the browser. Nothing gets uploaded. A dependency list reveals a lot about a product, from version freshness to potentially vulnerable components, and has no business sitting on someone else’s server. If you still prefer not to trust the hosted viewer, the repository ships a Dockerfile; the instance runs behind your own reverse proxy and can serve a curated SBOM catalog to your team.

The second: honesty about dirty data. Real SBOMs have quirks. Checksum spacing variants, duplicate SPDXIDs, versions hiding only in the purl, unknown relationship types. A parser that answers all of this with an exception is useless in practice. SBOM Lens loads tolerantly and reports what it found as per-document diagnostics.

The third: performance as a feature. Documents with 6,500+ packages parse in a Web Worker, tree and source views are virtualized, and search runs against a prebuilt index. Anyone who has ever opened a 40-megabyte JSON file in a browser tab knows why we mention this.

For daily work there is also a VS Code extension on Open VSX: “Open with SBOM Lens” on any .spdx file, plus workspace scanning that finds every SBOM in your repository.

Open source, built with AI

SBOM Lens is published under Apache-2.0 on GitLab, with a GitHub mirror. For us that is not a marketing by-product but consistency: we have recommended open source building blocks to clients for years, so we release our own tooling in the open as well. The tool was, by the way, largely written by AI coding agents, with human architecture and review work at the points that matter. Both stories, the release process and the AI-native development workflow, get their own articles in this series, as do a deeper look at SPDX cascades and the Open Component Model.

Conclusion

SBOMs only create value once somebody reads them, and that requires tooling that copes with real, cascading documents. SBOM Lens is our answer: open, local, fast. Try it with the bundled example cascade directly in the viewer. And if your delivery pipeline produces SBOMs nobody can work with, talk to us: our team supports you from pipeline integration to analysis, see software engineering at EverBright.

Frequently Asked Questions

What is SBOM Lens?

SBOM Lens is a free, open source viewer for SPDX SBOMs, developed by EverBright IT. It resolves references between cascading documents and renders the entire supply chain as one navigable tree. The tool runs fully in the browser, files never leave your machine, and it is licensed under Apache-2.0.

Which SBOM formats does SBOM Lens support?

SBOM Lens reads SPDX 2.x in tag-value, JSON and YAML formats, including cross-document references via ExternalDocumentRef. CycloneDX is currently not supported; the focus is deliberately on deep SPDX handling rather than format breadth. For CycloneDX workflows, documents can be converted to SPDX beforehand.

Are my SBOM files uploaded when I open them?

No. SBOM Lens is a static, client-only application: documents are parsed locally in your browser and never transmitted to a server. URL fetching only happens when you explicitly trigger it. For private registries you can self-host the tool and run it behind your own reverse proxy.

Can I self-host SBOM Lens in my company?

Yes. The repository contains a Dockerfile producing a roughly 25 MB nginx image; alternatively any static web server works. A self-hosted instance can ship a curated catalog of SBOMs, so your team opens the viewer and starts analyzing without hunting down files manually.