— Patrick Burke (Chainguard) on minimal container images and FedRAMP SLAs
Quick recap. Patrick Burke (Chainguard, Solutions Engineer) presented on minimal container images — what they are, why vulnerability trends are driving adoption, and how they compare to traditional patching, golden-image programs, and debloated images. Over a live demo he walked through building the same FastAPI Python app on four base images and running Trivy against each: the stock `python` image produced 1,699 vulnerabilities (269 critical/high), `python:slim` dropped it to 90 (2 critical, 7 high), `python:alpine` further to 3, and a Chainguard base image to 2. The group then debated FedRAMP SLAs for CVE remediation (30/90/180 days for critical/high/medium), the pros and cons of each approach, and when self-managing a Kubernetes control plane actually makes sense. Shawn noted this was the 129th CSOH session.
Show 7 discussion topics
Vulnerability Trends and the Case for Minimal Images
Patrick opened by framing vulnerabilities as flaws in a specific piece of open-source or vendor software, typically fixed by upgrading to a patched version (Log4Shell → 2.15.0-rc1 and the 2.16 line). Year over year, CVE counts have climbed steadily for the last eight years, with a visible acceleration recently. That's the forcing function: throwing more engineers at remediation scales poorly, so the industry is moving toward reducing the surface that can carry vulnerabilities in the first place.
Containers, Kubernetes, and Open Source — The Setup
Patrick ran quick refreshers on what a container is (standardized unit packaging source, dependencies, and config so the app runs the same on any host), distinguished application images (nginx, redis, mysql) from base images (python, golang, ubuntu), and used a "contractor and project manager" analogy for Kubernetes — with containers as specialized workers and Kubernetes as the orchestrator handling scheduling, networking, storage, and resilience. Adoption data from Red Hat, Gartner, Docker, and Wiz all pointed to very broad container adoption. One interesting Wiz stat: an 8% uptick between 2023 and 2024 in self-managed Kubernetes control planes on VMs inside AWS.
When Self-Managing a Kubernetes Control Plane Makes Sense
Kyle pushed back on Patrick's read of the self-managed uptick, suggesting it could just as easily signal cost pressure, multi-cloud ambitions, or overconfidence — "like rolling your own crypto." Juninho (ex-GCP) countered that some of Google's biggest customers hit the edges of what managed offerings permit, and moving off-managed is a legitimate workaround for real constraints. Neil added that "self-managed" is a misnomer: many of these clusters aren't raw Kubernetes but distributions like OpenShift or Rancher with established configuration patterns. Jay (SAP) confirmed multi-cloud and versioning control are the two biggest drivers in practice — SAP runs its own Gardener-based distribution so dev and ops teams get the same platform on bare metal or any cloud, and enterprises often can't keep up with aggressive cloud-provider version bumps.
Open Source Is Most of the Code You Ship
Patrick cited Google data putting open-source components at 77% of modern applications and a colleague's audit that measured 76.2–99.9% OSS content across five commercial Java apps. Kyle noted many tech companies hire dedicated open-source maintainers for libraries they depend on (Steam funding Proton and Wine, Microsoft with VS Code and GitHub). Dave pointed out that "open source" is also a distribution strategy — giving the platform away to drive adoption, then monetizing on top. Stryker recalled a SecTor keynote that framed the trust question: despite vulnerabilities, OSS is so woven into everything from NASA to Microsoft that opting out isn't realistic.
Live Demo: Four Base Images, Four Outcomes
On the same FastAPI Python app with an empty `requirements.txt` (zero application-layer vulns), Patrick rebuilt against four base images and ran Trivy: - `python` — 1,699 total vulnerabilities, 269 critical + high. - `python:slim` — 90 total, 2 critical, 7 high. - `python:alpine` — 3 total, 1 critical, 2 high. - `chainguard/python` — 2 total, 0 critical, 1 high, 1 medium. The Alpine and Chainguard results were close in this snapshot. Patrick emphasized that raw counts aren't the full story — the differentiator is what happens over time.
Compliance and SLAs — the Real Differentiator
Shawn jumped in to reinforce that a lower starting count isn't the only reason to buy a minimal-image product: vendors like Chainguard attach SLAs to CVE remediation, which matters once you build those images into your pipeline as the approved "golden" ones. Patrick tied this to FedRAMP, which mandates critical CVEs remediated in 30 days, high in 90, and medium in 180. Meeting those timelines without a vendor SLA requires very strict internal controls. Minimal-image vendors also commonly ship FIPS-validated (140-2 or higher) cryptography for the same customer base — agencies selling to the federal government.
Four Approaches to Managing Container Vulnerability Load
Patrick closed with a side-by-side of the four strategies an org can pick between: 1. **Patch as discovered.** Scanner finds a CVE, security pings the engineer, engineer patches. Easiest to green-light — no budget or political capital required — but inefficient, often misses internal SLAs, and is miserable for the people doing it. 2. **Golden image program.** The SRE or platform team curates a catalog of vetted base and application images. Real reduction in vulnerability load, but meaningful upfront and ongoing investment and a constant battle to get developers to pull from the catalog instead of rolling their own. 3. **Minimal container images (paid).** Vendors like Chainguard ship trimmed-down Linux distributions with only the packages each image actually needs, plus SLAs and FIPS validation. Trade-offs: some testing required (no package manager, no curl in the most minimal variants) and it's a line-item cost. 4. **Debloated images.** Vendor ships an image; customer writes a coverage test describing how the app is actually used; instrumentation strips unused packages based on the observed runtime path. Can beat open-source alternatives on vulnerability count and often comes with some FIPS coverage, but SLAs are not guaranteed.