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), 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, or
BSI TR-03183-2. Each report links its requirement source.
- 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 overlay. Open an OpenVEX document next to your SBOMs and see what
the supplier communicates about known vulnerabilities: per-package
statements with status and justification, a VEX column and status filter
in the inventory, findings in the exports. Matched by package URL, newest
statement wins. 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,
including BOM-Link cascades.
- 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 overlays: license and
quality fields are shown, not interpreted. Spec findings check expression
GRAMMAR, never whether a license identifier is real; 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.
| |
