Bootable Containers: Building Zero-CVE Infrastructure in 2026
The Linux kernel team recently changed how they handle CVE assignments. Greg Kroah-Hartman announced that the kernel CNA now assigns CVEs to nearly every bug fix but refuses to provide CVSS scores. His reasoning is straightforward: usage differs for each user, and a vulnerability that devastates a cloud microservice may be irrelevant to an industrial controller. This shift breaks the traditional "patch anything above CVSS 7.0 within 30 days" compliance model that enterprise security teams have relied on for years.
The Triage Dilemma
Organizations now face a difficult choice. Manual triage requires analyzing whether each unscored CVE actually affects your specific environment. This approach is accurate but expensive, slow, and scales poorly when facing thousands of kernel CVEs. The alternative is aggressive patching: apply every fix immediately to maintain zero-CVE status. Companies with minimal container images can pull this off, but most enterprises fear that rapid kernel updates will break production systems.
This fear has a name: Update Fatigue. The anxiety that a necessary security patch might cause unexpected regressions keeps many organizations running vulnerable systems longer than they should.
Enter bootc
bootc changes this equation by treating the entire operating system (kernel, drivers, and userspace) as a standard container image. Instead of patching a running server, you build and deploy a new OS image. If health checks fail, the system automatically rolls back to the previous working state.
# Build a bootable container image
podman build -t localhost/myos:latest -f Containerfile .
# Deploy to a system running bootc
bootc switch localhost/myos:latest
Quick Reference
| Concept | Traditional Patching | bootc Approach |
|---|---|---|
| Update method | In-place modification | Atomic image swap |
| Rollback | Manual, often incomplete | Automatic on failure |
| Testing | Production is the test | CI pipeline validation |
| Downtime | Uncertain duration | Predictable reboot |
| State | Accumulated drift | Clean slate each deploy |
Why bootc Solves the CVE Problem
Atomic transactions eliminate update anxiety. When OS updates are atomic operations in a CI/CD pipeline, patching becomes an invisible background task rather than a high-stakes manual event. Your infrastructure either accepts the new image or rolls back automatically.
Minimal images reduce attack surface. When your bootc image follows distroless principles, vulnerability scanners only flag what actually exists in the image. You triage your build file, not spreadsheets full of potential CVEs.
Environmental context becomes explicit. Greg KH cannot score CVEs because he does not know your stack. With bootc, your Containerfile documents exactly what runs in your environment, making vulnerability relevance obvious.
Getting Started
Install bootc on Fedora or CentOS Stream:
dnf install bootc
Create a Containerfile for your OS image:
FROM quay.io/fedora/fedora-bootc:40
RUN dnf install -y nginx && dnf clean all
COPY nginx.conf /etc/nginx/nginx.conf
Build and push to your registry:
podman build -t registry.example.com/myos:v1 .
podman push registry.example.com/myos:v1
Production Considerations
Run comprehensive tests in your CI pipeline before deploying new images. Use canary deployments to validate changes on a subset of systems before rolling out fleet-wide. Monitor boot success rates and automate rollback triggers based on health check failures.
Bootc integrates with existing container tooling. You can use the same registries, scanning tools, and CI systems you already have. The difference is that your "container" now includes the entire operating system.
The Future of Patching
The kernel team is right that security is local. Rather than debating CVSS scores, the industry is moving toward infrastructure that can absorb every bug fix automatically. When applying stable fixes is simply what the system does, you no longer need to know the score of a vulnerability. Your infrastructure stays resilient by moving faster than potential exploits.
Bootable containers represent a fundamental shift in how we think about operating system maintenance. Instead of treating servers as fragile pets requiring careful manual care, we treat them as cattle that can be rebuilt from a known-good image at any time.
Conclusion
Bootc offers a path forward for organizations struggling with kernel CVE triage. By treating the OS as an immutable container image with atomic updates and automatic rollbacks, teams can patch aggressively without fear. The traditional patching model is breaking down, and bootable containers provide a practical alternative.
Looking for an AI-powered platform to automate your infrastructure operations? Check out Akmatori, an open-source AI agent designed for SRE teams. Built on Gcore infrastructure for reliable global performance.