SBOM Lens for VS Code
View SPDX and CycloneDX SBOMs, including cascading document hierarchies,
right in your editor. The full SBOM Lens viewer as a
custom editor: Explore tree, document map, inventory, version conflicts,
release diff, and quality reports.
Opening documents
- Open with SBOM Lens: right-click a
.spdx, .spdx.json,
.spdx.yaml, .cdx.json, or .bom.json file in the explorer (or use
Reopen editor with...).
Multi-select several files and they open together in one panel, with
cross-document references resolved between them.
- Open folder with SBOM Lens: right-click a folder, and every SPDX
document under it loads into one panel.
- SBOM Lens: Scan workspace for SBOMs: the command-palette way to load
the whole workspace (files over 50 MB are skipped).
- From URL: fetches run in the extension host, so browser CORS limits
don't apply. Access tokens are kept in VS Code's secret storage.
What you get
- Cascades as one tree.
ExternalDocumentRef links resolve across
everything you load, by checksum first and then namespace, and render as one
continuous tree: release, component, sub-SBOM, package. Unresolved
references become actionable placeholders.
- Analysis views. A sortable cross-cascade inventory (CSV/JSON export via
the native save dialog), a licence inventory (every SPDX identifier across
the cascade with its status on the SPDX License List, CSV/Markdown export),
version-conflict detection, release-to-release diffs, and a quality report
per document against the NTIA minimum elements (2021), the
CISA 2026 minimum elements that replace them,
BSI TR-03183-2 (field coverage, and the
licence fields of section 6.1), the
OpenChain Automotive SBOM v1.1
mandatory fields, the SBOM content of the
FDA 524B guidance (02/2026),
the G7 SBOM for AI minimum elements
(model and dataset meters scoped to those components), or, for a
CycloneDX CBOM, the cryptographic inventory the EU PQC roadmap asks for,
the DORA certificate register, PCI DSS 12.3.3 and the parameter tables of
BSI TR-02102-1 (2026-01).
Each report links its requirement source; none states conformance.
- Your own compliance rules. Drop a
.sbomlens/profile.json into the
workspace and every panel picks it up as a quality profile: thresholds,
field patterns, coverage gates. Reports export as Markdown.
- VEX and advisory overlay. Open an OpenVEX document or a CSAF advisory
(or a folder of them) next to your SBOMs and see what the supplier
communicates about known vulnerabilities: per-package statements with
status, justification and remediations, a VEX column and status filter in
the inventory, findings in the exports. Matched by package URL, CPE or
file hash, newest statement wins. Each CSAF document is measured against
the clauses of BSI TR-03191 a file can show, as facts with clause numbers.
A communication channel, not a scanner.
- Spec findings. Every document is checked against the specification it
claims to follow: relationship types outside the vocabulary, digests whose
length cannot match their algorithm, license expressions that do not parse,
identifiers off their grammar. They stay warnings and sit next to the
document, told apart from parser notes so you always know which you are
looking at. A reading aid, not a conformance verdict.
- Private by design. Documents are parsed locally inside the editor.
Nothing is uploaded anywhere.
- Field info tooltips carry the SPDX 2.3 spec docs and link into the exact
section of the specification; the theme follows your editor.
Working with Open Component Model deliveries (component descriptors,
CTF / component archives)? That is
OCM Lens, the
sibling extension built from the same codebase. SBOM Lens stays a focused
SPDX viewer.
Limits
- SPDX 2.x (tag-value / JSON / YAML) in full; SPDX 3.0.x as JSON-LD
with the core/software profiles mapped; CycloneDX 1.x as JSON or XML,
including BOM-Link cascades and CBOM cryptographic assets.
- The workspace scan skips files over 50 MB (open those by hand). A
single large SPDX document has no hard cap; parsing runs off the UI thread.
- Compliance profiles are capped at 64 KB / 200 checks; up to 16 persist.
- No license-compliance judgement, and no vulnerability data in the core
model (VEX and CSAF stay an overlay): license and quality fields are shown,
counted and checked against the SPDX License List (identifiers and
deprecation flags only), never interpreted. Spec findings
check expression GRAMMAR, not whether an identifier is on the list; for
authoritative conformance verification use
spdx/tools-java.
- Documents are parsed locally and never uploaded; only preferences and
imported profiles persist.
Install
Links
Apache-2.0 © EverBright IT GmbH — we help teams
with CRA/SBOM readiness and secure AI adoption.
| |
