Zero-Trust Runtime Security: Container Runtime Attestation

By Kai Aizen — SnailSploit

In early 2019, the runC vulnerability (CVE-2019–5736) demonstrated a harsh truth: a single container escape can give an attacker root on the host. Once the host falls, the attacker can compromise other workloads, poison the container runtime, and pivot to the control plane.

Since then, we’ve seen Dirty Pipe (CVE-2022–0847), Sysdig Falco bypasses, and privilege escalation flaws in Kubernetes like CVE-2021–25741. These events keep reminding us: perimeter defenses — image scanning, firewall rules, admission controllers — protect the starting line, but offer no guarantee once a container is running.

Zero-Trust Runtime Security changes the equation: it assumes no container or node is inherently trustworthy and forces them to continuously prove their integrity while in operation. The primary mechanism to do this? Runtime attestation.

What is Runtime Attestation?

Runtime attestation is the practice of measuring a live container’s state — from binary hashes to control-flow integrity and syscall patterns — and comparing those measurements to an expected baseline.

If the live measurements diverge beyond defined thresholds, the container is flagged, quarantined, or terminated automatically.

It’s a familiar principle in other security domains:

• Secure Boot measures firmware and OS components before boot.
• Trusted Execution Environments (TEEs) prove enclave integrity before sharing secrets.

Here, we apply it to dynamic, constantly changing workloads.

In the AATMF, runtime attestation is part of Context Verification — a defensive strategy that keeps the execution environment from drifting into attacker-controlled states.

How Runtime Attestation Works Under the Hood

Measurement Collection
Attestation agents — often running at the kernel layer — collect runtime telemetry:

• Static file hashes (binaries, config files, libraries)
• Process inventory and parent-child relationships
• System call sequences and frequency distributions
• Open network sockets and flows

Baseline Definition
A baseline is your definition of “normal.” It might come from:

• Pre-production golden images
• Output from vulnerability scanners like Trivy

Observed behavior during a burn-in period in staging
This baseline is hashed, signed, and stored in an immutable attestation DB.

Comparison & Policy Enforcement
Live telemetry is compared against the baseline using a policy engine

• Policies can be strict (“no deviations allowed”) or adaptive (“allow expected updates but log changes”).

For example:

“Nginx may only execute /usr/sbin/nginx and its child processes.”
“Redis cannot open outbound TCP connections except to whitelisted services.”

Response Actions

• Alert security teams
• Quarantine or pause the container
• Terminate the process tree and block restarts
• Trigger orchestration workflows (cordon node, rotate secrets)

Implementing Zero-Trust in Container Ecosystems

Step 1: Establish a Baseline

• Scan every container image pre-deploy using tools like Trivy, Grype, or Kuberoast.
• Record expected process trees, file checksums, and network profiles
• Store these in a signed, versioned repository so drift can be detected over time.

Step 2: Deploy Attestation Agents

• Use eBPF-based agents (Tetragon, Cilium) to capture runtime activity with minimal performance impact.
• Agents should sign measurements with a node-specific key so they can’t be spoofed.

Step 3: Centralized Policy Engine

• Aggregate measurements in a verification service that enforces rules.
• Rules can be declarative (“containers must not spawn a shell”) or behavioral (“alert on new syscall patterns”).

Step 4: Continuous Verification

• Re-attest periodically — every few seconds for critical workloads.
• Trigger immediate re-attestation on events like:
• Container restart
• Namespace privilege change
• New binary execution outside baseline

Real-World Attacks That Attestation Could Have Caught

• CVE-2019–5736 runC overwrite
  The attacker overwrote /proc/self/exe with malicious code. Attestation could flag a binary hash change in milliseconds
• Dirty Pipe (CVE-2022–0847)
  Kernel exploit allowing arbitrary file overwrite. Attestation could detect unexpected writes to protected binaries or config.
• K8s privilege escalation (CVE-2021–25741)
  Attestation policy could block unauthorized mount operations outside baseline scope.
• Cryptominer dropper
  Attestation could detect the introduction of miner binaries and anomalous outbound connections.

Beyond Detection: Automated Response

Zero-trust isn’t just about finding bad states — it’s about eradicating them fast.

• Containment: Quarantine the container or isolate its network namespace.
• Host Remediation: Cordon and drain affected nodes; block scheduling until re-attested clean.
• Secret Rotation: Invalidate and rotate any tokens/keys mounted in the workload.
• Forensics: Automatically snapshot file system and memory for later analysis.
• SIEM/SOAR Integration: Push events into Splunk, Sentinel, or Elastic for correlation.

Integrating with AATMF & Broader Threat Models

In your adversarial model, runtime attestation directly counters:

• Legitimacy Masking — malicious processes hiding in legitimate workloads.
• Context Accumulation — persistence by altering container state gradually.
• System Role Injection — modifying runtime roles or permissions outside expected behavior.

When mapped into your AATMF taxonomy, attestation is a verification control that turns runtime drift into a detectable, actionable event — even against zero-day container escapes.

Building It Into Your Security Culture

1. Shift-Left Attestation — Generate baselines during CI/CD, not after deployment.
2. Make It Immutable — Sign and store baselines and measurement logs in WORM storage.
3. Train Response Playbooks — Simulate violations and run full blue-team responses.
4. Measure Performance Impact — Tune collection intervals to balance security and performance.

Conclusion

Zero-trust runtime security is not optional in modern containerized infrastructure. Perimeter checks tell you what you started — attestation tells you what you’re running right now.

By continuously measuring, verifying, and enforcing runtime state, you can catch container escapes, supply chain compromises, and privilege escalations before they metastasize into full-blown breaches.

The runtime is your battlefield. Attestation is your constant guard.

About the Author

Kai Aizen is the creator of the Adversarial AI Threat Modeling Framework (AATMF) and a red teamer focused on adversarial testing for AI and cloud-native systems. At SnailSploit, Kai designs controlled offensive scenarios — from AI prompt injections to container escape drills — to expose risks before attackers do.

Read More in This Series:

• Revisiting the MCP Protocol — Securing the “USB-C of AI” against registry poisoning and tool drift.
• The Custom-Instruction Backdoor — Persistence as an attack vector.
• GPT-01 & Context Inheritance — Cross-model exploit persistence.