VisCommandsvis sbom

vis sbom

Generate a CycloneDX 1.7 Software Bill of Materials for the workspace

vis sbom

Generates a CycloneDX 1.7 Software Bill of Materials (SBOM) for the current workspace, capturing every workspace project, every reachable registry dependency, per-version licenses, and the dependency graph.

The generator walks the workspace project graph plus the lockfile closure, so the emitted BOM includes both direct and transitive dependencies — the same closure that is actually installed in node_modules.

Usage

vis sbom [options]

Examples

# Full-workspace SBOM → sbom.cdx.json
vis sbom

# Scope to a single project's closure
vis sbom --focus=my-app

# Focus multiple projects
vis sbom --focus=my-app,other-app

# XML output
vis sbom --format=xml --output=sbom.cdx.xml

# Include devDependencies
vis sbom --include-dev

# Write to stdout (for piping / CI)
vis sbom --output=-

Options

OptionDefaultDescription
--focusProject name(s) to focus on — comma-separated. Scopes the BOM to the transitive closure.
--formatjsonOutput format: json (CycloneDX 1.7 JSON) or xml.
--outputsbom.cdx.jsonOutput file path (resolved against the workspace root). Use - to write to stdout.
--include-devfalseInclude devDependencies in the closure walk. Default is production-only, per industry practice.

What's in the BOM

Every emitted BOM passes the vendored CycloneDX 1.7 JSON Schema (bom-1.7.schema.json). Each components[] entry carries:

  • name + version + purl (pkg:npm/… Package URL)
  • bom-ref (unique per component)
  • type: "library" (or "application" for the workspace root / focus target)
  • scope: "required" | "optional"optional propagates only through optionalDependencies edges; required wins on any shared path
  • hashes: [{ alg, content }] — decoded from SRI when the lockfile provides one
  • licenses — resolved against the specific installed node_modules/.pnpm/<name>@<version>/ copy so different versions can carry different licenses
  • description, author, externalReferences (homepage, vcs, issue-tracker) from the installed copy

dependencies[] edges cover both workspace project → project edges and registry → registry edges (from the lockfile graph walk).

Package manager support

Package managerLockfileSBOM coverage
pnpmpnpm-lock.yaml✅ Full
npmpackage-lock.json (v2 / v3)✅ Full
Yarn Classicyarn.lock (v1)✅ Full
Yarn Berryyarn.lock (v2+)✅ Full except integrity hashes — Berry uses XXH64 (checksum:), which is not a cryptographic hash and is outside CycloneDX 1.7's HashAlgorithm enum. Berry components emit without a hashes entry; all other fields are populated normally.
Bunbun.lock (1.1+)✅ Full

Binary bun.lockb is not supported.

Focus mode

--focus=<project> scopes the BOM to one or more workspace projects plus their transitive closure. The focused project becomes metadata.component; other workspace projects outside the closure are excluded.

Useful for Docker images, deploy artifacts, or per-app compliance reports:

vis sbom --focus=web-app --output=dist/web-app/sbom.cdx.json

Limitations

  • License lookup is best-effort. The generator resolves each name@version's license against its installed package.json — trying pnpm's virtual store (node_modules/.pnpm/<name>@<version>/node_modules/<name>/package.json, including peer-disambiguated suffixes) first, then the hoisted node_modules/<name>/package.json (version-matched). npm's nested node_modules/parent/node_modules/<pkg>/ layouts and Yarn PnP are not searched; components whose installed copy isn't found emit without license decoration rather than failing.
  • Yarn Berry integrity is dropped (XXH64 is not a supported algorithm). See the matrix above.

Why

Regulatory mandates for SBOMs include:

  • US Executive Order 14028 (2021) — federal supply-chain security
  • EU Cyber Resilience Act — effective December 2027
  • PCI DSS 4.0 — payment-card industry compliance

vis sbom is designed to be the first monorepo-native CycloneDX generator — moon, Nx, and Turborepo do not emit SBOMs out of the box. cdxgen exists but is heavy (200+ dependencies) and not monorepo-aware.

Configuration

No vis.config.ts configuration is required. The command reads directly from the workspace lockfile + package.json files.

Support

Contribute to our work and keep us going

Community is the heart of open source. The success of our packages wouldn't be possible without the incredible contributions of users, testers, and developers who collaborate with us every day.Want to get involved? Here are some tips on how you can make a meaningful impact on our open source projects.

Ready to help us out?

Be sure to check out the package's contribution guidelines first. They'll walk you through the process on how to properly submit an issue or pull request to our repositories.

Submit a pull request

Found something to improve? Fork the repo, make your changes, and open a PR. We review every contribution and provide feedback to help you get merged.

Good first issues

Simple issues suited for people new to open source development, and often a good place to start working on a package.
View good first issues