lpm sbom

lpm sbom
lpm sbom --format spdx
lpm sbom --output bom.cdx.json
lpm sbom --registry-metadata

lpm sbom exports a Software Bill of Materials for the current project. An SBOM is a machine-readable inventory of the packages in a build: names, versions, package URLs, dependency edges, sources, integrity hashes, licenses when local metadata is available, patch metadata, and provenance metadata when cached or fetched.

Security teams, enterprise customers, release pipelines, and vulnerability scanners use SBOMs to answer "what shipped?" after a build. Generate one in CI and attach it to releases or container images.

Formats

Default output is CycloneDX 1.7 JSON:

lpm sbom > bom.cdx.json

SPDX 2.3 JSON is available with --format spdx:

lpm sbom --format spdx > bom.spdx.json

Both formats are generated from lpm.lock, so run lpm install first.

Enrichment

By default, SBOM generation is local-first and does not depend on the network. It reads:

• lpm.lock for the resolved package graph
• package.json for root metadata and direct dependency scopes
• installed package manifests from node_modules/ and the LPM CLI store when present
• lpm.lock > [patches] for patch paths, original integrity bindings, and patch-file SHA-256 records
• verified provenance evidence from lpm.lock
• cached Sigstore bundles under ~/.lpm/cache/metadata/attestations, only when the package has integrity that can bind the bundle to its exact tarball

Use --registry-metadata when you want live registry metadata and provenance attestation checks during SBOM generation:

lpm sbom --registry-metadata --output bom.cdx.json

The flag respects the same registry routing and .npmrc behavior as metadata-reading commands. Plain lpm sbom stays deterministic and offline-friendly.

Lockfile evidence is preferred because it is already bound to the package's exact name, version, source, npm package URL, and SHA-512 integrity. A cache entry is never treated as a writable “verified” snapshot: the cache stores the original bundle bytes, and every use reruns certificate, transparency-log, identity, subject, and tarball-digest verification. A cache entry cannot contribute provenance when the package has no integrity to bind it.

Output file

lpm sbom --output bom.cdx.json
lpm sbom --format spdx --output bom.spdx.json

When --output is set, LPM CLI writes the SBOM to that path and does not duplicate the JSON to stdout.

Progress is still printed to stderr, so stdout stays reserved for the SBOM document when you do not pass --output:

› Generating CycloneDX SBOM from lpm.lock
    packages  207
    format    cyclonedx
    output    /path/to/bom.cdx.json

✓ Included patch and provenance metadata
✓ Done · wrote SBOM in 236ms

Patch and provenance fields

CycloneDX output uses the native component.pedigree.patches field for patched dependencies. LPM CLI also carries checksum and integrity details as component properties, for example:

{
  "pedigree": {
    "patches": [
      {
        "type": "unofficial",
        "diff": {
          "url": "patches/lodash@4.17.21.patch"
        }
      }
    ]
  },
  "properties": [
    {
      "name": "lpm:patch:sha256",
      "value": "sha256-..."
    }
  ]
}

SPDX output carries the same LPM CLI details in package attributionTexts. This keeps the documents valid while preserving the information needed to audit patched dependencies.

Flags

Plus the global flags.

See also

• lpm install — produces the lockfile SBOMs read
• lpm patch — patch metadata included in SBOM output
• lpm licenses — human/JSON license inventory and CI policy gates
• lpm audit — vulnerability and behavioral analysis
• Lockfile — resolved graph source of truth