Extension SBOM: A Software Bill of Materials for Browser and IDE Extensions

What an extension SBOM is

An SBOM — software bill of materials — is the machine-readable inventory of every component inside a piece of software. For an extension, that means the bundled runtime (the compiled main.js or background.js), every first- and second-level dependency from its package.json, the libraries a Chrome extension pulled in through its build, and — for MCP servers and n8n nodes — the full npm dependency tree the component installs at runtime.

The reason this matters more for extensions than for ordinary packages: extensions ship their dependencies frozen inside an artifact. A VS Code extension's VSIX is a zip of already-built bundles; a Chrome extension inlines its libraries into the package the store distributes. When a vulnerability lands in a bundled library, the fix does not flow to installed extensions until the publisher rebuilds and ships a new version — and users do not choose to upgrade the way server operators do.

Why extensions are a real supply-chain surface

The modern extension sits at the intersection of several package ecosystems, and each has been the origin of real incidents:

• The Shai-Hulud worm self-replicated through npm, stealing cloud and AI credentials, and later waves explicitly targeted Claude Code and MCP configuration files.
• GlassWorm spread between OpenVSX and the VS Code Marketplace and harvested npm, GitHub, and OpenVSX tokens plus crypto wallets.
• The Count Dooku campaign re-published legitimate VS Code extensions with an appended payload — a dependency-integrity failure at the registry level.

An SBOM is what lets you ask "was anything I have installed built from one of those compromised packages?" without waiting for a vendor advisory.

What a useful extension SBOM contains

• Direct dependencies with pinned versions, resolved from package.json / the extension manifest.
• Bundled code identification: which known libraries (and versions) were detected inside the compiled artifact, even without clean metadata.
• Vulnerable-component matches: dependencies with known CVEs at the bundled version.
• Runtime installers: components that fetch or npm install further code when they run — the highest-risk category, because the artifact you scanned is not everything that ends up executing.

How to use an SBOM to triage

1. Start with critical CVEs at the bundled version, not the latest version — the fix only exists if the publisher ships it.
2. Weight by reachability. A vulnerable markdown renderer bundled into a UI panel is a lower tier than a vulnerable network client that runs in the extension's background worker.
3. Watch the diff across versions. A dependency that appears, disappears, or jumps a major version between releases is a supply-chain event worth a look, even with no CVE attached.
4. Check who built it. A clean SBOM from a publisher whose identity is unverifiable is worth little — see publisher takeover.

Risky Plugins builds this inventory for every extension it analyzes; each scorecard carries the dependency findings and the version-by-version history. Our longer SBOM guide covers the methodology in depth.