Deployed-Artefact Ledger

A critical vulnerability is announced in a transitive dependency. The organisation has an SBOM and a signed provenance attestation for every build, and admission policy verifies the attestation before a pod starts. The first question asked is "is it running anywhere", and nothing in the programme can answer it, because every artefact the team has is a statement about a build rather than about a deployment.

The ledger is the missing join. Written by the deployment mechanism: artefact digest, environment, cluster, when it started running, when it stopped, and what put it there.

Why it matters

During a vulnerability response three questions are asked in order: is it in anything we build, is it running anywhere right now, and how fast can we get it out. Per-build metadata answers the first. The ledger answers the second, and the second gates the third.

Without it, the answer is assembled by asking teams, which is what turns a 20-minute response into 48 hours. The time is not spent patching; it is spent establishing scope, and across 30 teams even a 2-hour turnaround per team is a day of elapsed time.

It also answers the audit question provenance alone cannot. "Prove the container running in production is the one that passed security review" requires the running digest, and no build-time artefact contains it.

And it is the only honest basis for a retention decision: SBOMs are worth keeping for artefacts that reached an environment, which is a small fraction of all builds.

Implementation patterns

• Write from the deployment mechanism, not from the pipeline. The pipeline records intent; the deployer records what happened. Anything else drifts.
• Append-only, with start and stop times. A current-state table cannot answer "what was running on 12 March", which is the audit and incident question.
• Key on digest. Tags and version strings are not identities.
• Record the environment, the cluster or region, and the workload identity, so the query result is actionable rather than a count.
• Retain longer than your longest-lived workload. A pod that has been running for 14 months must still resolve to a ledger row.
• Join it to the SBOM index, and test the joined query on a drill: pick a dependency, ask for affected running workloads, and time the answer.
• Include non-container artefacts — mobile bundles in stores, serverless function versions, firmware, machine images. They have the same question and usually no ledger at all.

Industry example

The capability is what asset-inventory requirements in security frameworks have always been asking for, and what the industry rediscovered under pressure during the Log4Shell response in December 2021: organisations with a current inventory of running artefacts scoped the problem in hours, and organisations without one spent days surveying teams while the exposure continued. The technical fix was widely available almost immediately; the scoping was the bottleneck.

The xz-utils backdoor disclosed in March 2024 (CVE-2024-3094) makes the adjacent point about provenance: the malicious macro shipped in the release tarballs and not in the equivalent state of the public repository, so a pipeline that trusts a release archive rather than a verified build from source cannot see the difference — and a ledger is what tells you where that archive ended up.

Failure scenarios

• Scope established by survey, because the ledger does not exist, so the response is gated on human availability.
• A current-state-only inventory, which cannot answer questions about a past date.
• Ledger keyed on tag or version, so two different images collapse into one row.
• The pipeline as the source, recording deployments that were rolled back and missing those done by hand during an incident.
• No coverage of mobile, serverless or machine images, so a whole class of artefact is invisible.
• A ledger nobody has queried, discovered during the incident to be missing the one field the query needs.

Trade-offs

The ledger costs a write on every deployment, a store with real retention, and the discipline of keeping it the single source. It is cheap compared with what it replaces, and the genuine cost is organisational: every deployment path must write to it, including the irregular ones, and the irregular ones are exactly where it is skipped.

There is also a security consideration that cuts both ways. A complete inventory of what runs where is valuable to a defender and valuable to an attacker, so it needs the access controls of a sensitive asset rather than those of a build log.

When not to use it

One application, one environment, one team. The deployment history your tooling already keeps is the ledger, and building a second one is duplication. The threshold is roughly where no single person can answer "what is running where" from memory — commonly around 5 teams and 3 environments.

Also not as a replacement for admission control. The ledger is a record and admission is a control: one tells you what happened, the other stops the wrong thing happening. Teams that build the ledger sometimes argue the control is now redundant, and it is not.

Interview question

Q: A critical vulnerability lands in a widely used library at 09:00. Your organisation has SBOMs and attestations for every build. Walk me through the first hour, and tell me what you would change before the next one.

What a strong answer covers: the three questions in order, and recognising that the second one — what is running — is the one the current artefacts cannot answer · the interim approach, querying deployment history per cluster and accepting it is incomplete · the change: a deployed-artefact ledger written by the deployer, append-only, keyed on digest, with start and stop times, joined to an SBOM index for promoted artefacts only · timing the joined query in a drill rather than assuming it works · extending coverage to mobile bundles, serverless versions and machine images · the next capability after scope, which is revocation throughput — how long a patched artefact takes to reach every affected cluster, a number that should be measured in advance · and keeping admission control, because a record is not a control.

Quick check

Quiz: Which question can an SBOM-per-build programme not answer, and what artefact answers it? — "Is it running anywhere right now", answered by an append-only ledger of which digest ran in which environment and when.

Flashcard: Why must the ledger be written by the deployer rather than the pipeline? — The pipeline records intent, including deployments that were rolled back, and misses anything applied outside it; the deployer records what actually ran.