Link SBOM Records to Build‑Intent Proposals for Immutable Provenance

The liability of an invisible supply chain

A vendored library lands in your repository. The code compiles. The feature ships. Weeks later a licence audit flags a component you never saw. The audit reveals a missing attribution. The legal team asks: where did that line come from? You cannot answer. The SBOM you generated lists a package name and version, but no commit hash, no licence file snapshot. The gap becomes a liability. The failure mode is “unlinked SBOM entries”. The provenance of each line is unknown. The risk is a breach of compliance and a potential injunction.

Capture the truth at the Build‑Intent gate

The Build‑Intent gate is the moment an agent proposes a write. At that instant the system knows the exact commit range that will be added. It also knows the licence metadata extracted from each source file. The correct posture is to feed that data straight into the SBOM record. The SBOM entry now contains three immutable fields: the package identifier, the commit SHA that introduced the code, and a licence fingerprint (hash of the licence file). Because the SBOM is generated from the same gate that registers the write, the record cannot be altered later without a new Build‑Intent. The paper trail is therefore immutable.

A concrete walk‑through helps. A developer runs shpbl write --path src/vendor/foo. The agent resolves the proposal, checks invariants and licences, and returns a Build‑Intent token. The token includes a manifest:

{
  "commit":"a1b2c3d4e5f6",
  "licenseHash":"d41d8cd98f00b204e9800998ecf8427e",
  "sbomEntry":{
    "purl":"pkg:npm/foo@1.2.3",
    "commit":"a1b2c3d4e5f6",
    "licenseHash":"d41d8cd98f00b204e9800998ecf8427e"
  }
}

The SBOM file written to the repository now carries the exact commit and licence hash. Any downstream consumer that reads the SBOM can verify the commit exists in the source history and that the licence file matches the recorded hash. The verification step is repeatable because the SBOM is a computed artifact, not a generated one.

Why downstream distribution stays trustworthy

When a downstream team pulls the repository, they receive the SBOM alongside the source. Their build pipeline can run the same certification harness that SHPBL provides. The harness reads each SBOM entry, checks out the referenced commit, recomputes the licence hash, and compares it to the stored value. If the values match, the harness records a CERTIFIED verdict for that artifact. If the commit is missing, the harness returns INCONCLUSIVE, signalling a supply‑chain break that must be repaired before release.

Because the SBOM is tied to the Build‑Intent, any later change to the vendored code must pass through a new Build‑Intent gate. That new gate will generate a fresh SBOM entry with a new commit hash and licence hash. The old entry remains in the archive, preserving the historic provenance. The result is a supply chain that can be audited at any point without guessing which commit introduced a licence.

How SHPBL makes this happen

SHPBL’s library implements the Build‑Intent gate and the SBOM enrichment in a single, model‑independent step. The gate validates invariants, resolves licences, and writes an SBOM entry that contains the exact commit SHA and a licence‑file checksum. The same SBOM is exposed through the plain HTTP API, the typed TypeScript client, and the offline file edition, so every consumer sees identical data. The certification harness can then execute the artifact and emit a CERTIFIED or PROVISIONAL verdict. For a deeper look, see the post on capturing license metadata at the build‑intent gate and the API access documentation.

Take action on Monday

Run a free repository evaluation against a vendored component you already use. The evaluation will generate an SBOM that includes commit hashes and licence hashes for every vendored file. Compare the output with your current licence audit. If gaps appear, add a Build‑Intent step to your CI pipeline and regenerate the SBOM. The next audit will have an immutable paper trail to show where every line originated.

---

Related reading: Linking SBOM Entries to Exact Source Commits explains the same technique in a different context. The pillar post on the cost of missing provenance, Vendoring code without a paper trail is unsecured debt, outlines the broader risk.

---

Start with the evaluation today, and have a provable SBOM ready for your next release.