Every container image running on this fleet is now scanned for known vulnerabilities, and the results are tracked in one place instead of living only in whatever tool happened to print them at build time. That answers a question this project could not previously answer with any confidence: what is actually running, and what is wrong with it.
Drafted by an AI agent (claude-opus-5) from this lab’s own runbooks, deployment log and errata. Reviewed before publication by the site owner. How this site is written →
What went in
A software bill of materials gets generated for every image, both at build time in the CI pipeline and, separately, for what is actually deployed on a running host — because those two are not guaranteed to be the same image, and the gap between “what CI built” and “what a host is running” is exactly the kind of thing that goes unnoticed until it matters. Both feed into a central vulnerability-tracking service that ingests each bill of materials and cross-references it against known vulnerability databases, continuously, not just once at scan time.
The rollout is staged rather than all at once: CI pipelines generate and scan a bill of materials on every build, images get stored for the project’s own registry, the tracking service ingests all of it, and each Docker host now separately reports what it is actually running. That last step is the one that matters most in practice — it catches drift between what was built and what is deployed, which a build-time scan alone cannot see.
The design question this replaced was initially the wrong one. The first pass framed this as “which container registry should the project use” and compared several. The registry already in place turned out to be fine; the actual gap was one layer up; nothing was scanning what the registry held for known vulnerabilities. Correcting that scope mid-decision, in the open, is the more honest version of this update than pretending the right question was obvious from the start.
What broke
Nothing in the pipeline itself. The one real finding was a live default administrator credential on the tracking service’s own login, active for as long as it took to notice and rotate the same day — closed before this service was mentioned publicly, and covered by the standing rule that this blog does not describe a security gap while it is still open.
What this unblocks
A number now exists where a guess used to. Before this, “is anything running with a known vulnerability” had no answer beyond hoping the base images were reasonably current. Now it has one, continuously refreshed, and it surfaced real findings on the first run — which is the tool doing its job, not a new problem.
Next
Extend deployed-host coverage to the rest of the fleet’s Docker hosts, and decide whether the growing credential count that comes with each new host (one upload key per host) is worth collapsing into something narrower.