What If Every Day Is a Zero Day? Building Infrastructure That Assumes Breach

In 2023, Google's Threat Analysis Group tracked 97 zero-day vulnerabilities exploited in the wild. In 2024, the number was higher. In 2025, higher still. By 2026, the question isn't whether your infrastructure will face a zero-day this quarter — it's whether you'll face one this week.

The traditional security model treats zero-days as extraordinary events. You patch known vulnerabilities, maintain a WAF, run periodic pen tests, and hope that the window between disclosure and patch is short enough that attackers don't find you first. This model is breaking. The window is shrinking to hours. The attack surface is expanding with every container, every API, every AI model endpoint you deploy.

What if you stopped treating zero-days as exceptions? What if you designed your infrastructure on the assumption that an unknown vulnerability exists in your stack right now — today — and an attacker already knows about it? What would you build differently?

This article describes that architecture. Not theoretically — practically, for regulated enterprises running Kubernetes-based workloads in production.

The Assume-Breach Mindset

The "assume breach" principle inverts the traditional security model. Instead of building walls to keep attackers out, you design systems that limit damage when attackers are already in. Every architectural decision passes through a single filter: "If this component is compromised right now, what's the blast radius?"

This isn't paranoia — it's engineering discipline. And for regulated enterprises under DORA, NIS2, and the CRA, it's increasingly a compliance requirement. Regulators don't ask "are you secure?" They ask "what happens when security fails?" Your architecture needs to answer that question convincingly.

Layer 1: Immutable Infrastructure

The first principle of zero-day-resilient infrastructure: nothing should be mutable in production.

• Read-only container filesystems: Every container runs with readOnlyRootFilesystem: true. If an attacker exploits a vulnerability in your application, they can't write a backdoor, drop a cryptominer, or modify application binaries. Temporary data goes to emptyDir volumes that are destroyed with the pod
• Immutable container images: Images are built once, signed with cosign/Sigstore, and never modified after build. Production pulls from a registry that enforces signature verification. No :latest tags — every deployment references a digest
• No SSH, no exec: Production pods don't have SSH daemons, shell access, or package managers. kubectl exec is disabled via RBAC or admission policy for production namespaces. If you need to debug, you debug a replica in a staging environment — not in production
• Ephemeral nodes: Kubernetes nodes are replaced, not patched. Node OS images are rebuilt weekly (or on-demand for critical patches) and nodes are rolled via kubectl drain + replacement. A compromised node is destroyed, not cleaned

Why This Helps Against Zero-Days

Most exploits require writing to the filesystem — dropping a payload, modifying a configuration, establishing persistence. Immutable infrastructure eliminates these post-exploitation steps. The attacker may achieve code execution, but they can't persist, and when the pod or node cycles, they're gone.

Layer 2: Microsegmentation and Network Policy

If everything can talk to everything, one compromised pod means your entire cluster is compromised. Microsegmentation limits lateral movement:

# Default deny all ingress and egress per namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Then explicitly allow only the traffic flows your application requires:

# Allow API service to reach database — nothing else
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-to-database
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-service
    ports:
    - port: 5432

• Default deny everything: Every namespace starts with deny-all ingress and egress. Traffic is explicitly allowed, not implicitly permitted
• DNS egress control: Restrict egress DNS to your internal DNS service. Attackers use DNS for exfiltration and C2 communication — if your pods can only resolve internal names, that channel is closed
• Service mesh mTLS: All service-to-service communication is mutually authenticated and encrypted via Istio, Linkerd, or Cilium. Even if an attacker achieves code execution in a pod, they can't impersonate another service without its certificate
• Egress gateways: All outbound internet traffic flows through an egress gateway with URL-level filtering. If a compromised pod tries to reach an unknown external endpoint, the connection is blocked and logged

Layer 3: Runtime Security and Anomaly Detection

Zero-day exploits, by definition, aren't in your vulnerability scanner's database. Signature-based detection fails. You need behavioural detection — monitoring what your workloads actually do and alerting on anomalies:

eBPF-Based Runtime Monitoring

Tools like Falco, Tetragon, and KubeArmor use eBPF to observe system calls at the kernel level — without modifying your containers:

• Unexpected process execution: Your API container should only run your application binary. If bash, curl, wget, or python executes inside it, that's an anomaly worth investigating immediately
• File access patterns: Your application reads config from /etc/app/config.yaml and writes logs to /var/log. If it reads /etc/shadow or writes to /tmp, something is wrong
• Network connections: Your application connects to the database on port 5432 and the cache on port 6379. If it opens a connection to an external IP on port 443 that it has never contacted before, that's potential exfiltration
• Privilege escalation: Any attempt to change capabilities, load kernel modules, or access sensitive syscalls (ptrace, mount, unshare) triggers an immediate alert

# Falco rule: detect shell execution in production containers
- rule: Shell Spawned in Production Container
  desc: Detect shell processes in production namespace containers
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh, dash, csh) and
    k8s.ns.name = "production"
  output: >
    Shell spawned in production container
    (user=%user.name container=%container.name
    image=%container.image.repository
    namespace=%k8s.ns.name pod=%k8s.pod.name
    command=%proc.cmdline)
  priority: CRITICAL

Build Behavioural Profiles

The most effective runtime security starts with learning what "normal" looks like for each workload:

1. Observation phase: Run Tetragon or Falco in observe mode for 2 weeks, recording all system calls, network connections, and file access for each pod
2. Profile generation: Generate a baseline profile: "this container normally makes these syscalls, connects to these endpoints, reads these files"
3. Enforcement phase: Switch to enforcement mode — any deviation from the profile triggers an alert or blocks the action

When a zero-day exploit fires inside your container, it will almost certainly deviate from the established behavioural profile — because the exploit is doing something your application was never designed to do.

Layer 4: Least-Privilege Everything

Every permission granted is a capability an attacker inherits when they compromise a component:

• Pod Security Standards: Enforce restricted profile on all production namespaces. No privileged containers, no host network, no host PID, no capability additions beyond the minimum
• RBAC minimisation: No cluster-admin for humans. Service accounts get the minimum RBAC verbs on the minimum resources in the minimum namespaces. Audit RBAC quarterly — permissions accumulate like technical debt
• Secret scoping: Secrets are mounted only to the pods that need them, in the namespaces that need them. Use an external secrets manager (Vault, AWS Secrets Manager) with dynamic, short-lived credentials. A compromised pod in namespace A cannot access secrets in namespace B
• Cloud IAM: Workload identity (GKE), IAM Roles for Service Accounts (EKS), or Workload Identity Federation (Azure) — pods authenticate to cloud APIs with scoped, temporary credentials. No long-lived cloud API keys in Kubernetes secrets

Layer 5: Rapid Recovery

Assume-breach means assuming you'll need to recover. The speed of recovery determines the business impact:

• GitOps everything: Your entire cluster state is declared in Git. If a namespace is compromised, delete it and let ArgoCD or Flux recreate it from the last known-good commit. Recovery time: minutes, not hours
• Backup isolation: Backups are stored in a separate account, separate cloud provider, or air-gapped storage. If your primary cluster is ransomed, backups are untouchable
• Blast radius testing: Regularly test: "What happens if we lose namespace X? What happens if we lose this entire node pool? What happens if we lose the whole cluster?" Answers should be documented, with tested recovery procedures
• Chaos engineering: Use Litmus, Chaos Mesh, or Gremlin to regularly kill pods, drain nodes, and inject network failures. Your infrastructure should handle these gracefully — because real attacks cause the same disruptions

Layer 6: Supply Chain Hardening

Most zero-days arrive through your supply chain, not through direct exploitation of your code:

• SBOM + continuous scanning: Every shipped artifact has a machine-readable SBOM, continuously scanned against vulnerability databases. See our SBOM automation guide
• Admission control: Use Kyverno or OPA/Gatekeeper to block container images that aren't signed, don't have an SBOM, or have critical unpatched vulnerabilities. If it didn't pass your pipeline, it doesn't run in your cluster
• Build provenance: SLSA Level 3 minimum — hermetic builds, signed provenance attestations, verified builder identity. If you can't prove how an artifact was built, don't trust it
• Dependency pinning: Pin everything to exact versions and digests. No floating version ranges in production. Renovate or Dependabot handles updates — humans review before merging

The Cost of Assuming Breach

This architecture is more expensive to build than traditional perimeter-based security. Read-only filesystems require application changes. Network policies require mapping every traffic flow. Runtime monitoring requires tuning to avoid alert fatigue. Immutable nodes require automation that many teams don't have.

The alternative is more expensive. The average cost of a data breach in the EU is €4.3 million. For financial services, it's €5.9 million. A single ransomware incident affecting regulated data can trigger GDPR fines, DORA sanctions, customer loss, and reputational damage that compounds for years.

Assume-breach architecture is insurance that also makes you faster, more reliable, and more auditable. It's not just security — it's operational maturity.

Getting Started

You don't implement all six layers at once. Prioritise by impact:

1. Week 1–2: Default-deny network policies in production namespaces. Immediate blast radius reduction
2. Week 3–4: Read-only container filesystems + Pod Security Standards enforcement. Eliminates persistence
3. Month 2: Runtime monitoring with Falco or Tetragon in observe mode. Start building behavioural profiles
4. Month 3: SBOM generation + admission control for image signing. Supply chain hardening
5. Month 4–6: GitOps recovery automation, backup isolation verification, chaos engineering
6. Ongoing: RBAC audits, secret rotation, behavioural profile tuning, tabletop exercises

For the Kubernetes security patterns that underpin this architecture — Pod Security Standards, RBAC, NetworkPolicies, and admission control — see Kubernetes Recipes.

What Open Empower Delivers

We help regulated enterprises build assume-breach infrastructure on Kubernetes:

• Security architecture review: Assess your current blast radius and identify the highest-impact hardening opportunities
• Network policy design: Map your application traffic flows and implement microsegmentation without breaking services
• Runtime monitoring: Deploy and tune Falco/Tetragon with workload-specific behavioural profiles
• Supply chain hardening: SBOM automation, image signing, admission control, and build provenance
• Recovery automation: GitOps-based disaster recovery with tested runbooks and blast radius documentation
• Compliance mapping: Every control mapped to DORA, NIS2, CRA, and ISO 27001 requirements

Every day might be a zero day. The only question is whether your infrastructure was designed for that reality. Let's build it.