Container hardening: 300+ vulnerabilities to zero

Long-lived services running on container images built years earlier, with base layers and language runtimes that had aged out of support. A security programme had begun enforcing scan thresholds.

Over three hundred reported vulnerabilities across the image set. Naive fixes — bumping the base image or upgrading a runtime — broke the applications, and nobody could say which pinned versions were load-bearing.

Zero tolerance for behavioural change in production. No rewrite budget. Some dependencies were transitive and undocumented, and a subset of findings had no upstream fix at all.

I separated findings into categories: fixed by rebasing, fixed by dependency upgrade, fixed by removing something the image did not need, and genuinely unfixable. The last group shrank considerably once unused packages and build tooling were removed from runtime images.

Each image was remediated in isolation, exercised against its previous behaviour, and promoted only after verification. Multi-stage builds kept build tooling out of the shipped layer.

Reduce the surface before patching it. Most of the vulnerability count came from packages the running application never used.

Add scanning to CI as a gate rather than a report, so the count could not silently climb back.

Remediated images passed the security gate with no known vulnerabilities and no functional regressions. The pipeline now fails on newly introduced findings, which turned a one-off cleanup into a maintained state.

Container images are a maintenance surface, not a build artifact you write once. Treating them as inventory — owned, dated, and rebuilt on a schedule — is cheaper than periodic remediation projects.

Remediation shipped image by image, each verified against the previous behaviour before promotion.