Detection vs Prevention

The Detection vs Prevention Problem

We’ve established that containers have fundamental security challenges. Now let’s talk about how the industry has been trying to solve them and why it’s not enough.

The Security Treadmill

Here’s the current state of container security:

1. New vulnerability discovered
2. Security vendors release detection signatures
3. You deploy detection tools
4. Hope you catch attacks before damage is done
5. Patch the vulnerability
6. Roll out patches across infrastructure
7. Repeat weekly

This is a reactive cycle. You’re always behind, always patching, always worried your detection is good enough and patching is fast enough.

Detection-Based Security: The Current Approach

Most container security today relies on:

Runtime Monitoring

• Watch for suspicious syscalls
• Detect unusual process behavior
• Monitor network connections
• Alert on anomalies

Problem: Detecting a real-world breach from a syscall alert is nearly impossible. And by the time you detect the attack, the attacker may have already escaped and pivoted.

Image Scanning

• Scan container images for vulnerabilities
• Block images with critical CVEs
• Enforce signing and provenance (good, but no one really does this in practice)

Problem: Zero-day vulnerabilities and kernel exploits aren’t in your container image, they’re in the kernel which is patched rarely.

Network Policies

• Segment workloads with network rules
• Restrict ingress/egress traffic
• Implement zero-trust networking

Problem: Doesn’t prevent container escapes or kernel exploits. One successful escape and you can disable all Network Policy rules and eBPF altogether.

Admission Controllers

• Enforce security policies at deployment time
• Restrict privileged containers
• Require security contexts

Problem: All policies can be bypassed if the kernel is compromised.

The False Sense of Security

Here’s the uncomfortable reality: all of these tools are valuable, but they’re band-aids on a architectural wound.

They operate under the assumption that:

1. Container isolation is “good enough”
2. We can detect and respond to breaches
3. Defense in depth will compensate for fundamental weaknesses

But what if the foundation is flawed?

The Cost of Breaches

Let’s talk numbers. What happens when detection fails?

Dwell Time

According to IBM’s Cost of a Data Breach Report:

• Average time to identify a breach: 204 days
• Average time to contain a breach: 73 days
• Total dwell time: 277 days

That’s nine months that an attacker has access to your systems.

Financial Impact

• Average cost of a data breach: $4.45 million
• Cost for breaches over 50M records: $348 million
• Regulatory fines (GDPR): Up to 4% of global revenue

Operational Impact

• Incident response team mobilization
• Forensic investigation
• Full-scale system rebuilds
• Customer notifications
• Legal and PR costs
• Lost business and reputation damage

Prevention: A Different Philosophy

What if instead of trying to detect attacks, we made them impossible by design?

This is the philosophy of prevention-based security:

“Don’t detect the container escape. Make it architecturally impossible.”

Shift Left… All the Way to the Architecture

The industry loves “shift left”—finding vulnerabilities earlier in the development cycle. But we need to go further:

Shift security left to the architecture itself.

Instead of:

Write Code → Build Image → Scan → Deploy → Monitor → Detect → Respond

Do this:

Design Secure Architecture → Deploy Faster with Confidence → Monitor

What Prevention Looks Like

True prevention means:

1. Hardware-enforced isolation - Not software tricks
2. Minimal trusted computing base - Less code = less vulnerabilities
3. No shared kernel - Eliminate the entire attack surface
4. Defense in depth - Still use detection tools, but they become far less noisy and relevant

This is what hypervisor-based isolation provides.

The Hypervisor Advantage

Virtual machines have been doing strong isolation for organizations and every major cloud provider for decades:

┌─────────────┐  ┌─────────────┐
│   VM 1      │  │   VM 2      │
│  [Kernel A] │  │  [Kernel B] │
├─────────────┤  ├─────────────┤
│         Hypervisor           │
├──────────────────────────────┤
│          Hardware            │
└──────────────────────────────┘

Key difference: Each VM has its own kernel.

If VM 1’s kernel is compromised:

• ✅ VM 2 is unaffected (different kernel)
• ✅ Host is protected (hypervisor isolation)
• ✅ Hardware enforces the boundary

This is prevention, not detection.

But VMs Are Slow and Heavy… Right?

This is old thinking. The legacy VM model was:

• Heavy: Full OS per VM
• Slow: Long boot times
• Overhead: High memory and CPU cost

But modern hypervisors and paravirtualization change this equation.

What if you could get VM-level isolation with container-like performance?

That’s the core insight behind Edera.

The Edera Philosophy

Edera’s approach is simple:

Assume breach before it occurs. Build isolation so strong that breaches are truly contained.

This means:

1. Every container runs in its own microVM
2. Each microVM has its own kernel
3. Xen hypervisor enforces hardware isolation
4. Minimal trusted computing base (360K lines of code vs 27 Million)

Prevention So Good, Every Alert Has a Purpose

With strong architectural isolation:

• Detection tools become confirmation, not your primary defense
• Patching becomes less urgent (isolated blast radius)
• Multi-tenancy becomes actually safe
• Compliance becomes demonstrable

You can move fast without breaking things.

The Real World

Let’s revisit those scenarios from earlier:

Multi-Tenant Platform

Before: Customer C escapes container, compromises cluster With Edera: Customer C is trapped in their microVM, can’t escape their own kernel

GPU Workloads

Before: Shared GPU driver, potential memory leaks between containers With Edera: GPU virtualization, each container has isolated GPU access

Container Escape

Before: Kernel exploit → host compromise → lateral movement With Edera: Kernel exploit → stuck in microVM, hypervisor blocks escape

Moving Forward

We’ve covered the problem space:

• ✅ Containers are processes with a shared kernel
• ✅ This creates fundamental security challenges
• ✅ Real-world attacks exploit these weaknesses
• ✅ Detection-based security is insufficient
• ✅ Prevention through architecture is the answer

Now it’s time to see how Edera actually implements this vision.

Next Module: The Edera Solution →

Module 1 Summary

Key Takeaways:

1. Containers share a kernel and this is a fundamental security weakness
2. Container escapes are real, recurring, and costly
3. Multi-tenancy and GPU isolation are particularly challenging
4. Detection-based security is reactive and insufficient
5. Prevention through hypervisor isolation changes the game

Questions to Consider:

• How will a container escape impact your organization?
• What’s the cost of a 9-month dwell time in your environment?
• Are your current isolation guarantees sufficient for compliance?
• What would true prevention-based security enable for your business?

Ready to see how Edera solves these challenges? Let’s dive into Module 2.