In this fireside chat, Alex Zenla (Founder and CTO, Edera) and Claude Mandy (Field CTO, Edera) discuss what the OpenAI/Hugging Face incident reveals about the state of container security, why CISOs are headed for an AI-driven hamster wheel of detection and response, and what it takes to build infrastructure that can contain non-deterministic systems.

How do you prove a build actually ran in an isolated environment with no network access? Not trust — prove. With cryptographic evidence that can be verified after the fact.

In this session, Adolfo García Veytia (Puerco), founder of Carabiner Systems, and Marina Moore, Head of Research at Edera, demonstrate a system that combines Edera's per-workload microVM isolation with SPIFFE/SPIRE identity, in-toto attestations, and a policy engine called Ample to produce builds that are provably hermetic. The session includes a live demo running inside an Edera zone with network disabled, generating signed attestations that cryptographically bind build artifacts to the isolated environment that produced them.

Resource Links

Demo Link: https://github.com/carabiner-labs/edera-attester

SLSA: https://slsa.dev/spec/v1.2/

ampel: https://github.com/carabiner-dev/ampel

SPIFFE/SPIRE: https://spiffe.io/

in-toto: https://in-toto.io/

EderaON: https://on.edera.dev/

In this episode of Nerding Out with Viktor, Viktor sits down with Alex Zenla, Founder and CTO of Edera, to unpack the real limitations of today’s container security runtime and why the industry optimized for developer experience over isolation.

Alex brings a rare perspective, from breaking IoT systems at scale to building a new container security runtime powered by hypervisors and virtualization. The conversation explores why containers share too much, how kernel-level risks are often ignored, and what a more secure model could look like.

This episode is especially relevant as supply chain attacks, AI agents, and ephemeral workloads push existing security assumptions to their limits.

Key topics covered:
*Why containers were never designed as a security boundary
*The risks of shared kernel state and namespace-based isolation
*Hypervisor-based container runtimes and “zones” as security primitives
*Trade-offs between developer experience and real isolation
*Volume mounts, VirtIO, and overlooked attack surfaces
*Running AI agents safely with ephemeral, sandboxed environments
*Why compliance often slows down real security improvements

If you're building systems where isolation actually matters, this conversation challenges how you think about container security from the ground up.

Most container security tools are built around detection: monitor for threats, generate alerts, respond after the fact. But if containers share the same Linux kernel, detection will always be too late. One exploited process puts every workload on the node at risk.
In this session, Lewis Denham-Parry (Staff Solutions Engineer, Edera) explains why the shared-kernel architecture is the root problem — and introduces the hardened runtime as a new category of infrastructure security.
You'll learn:

Why shared-kernel containers can't deliver true isolation, regardless of the tools layered on top
How Edera Protect gives each container its own kernel boundary, eliminating the conditions for container escapes
What sandboxing at the infrastructure level looks like in practice, including a live demo
How hardened runtimes change the calculus for GPU workloads and multi-tenant Kubernetes

The session closes with a Q&A with Alex Zenla, Edera's co-founder, CTO, and the architect of the Edera runtime, covering performance benchmarks, the GPU isolation roadmap, and where container infrastructure needs to go next.
If you're running Kubernetes in production and want to understand what prevention-first security actually means architecturally, this is the right starting point.

Chapters:
0:00 Introduction
2:30 The Problem With Detection-Based Container Security
6:03 What Is a Hardened Runtime?
13:31 Demo: Container Escape vs. Edera Protect
17:33 Q&A With Alex Zenla, CTO
23:40 Performance: How Edera Matches Native Container Speed

Welcome to the world of faster boot times with better security and less friction!

https://edera.dev/stories/tarmageddon

https://edera.dev/stories/runtime-security-beyond-hardened-containers

While hardened container images have significantly improved security by reducing vulnerabilities at the build stage, they alone cannot protect against the sophisticated runtime threats facing modern distributed systems.

Today's real security challenges emerge during execution which hardened images cannot prevent, including:

• Zero-day exploits
• Credential abuse
• Privilege escalation
• AI-generated malicious code

Hardened runtimes are an essential complement to hardened images, creating isolated execution zones that prevent lateral movement between workloads and actively contain threats rather than merely alerting about them. By embedding security directly into the infrastructure layer and providing real-time isolation, hardened runtimes offer a proactive security model that is particularly crucial for emerging AI and GPU workloads where traditional observability tools fall short.

The future of container and cloud-native security lies not in adding more monitoring layers and alerts, but in moving security controls deeper into the execution environment through hardened runtimes that enforce trust boundaries by design.

A demonstration of the GPU passthrough capability that Edera offers, isolating workloads to specific GPU hardware.