sbom-generate

Files (8)

• SKILL.md
• composes-in-graph.yaml · fixtures/
• composed.graph · fixtures/support/
• mark.svg
• catalog.md · references/
• mark-license.md · references/
• run.yaml
• sbom-generate.mjs

SKILL.md (first lines)

# SBOM Generate

Turn one lockfile into a verifiable component inventory. The caller supplies
the parsed lockfile; nothing is fetched, so the same input always seals the
same SBOM. This is the inventory layer of the security pipeline: `sbom-generate`
derives what is present, `cve-audit` detects what is vulnerable.

## Procedure

1. Native `data.digest` binds the exact lockfile object; the SBOM serial number
   and metadata carry that digest, so the inventory cannot drift from its
   source.
2. Deterministic extraction reads the modern `packages` map (or the classic
   nested `dependencies` map) and keeps only pinned components with versions,
   each with its evidence location inside the lockfile.
3. Licenses are normalized, counted, and risk-flagged: strong copyleft is
   `high`, weak copyleft is `medium`, missing license evidence is `review`.
   Risks are surfaced, never suppressed.
4. A lockfile that is not an object, carries no dependency map, or pins no
   components refuses with findings instead of emitting an empty inventory.

To inventory a remote lockfile, compose `web-fetch` for the governed read and
pass its content here; the digest binds whatever bytes were supplied.

## Output

`sbom_result` (`runx/sbom-generate.sbom.v1`) carries `decision` (`generated`, `refused`),
the CycloneDX 1.5 `sbom` or null, `component_count`, `license_summary`,
`license_risks`, `validation`, and the lockfile digest.

Inputs are `lockfile` and optional `lockfile_type` (`package-lock`,
`npm-shrinkwrap`).

From runxhq/runx, Apache-2.0.

More from runxhq/runx