SBOM drift automation for platform engineers: catching dependency divergence before the auditor does.

what · sbom · drift · is

What SBOM drift is and why platform teams miss it until the auditor asks.

SBOM drift is the condition where the SBOM in your artifact registry no longer reflects the lockfile resolved at the current HEAD of your repository. It happens between PRs in batch-scan flows: a batch run produces one SBOM per cycle, and every lockfile change that lands between cycles produces drift that the SBOM cannot represent. A quarterly SBOM export is a point-in-time snapshot of the world at the moment the batch ran — it says nothing about the eleven PRs that landed after it. The auditor does not ask for a snapshot; they ask for a continuous record of every dependency-touching change, in the order those changes merged. A batch SBOM cannot answer that question, and platform teams running batch flows discover this gap only when the auditor replays the PR chain against the quarterly export and finds the two do not reconcile.

renovate · lockfile · but · no · sbom

Renovate keeps lockfiles current. It does not emit a signed SBOM delta.

Renovate's job is the lockfile bump PR. It watches the advisory feeds, opens the bump, and keeps the lockfile current — that posture is correct and necessary. SBOM generation is outside Renovate's scope by design; the project does not claim it and the gap is not a Renovate failing. The gap is a posture gap that sits between the lockfile bump and the supply-chain ledger: the lockfile changed, but there is no signed CycloneDX document that records what the change meant for the package inventory, no cosign signature binding the SBOM hash to the commit, and no audit-trail row the regulator can replay. A separate signing and emission step closes that gap — one that runs inside the same hermetic sandbox that produced the diff and signs over the compound claim that ties the SBOM to the commit.

per · pr · cyclonedx · posture

Per-PR CycloneDX emission closes the drift loop. Cosign pins the snapshot.

The per-PR posture closes the drift loop by making the SBOM a first-class output of every dependency-touching PR, not a batch artefact produced on a separate schedule. Every PR that changes the lockfile emits a CycloneDX 1.5 document regenerated from the lockfile resolved inside the hermetic sandbox — not lifted from a vendor, not produced by a nightly scanner. The sandbox signs the document with cosign over the compound claim (commit_sha || sbom_sha256): the commit sha pins the source, the SBOM sha256 pins the supply-chain artefact, and any drift between the two cannot pass the signature. The signed SBOM is the seventh column in the audit-trail row — the same row that carries the trigger source, the triage record, the diff, the sandbox test results, the approver chain, and the commit signature. Drift detection at ingest is the final check: if the SBOM hash in the ledger row disagrees with the hash of the lockfile that produced the diff, the row is flagged at ingest and does not reach the audit-trail ledger without a remediation pass.

cost · of · batch · vs · continuous

The cost of quarterly-batch SBOM: three risks the schedule hides.

A quarterly-batch SBOM produces a snapshot, not a ledger. The snapshot hides three risks that only become visible when the quarter closes and the regulator pulls the evidence binder.

• CVE invisibility windowA vulnerability lands on day two of the quarter and the SBOM is ninety days stale. The regulator replays the quarter and finds a gap: the vulnerability was in the lockfile for eleven weeks before the SBOM reflected it.
• Regulator evidence gapThe regulator replays the quarterly export and cannot reconcile it against the merged PR chain. Each PR moved the lockfile; the batch SBOM represents only one point in the sequence, and the intermediate states are unrecorded.
• License drift windowA licence change — permissive to source-available — propagates for sixty days before detection. A per-PR SBOM would route the anomaly on the day the change merged; the batch scan discovers it on the next quarterly cycle.

who · runs · this · today

Who runs per-PR SBOM drift detection in production today.

Regulated platform teams are running per-PR SBOM emission as a first-class merge gate — not a quarterly audit step — because their regulators ask for it directly. Fintechs under PCI-DSS need a continuous SBOM record that reconciles against the merged PR chain; SaaS platforms under SOC 2 Type II need the SBOM hash in the same ledger row as the approver chain; government contractors under FedRAMP need a signed CycloneDX document on every dependency-touching commit, verifiable by the agency without access to the vendor control plane. The posture is not experimental — it is the bar those regulated environments set when they read the supply-chain hygiene section of the audit scope-of-work. Platform teams outside regulated environments are adopting the same posture ahead of the audit, because the cost of retrofitting a continuous-SBOM record after the regulator asks is significantly higher than running it from the first PR.