The container image backing my repository server had quietly accumulated over 290 CVEs. Each of those is not just a statistic—they’re potential entry points on the attack surface.
Let’s be clear: just because this service ran inside Kubernetes doesn't mean those vulnerabilities were somehow magically mitigated. Kubernetes may abstract deployment and orchestration, but it does nothing to shrink the surface exposed by the containers themselves. A vulnerable container in Kubernetes is still a vulnerable system.
This image was built on Rocky Linux 9. While updates were technically available, actually applying them was more difficult than it should have been. Patching wasn't just a matter of running dnf update—dependency entanglements and version mismatches made the process fragile.
I attempted a move to Rocky Linux 10, hoping for a cleaner slate. Unfortunately, that path was blocked: the DEB repo tooling I rely on couldn’t be installed at all. The package dependencies for the deb-dev utilities were broken or missing entirely. At that point, the problem wasn’t patching—it was the platform itself.
That left one real option: rebuild the entire server as a pure Go application. No more relying on shell scripts or external tools for managing Debian or RPM repository metadata. Instead, everything needed—GPG signing, metadata generation, directory layout—was implemented natively in Go.
The Result
- Container size dropped from 260MB to just 7MB
- Current CVE count: zero
- Dependencies are explicit and pinned
- Future updates are under my control, not gated by an OS vendor
In practical terms, the entire attack surface is now reduced to a single statically-linked Go binary. No base image, no package manager, no lingering system libraries to monitor or patch.
This is one of those changes that doesn’t just feel cleaner—it is objectively safer and more maintainable.
Lesson reinforced: containers don’t remove the need for security hygiene. They just make it easier to ignore it—until it’s too late.
No comments:
Post a Comment