A Bug is a Bug, but a Patch is a Policy: The Case for Bootable Containers

Posted on February 20, 2026  •  3 minutes  • 633 words

The old compliance rule no longer works

For years, enterprise security has lived by a simple, if flawed, rule: “Patch anything with a CVSS score above 7.0 within 30 days.” It was a clean metric for auditors and a clear directive for SRE teams.

But in a recent post , Greg Kroah-Hartman, as the head of the Linux Kernel CNA, confirmed a shift that breaks this model. The kernel team is now assigning CVEs to almost every bug fix, thousands of them, but they are refusing to provide a CVSS score.

Greg’s argument is a hard truth: “Usage is different for each user.” He cannot score a vulnerability because he doesn’t know if you’re running a cloud-native microservice or a legacy industrial controller.

You either triage carefully or patch at velocity

Large organizations are now at a crossroads between two radical philosophies. With the kernel CNA no longer providing CVSS scores, you can’t rely on NIST, NVD, or similar bodies to prioritize for you. That crutch is gone.

The triage way (the “precision” tax) This is the traditional approach: manual analysis to see if a “Worst Case Scenario” CVE actually reaches your specific environment. While accurate, it is expensive, slow, and prone to human error. In the face of thousands of unscored kernel CVEs, manual triage is a losing battle.

The Chainguard way (the “velocity” mandate) This philosophy treats triage as a legacy bottleneck. If a patch exists, apply it immediately to reach “Zero-CVE” status. Companies like Chainguard can do this because they bet on a minimal attack surface: small images are easier to test and harder to break. For everyone else, this velocity often leads to Update Fatigue: the very real fear that a frequent kernel update will break production drivers or specialized configurations.

bootc treats the whole OS as a container image

The reason Update Fatigue exists is that we’ve been treating the operating system like a fragile, stateful pet. bootc changes the game by treating the entire OS (kernel, drivers, and user-space) as a standard container image.

By moving to an image-based, bootable container model, we can finally reconcile Greg KH’s “unscored” world with corporate stability:

• Atomic certainty You don’t “patch” a running server; you push a new version of the OS image. If the new image fails a health check, the system automatically rolls back. This eliminates the primary risk of the “Velocity” approach.

• Environmental triage by design Greg won’t score the CVE because he doesn’t know your stack, but you do. If your bootc image is minimal (distroless), your vulnerability scanner only flags what is actually inside that image. You aren’t triaging spreadsheets; you are triaging your build file.

• Solving the human element We solve Update Fatigue by removing “reboot anxiety.” When an OS update is an atomic transaction in a CI/CD pipeline, the “patch” becomes an invisible, automated background task rather than a high-stakes manual event.

For a concrete walkthrough of bootc and getting to a 0-CVE OS on VMs, see my old post achieving a 0-CVE OS for VMs: the end of traditional patching .

Security is local; the patch should be policy

Greg KH isn’t making our lives difficult for fun. He’s highlighting the fact that security is local. The future of corporate security isn’t a team of humans debating CVSS scores.

We must stop litigating which fixes matter and start treating every kernel bug fix as relevant (a bug is a bug). We must stop running patching as a project and bake it into the pipeline so that applying stable fixes is simply what the system does (the patch is the policy). bootc is the engine for that policy: build, test, deploy. We don’t need to know the “score” of a vulnerability if our infrastructure is resilient enough to move faster than the exploit.