What every audit-linked PR carries in its SBOM — and why a regulated buyer cares.

from · emit · to · ledger

From emit to ledger: what every PR carries in its SBOM.

A Driftlock run closes a single CycloneDX 1.5 document as part of the same hermetic sandbox run that produced the diff. The SBOM is regenerated from the resolved lockfile inside the sandbox — never lifted from a vendor or a third-party scanner — and the document carries, per package, the PURL, the SPDX license expression, the supplier, and the package content hashes. Two artefacts come out together: the SBOM itself, addressed by SHA-256, and a cosign signature over that SHA-256. The SBOM hash is the seventh column in the same audit-trail row the launch post enumerates — it sits next to the trigger source, the triage record, the diff, the sandbox test results, the approver chain, and the commit signature. The CycloneDX JSON the document emits is the canonical form an Anchore Enterprise, FOSSA, or in-house SBOM pipeline reads without translation; the same document lands as an SPDX handled-link for tooling that prefers SPDX over CycloneDX.

the · seven · field · row · binds · it

The seven-field row binds SBOM, signature, sandbox, and approver chain.

Every Driftlock run writes a row in the customer supply-chain ledger. The row has seven columns and each column has a single owner: the watcher writes the trigger source and triage record, the sandbox writes the diff and the test results, the signing controller writes the commit signature, and the SBOM signer writes the SBOM hash. None of the columns can be reauthored independently — each row is bound by the run id, and a column that disagrees with its sibling pair is flagged at ingest. The SBOM hash is not adjacent to the signature — it is one of the artefacts the signature covers. When a regulator replays the row, they pull the run id, fetch the SBOM, recompute the SHA-256 against the lockfile that produced the diff, and check the cosign signature against the customer KMS-resident verification key. If any of the four checks fail, the row fails the re-enactment — a tampered SBOM cannot survive replay without breaking the signature that binds it to the diff.

landing · in · the · ledger

Where the SBOM lands, and what a key rotation does not break.

Where the SBOM lands in the customer environment matters as much as what is in it. The signed SBOM is pushed alongside the commit to the customer artifact registry, and the same write attaches a CycloneDX audit-trail column — run id, sandbox hermetic-build hash, approver GitHub identity, and the SBOM signature Rekor transparency-log entry — to the row in the ledger. The Rekor entry is what makes the artefact independent of any single signing ceremony: the older SBOM stays verifiable after a key rotation because the claim is bound to the Rekor log, not to the public key of the moment. The customer KMS-resident key rotates on the customer schedule (or against the customer HSM on the Enterprise tier); a buyer months into a rotation cycle can still verify every SBOM emitted under the previous key, by reading the Rekor entry and walking back through the cosign claim payload.

what · regulators · actually · ask

What SOC 2 / FedRAMP-style regulators actually ask of the SBOM.

The asks a regulated buyer puts on the table are concrete, and each one is satisfied by the per-PR SBOM as it lands. They do not accept a weekly batch or a quarterly point-in-time export; they ask for SBOMs on every PR a downstream tool can ingest, and they ask that the SBOM and the diff live in the same row. Six asks cover the bar every time — the list mirrors the asks the platform-security lead typically writes into the SOC 2 Type II scope of work:

• Continuous SBOM ingestionSBOMs arrive per PR, in CycloneDX, on a fixed cadence the downstream tool can poll. The downstream tool never sees a daily batch it has to reconcile against the diff after the fact.
• Evidence of SBOM integrityThe cosign signature over the SBOM SHA-256 is verifiable against a customer KMS-resident verification key; the older entry is still verifiable after a key rotation, because the claim is logged to Rekor.
• Change-tracked diff per PRThe SBOM diff sits next to the lockfile diff in the same PR. A reviewer sees what the dependency patch actually meant for the surface area, package by package, on the same review screen.
• Lockfile-to-SBOM coherenceA package present in the SBOM that is not in the lockfile is rejected at ingest. Off-tree packages — the long-tail supply-chain risk every audit enumerates — do not silently reach production.
• Supplier and conformance attestationsPer-package supplier fields and SPDX license expressions are present in the document; a downstream tool can group by supplier and route anomalies to the correct reviewer.
• Anomaly routing on licence driftA licence change — permissive to source-available, or a GPL appearing in a tree that was MIT-only yesterday — lands as an anomaly tagged on the row, not as an event buried in a feed.

compare · vendor · attestation · patterns

Where vendor-courtesy SBOMs break, and what closes the gap.

The failure mode of vendor-courtesy SBOMs is consistent. A vendor SBOM is generated outside the run that produced the diff, signed with a key only the vendor holds, and pushed to a portal the buyer reads but does not verify against. The key stays outside customer control. The signature is unsigned, or signed with a vendor-KMS key whose public key the buyer does not pin in their own trust store. Worst of all, the SBOM drifts from the lockfile — the document the vendor published last week is no longer the document the build at this commit would produce, because the lockfile moved. Driftlock closes each gap with a single move: every PR carries a CycloneDX SBOM regenerated inside the hermetic sandbox, signed with the customer KMS-resident key, hashed against the lockfile that produced the diff, and stamped with the run id. The buyer trust store verifies the SBOM the same way it verifies the commit.

replay · and · the · evidence · binder

Replay: how a regulator re-enacts the row without Driftlock in the loop.

When a regulator pulls an evidence binder, they do not need access to a Driftlock control plane. They pull a run id from any prior PR, re-invoke the sandbox against the same trigger in their own environment, and get back the same diff, the same test results, the same CycloneDX SBOM byte-for-byte. They diff the lockfile and the SBOM hash together — the lockfile says what was resolved, the SBOM hash says what was signed. They verify the cosign claim against the Rekor log entries published at the time, and they walk the claim payload back to the approver chain. The result is a binder where every PR is itself a row: signed, hashed, and replayable. No Driftlock-managed control plane sits in the middle of the verification — the customer KMS, the customer artifact registry, the public Rekor log, and the sandbox the customer hosts already do the work.

the · row · is · the · evidence

The row is the evidence.

The SBOM is not an export; it is a row in the ledger tied to the run that produced it. There is no separate voyage the artefact takes, no vendor transit, no opaque nightly pipeline. The same row the regulator replays is the row the platform team signed off on the morning the PR opened, and the same snapshot the SBOM pipeline ingests on the day it lands.