lpm sbom

Export a Software Bill of Materials (SBOM) for a project or workspace member.

lpm sbom [OPTIONS]

Quickstart

lpm install
lpm sbom --output bom.cdx.json

An SBOM records resolved package versions and their relationships. Use it for dependency reviews, vulnerability scanners, and release records.

LPM CLI supports npm, private registries, and the LPM.dev Registry. The SBOM can include packages from each source.

Examples

# Export SPDX for a release
lpm sbom --format spdx --output reports/bom.spdx.json

# Send CycloneDX to another tool
lpm sbom > bom.cdx.json

# Include current registry metadata and provenance checks
lpm sbom --registry-metadata --output reports/bom.cdx.json

# Generate a report in CI
lpm sbom --json --output reports/bom.cdx.json

For a reusable report, define an uncached task:

{
  "tasks": {
    "deps:sbom": {
      "command": "lpm sbom --output reports/bom.cdx.json",
      "cache": false
    }
  }
}

lpm run deps:sbom

There is no dedicated SBOM configuration in lpm.json. The task's command holds the options. cache: false creates a fresh report each time.

For a different format or destination, run the command directly. An explicit lpm.json task command takes precedence in lpm run.

Project and workspace scope

The command finds the applicable lpm.lock and project manifest. Invocation from a nested source directory uses the same project.

In a workspace member, the report uses that member's lockfile projection. Sibling-only dependencies do not appear.

The report includes resolved versions, package URLs, dependency and peer relationships, source URLs, integrity hashes, and available metadata.

Separate dependency instances remain separate components, even with the same name and version. Their references preserve the relationships recorded in the lockfile.

The report describes the selected dependency inventory. It does not inspect a compiled bundle to determine which files shipped.

Installed manifests and dependency scope

Installed package manifests are required. LPM CLI follows the project's installation paths, including aliases and separate dependency instances.

Missing or invalid manifests stop the command. Packages omitted for platform compatibility, and dependencies reachable only through those packages, do not appear.

A package still needs a manifest if another compatible dependency requires it.

Development packages still appear in the document. excluded describes their runtime scope and does not remove them from the inventory.

SPDX preserves the package inventory and dependency relationships. It does not use the CycloneDX scope field.

If the manifest changed, update the installation before export:

lpm install
lpm sbom --output bom.cdx.json

Local and registry metadata

By default, SBOM generation makes no registry requests. It reads project files, installed manifests, lockfile evidence, and locally cached provenance bundles.

Local manifests supply descriptions, licenses, homepages, repositories, and authors. The lockfile supplies patch paths and recorded patch checksums.

To request current registry metadata, use:

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

For npm-compatible packages, this flag contacts the registry recorded in the lockfile. A changed default registry does not replace that source.

Packages under @lpm.dev/* use the configured LPM.dev Registry endpoint. Credentials and TLS configuration apply to the destination registry.

Registry values fill missing local fields. Registry licenses do not replace or expand an existing local license declaration.

Metadata lookup failures and absent locked versions stop the command. A refreshable LPM.dev Registry session can recover access to a hidden private version once.

Directory, link, Git, and direct tarball sources do not receive registry enrichment.

License declarations

The report records declared licenses. It does not establish legal permission or inspect license-file contents.

LPM CLI trims license text and removes empty or duplicate declarations. CycloneDX preserves declarations as named license entries.

SPDX uses valid license expressions. Multiple declarations join with AND, with parentheses that preserve compound expressions.

Custom text, UNLICENSED, and SEE LICENSE IN ... cannot serve as SPDX expressions. SPDX uses NOASSERTION and retains those declarations in licenseComments.

Use lpm licenses for license policy checks.

Patch and provenance records

CycloneDX includes patch records in pedigree.patches. Additional properties include:

SPDX carries these records in package attributionTexts.

Without registry enrichment, valid lockfile evidence takes precedence over cached provenance bundles. Cached bundles must pass verification and match the package's integrity.

With --registry-metadata, LPM CLI checks registry attestations. The report can contain absent, unknown, or rejected provenance results and still succeed.

SBOM generation is an inventory operation. Use lpm audit for security checks and CI failure policies.

Output files

Without --output, standard output contains one JSON document. Progress uses standard error.

With --output, the command writes the document to the selected file. It does not duplicate the document on standard output.

Relative paths start from the directory where you run the command. Missing parent directories are created. An existing regular file is overwritten.

Output paths cannot use symbolic links or special files. This includes linked parent directories.

Reports contain a generation timestamp, so repeated exports can differ even with the same dependencies.

Fix common problems

If a lockfile or installed manifest is missing, repair the installation:

lpm install
lpm sbom --output bom.cdx.json

If registry enrichment fails, check access to the locked registry. For npm-compatible registries, configure credentials in .npmrc.

For a local report without enrichment, omit the flag:

lpm sbom --output bom.cdx.json

If the destination is a link or special file, choose a regular file path.

Flags

See the global flags for JSON error output and other shared options.

See also

• lpm install — create the installation and lockfile
• lpm licenses — inspect licenses and enforce policies
• lpm audit — check vulnerabilities and package behavior
• lpm graph — inspect dependency relationships
• lpm patch — manage local package patches
• Lockfile — understand the resolved dependency graph