Someone will ask what was running on the day it happened.
An auditor, an insurer, a customer's security team, or your own board. The question is always some version of the same one: which software was on that server, in which version, on which date. Answering it from memory is uncomfortable. Answering it from a record is not.
The awkward part is rarely the answer itself — it is that the evidence was never kept. A base image gets rebuilt, a tag gets overwritten, the person who set up the pipeline has moved on, and what shipped in March is genuinely no longer knowable.
Every image we build keeps its own record: the complete list of packages and versions that went into it, tied to a version number that does not move.
"Which version of that library was in production in March?"
Open the build history for that month. Every build lists its packages with exact versions — no reconstruction from Git tags and a hopeful guess about the base image.
"What changed between these two deployments?"
Compare the two builds side by side and see exactly which packages and layers were added, removed or bumped — before you deploy, or long afterwards.
"Were you affected by this CVE?"
Check whether the package was ever in your image at all. Most of the time the honest answer for a purpose-built image is that the component was never shipped.
"How quickly do you apply security updates?"
The update feed records when a package was rebuilt and published. That is a timestamped answer rather than a policy document describing intentions.
A shorter list is easier to defend.
Your image contains what your composer.lock requires and nothing else.
That is not only less attack surface — it is a shorter inventory to review, and every
item on it has a reason to be there that you can actually give.
Versions that stand still.
Each build gets its own semantic version, and that version keeps pointing at the same content. An old tag stays pullable and stays what it was, which is what makes it usable as evidence at all.
A person you can quote.
Questionnaires sometimes need an answer no dashboard covers. Two people build this, and one of them replies — with a name attached, which is generally what the form is asking for.
Before the next questionnaire
Start keeping the record now.
A free account gives you a private registry and a build history from the first image onwards. The record is only useful if it starts before somebody asks for it.
To be precise about what this is and is not: we record what went into the images we build for you — packages, versions, layers and their build dates. That is the container side of an inventory, not a full SBOM across your application dependencies, and it does not replace an audit. It answers the part of the questionnaire that is usually hardest to reconstruct.