sbom-maker · git:20260811.73091b5 · 2026-08-11 · sha256 35cbf71ec5334991
sbom-maker git:20260811.73091b5A
Immutable. This exact content is served forever at /api/v1/blob/35cbf71ec5334991.
--- name: sbom-maker description: Derive a CycloneDX software bill of materials from a supplied lockfile deterministically, digest-bound to the exact bytes, with license risks surfaced and unsupported or unpinned lockfiles refused. --- # SBOM Maker 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-maker` 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.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`).