As the Product Owner for Image Mode for RHEL, I've spent the last few months having some fascinating (and frankly, sobering) conversations with platform teams, security engineers, and SREs. The same themes keep surfacing, and they all point to one reality: security is getting harder, and our traditional approaches to patching aren't keeping up.
Let me share what I'm hearing, and why I think Image Mode for RHEL offers a fundamentally better path forward.
The Conversations That Keep Happening
A security engineer from a finance company recently told me about their quarterly vulnerability audit results. "We have critical CVEs sitting unpatched for months," they said. "Not because we don't care. We just don't have the bandwidth. Every week brings new vulnerabilities, and our testing-and-deployment cycle can't keep pace."
The numbers back this up. In the first half of 2025 alone, we saw 23,667 CVE disclosures, roughly 133 new vulnerabilities every single day according to Recorded Future's H1 2025 vulnerability trends analysis. And the trend isn't slowing. Industry research shows AI-assisted development is accelerating code production while introducing vulnerabilities at significantly higher rates, with some studies suggesting 10x increases in security findings.
The industry is responding to this acceleration. Red Hat and IBM recently announced Project Lightwell, a $5 billion commitment to create a trusted clearinghouse for open source vulnerabilities, leveraging AI to validate and test fixes at scale. When frontier AI models can identify nearly 4,000 high- or critical-severity vulnerabilities in open source software in a single pass, the traditional approach of discovering, patching, and deploying fixes manually simply cannot keep pace.
And it's not just the volume. The window between disclosure and active exploitation has collapsed. Research from the Cloud Security Alliance tracking the median time-to-exploit (TTE) shows a dramatic acceleration. In 2018, organizations had an average of 756 days before a disclosed vulnerability was exploited in the wild. By 2022, that dropped to 32 days. By late 2023, it was down to 5 days. In 2025, nearly one-third of tracked exploits appeared on or before the day of public disclosure. That's zero time to react.
The asymmetry is stark: attackers operate at machine speed while defenders still operate at organizational speed. Whether we believe the number or not, the increasing trend is undeniable. We're entering an era where vulnerabilities are being discovered faster than our traditional patch-and-pray approach can handle.
The Long Tail of "We'll Get To It"
Here's the part that keeps me up at night: even when we know about critical vulnerabilities, remediation takes forever.
A recent Bitsight study tracking Exchange Server systems found that of 44,180 vulnerable systems, only 25% were patched over an 18-month observation period. Eighteen months. For a critical vulnerability. And about 12% of those that did get patched took over a year to remediate.
When I ask customers why patching takes so long, I hear the same story over and over:
"We can't just patch production systems. We have to test in staging first. But staging is always behind production, so we have to update staging, test the patches there, validate that nothing breaks with our applications, get sign-off from the app teams, schedule a maintenance window. And by the time we're ready, three more critical CVEs have landed."
"Our business-critical applications all have dependencies on specific package versions. One wrong update and we risk taking down production. So we test everything. And testing takes time we don't have."
"We've got thousands of RHEL systems spread across data centers and cloud. Some are configured slightly differently because they were deployed at different times or by different teams. Every patch becomes a science experiment. Will it work the same way on all of them? We won't know until we try."
The common thread? package-based patching forces you to choose between speed and safety. You can patch fast and risk breaking things, or you can test thoroughly and stay vulnerable for months. There's no good option.
Testing Before Deploy, Every Time
This is where the conversations shift from problems to possibilities.
A platform engineer told me something that stuck with me: "Look, we've been doing immutable infrastructure for our apps forever. Container images, CI scanning, the whole nine yards. So why are we still patching the OS like it's 2005? Makes no sense."
That question cuts to the heart of what Image Mode for RHEL is about.
With Image Mode, you're not patching systems at runtime. You're building a new bootable container image, scanning it for vulnerabilities in your CI pipeline, testing it in pre-production, and then deploying that exact, tested image to production. Same image, every time. No runtime surprises.
Here's what that looks like in practice:
Security finds a critical CVE. Instead of scrambling to patch hundreds of production systems, you rebuild your bootc image with the fix.
Your CI pipeline scans the new image. Standard tools like Trivy or Clair work here. You catch vulnerabilities before anything hits production.
Deploy to staging. Because it's an image, what you test is exactly what runs in production. No surprises.
Roll out to production. Systems download the new image, stage it, switch on reboot. Atomic transaction.
Something breaks? Reboot to the previous image. Rollback is automatic.
One customer made the shift and reported going from planning to deployment in 33 days for a major architecture change, something that would have taken months with traditional package-based approaches. The difference? They built the image once, tested it thoroughly, and then rolled it out with confidence across their fleet.
The shift feels like moving from "fix it live in production and hope" to "build it right, test it completely, deploy with confidence." That's the shift-left mindset applied to the OS layer.
If you want the technical details on how to set this up, my colleague wrote an excellent guide on creating CI/CD pipelines for Image Mode that walks through the entire workflow.
How Image Mode Changes the Security Equation
When I talk to security teams about Image Mode, the conversation keeps coming back to one theme: we can finally get ahead of CVEs instead of constantly chasing them.
What's changed is how you approach security at the OS layer. Instead of patching systems at runtime, you're scanning and validating at build time. Here are the key capabilities that make this work:
Build-time scanning. CVE scanning happens in your CI pipeline, not in production. If a vulnerable image tries to get promoted, you block it. One security architect told me: "Honestly, for the first time in my career, I can tell leadership that what we scanned is exactly what's running. Bit-for-bit identical across the fleet."
Immutable filesystem. The root filesystem is read-only. Attackers can't tamper with OS packages at runtime. You want to install an unauthorized package? You'd need to rebuild the image, which means going through CI, which means security review. Runtime compromise can't result in persistent OS-level backdoors.
Atomic updates. Image Mode updates are all-or-nothing. The system either boots the new image successfully, or it stays on the current one. No "half-updated" systems stuck in some undefined state with packages at mixed versions.
Configuration consistency. What you build is what runs, everywhere. All systems on the same bootc image are bit-for-bit identical. No configuration drift, no mystery packages, no "why is this system still vulnerable when we patched it last month?"
Sealed images (RHEL 10.2 tech preview). This extends cryptographic verification from boot firmware through every file in the running OS. If even a single system file is modified after the image is built, the kernel blocks it from executing. For environments where tampering is a real threat, this is the next level of protection.
For the full technical details on these capabilities, check out how Image Mode improves security.
Bottom line: The old way is CVE announced, assess impact, test patches, schedule maintenance windows, patch production, verify, find edge cases, patch again. Rinse and repeat for every critical CVE.
With Image Mode, you rebuild the image with the fix, scan it in CI, reject if vulnerable, test in pre-prod, roll out. Once. Done.
What I'm seeing is that you're not patching thousands of individual systems and hoping they all end up in the same state. You're deploying one verified, tested, scanned image.
The Reboot Question
I'd be lying if I said this doesn't come up in every conversation.
With Image Mode, updates require a reboot to switch to the new bootc image. For some workloads, that's totally fine. For others, it's a legitimate concern.
What I'm seeing is teams thinking about it like this:
Where reboots are manageable:
- Stateless workloads (web servers, API gateways, batch processors)
- Multi-instance deployments with load balancers (rolling updates are your friend)
- Scheduled maintenance windows for single-instance systems
- With RHEL 10's soft reboot: userspace-only updates in seconds
Where reboots are trickier:
- Single-instance stateful systems without HA (databases, legacy monoliths)
- Real-time systems with strict uptime SLAs
- Edge devices with limited remote access
The pattern I'm seeing is that teams design for high availability anyway. If you can't tolerate a reboot for an OS update, you probably can't tolerate hardware failure either. So you need multiple instances, load balancing, failover. Once you have that, Image Mode's reboot requirement becomes a non-issue.
That said, there's one scenario where the reboot requirement is genuinely challenging: non-disruptive kernel updates. In my experience, this is the single most requested feature from customers managing systems that need to maintain uptime for extended periods. In some cases, 15 months or longer without reboots to meet five-nines SLA requirements.
For these environments, technologies like Kpatch (kernel live patching) remain critical. The good news? Image Mode and live patching aren't mutually exclusive. You can use Image Mode for the rapid, tested rollout of userspace updates and configuration changes, while relying on live patching for kernel CVEs during those long uptime windows.
Hybrid approaches are fine. Start with your stateless layers, prove the value, then tackle the harder problems with proper HA design or complementary technologies like live patching.
Read more about RHEL 10's soft reboot capability and controlling updates with download-only mode.
Getting Started: Start Small, Prove Value, Expand
Every customer who's successfully adopted Image Mode started the same way: pick one non-critical workload, build a bootc image, test the update/rollback workflow, measure the results.
Don't boil the ocean. Don't try to migrate your entire fleet on day one. Pick a web server tier, or a test environment, or a dev cluster. Something stateless, something with multiple instances.
Build your first image following the getting started guide. Set up a simple CI pipeline to rebuild it when security updates land. Deploy it. Test a rollback. Measure the difference in patch-to-production time compared to your traditional workflow.
Then ask yourself: What would it look like to expand this to the next workload? And the next?
One platform engineer told me their journey went: test cluster → staging environment → dev web servers → production web tier → API gateways → worker nodes. Each step built confidence. Each step delivered measurable value.
For guidance on building and managing these images at scale, see how to build, deploy, and manage Image Mode for RHEL.
The Security Landscape Isn't Slowing Down
Here's the reality: the forces driving vulnerability acceleration (AI-assisted development, increasing code complexity, interconnected supply chains) aren't going away. If anything, they're intensifying.
We can't patch our way out of this with the same approaches that worked in the past. We need architectural shifts that match the scale and pace of the problem.
Image Mode isn't a silver bullet. It won't magically solve all security challenges. But it fundamentally changes the equation. From reactive runtime patching to proactive build-time prevention. From configuration drift to guaranteed consistency. From hoping systems are secure to knowing they are.
If you're drowning in CVE remediation backlogs, fighting configuration drift across your fleet, or just tired of the patch-test-pray cycle, it's time to try a different approach.
