Defense in Depth Explained: Security in the Age of AI
The Treadmill
Most security teams today are stuck on a treadmill. Automated scanners surface an overwhelming flood of vulnerabilities in their code and infrastructure. Teams scramble to patch them. New ones appear faster than old ones close. The backlog grows faster than teams can clear it.
This is the vulnerability treadmill, and it is the dominant security operating model at most organizations. It treats most flagged defects as urgent, regardless of whether an attacker could actually exploit them. It measures success by how fast you patch, not whether you are actually safer. It is exhausting, expensive, and increasingly the wrong model entirely.
There is a better model, and it has existed for decades in physical security. We just have not applied it rigorously enough to software.
The House
Imagine your software system is a house.
A single lock on the front door is a single point of failure. If the lock is picked, a window is left open, or a key is copied, the entire interior is exposed. No serious homeowner relies on one lock. They have a fence, exterior lights, a locked front door, interior door locks on sensitive rooms, a safe inside the closet, and maybe a camera watching the hallway.
This is Defense in Depth: multiple independent layers of protection, designed so that the failure of any single layer is not catastrophic. The goal is not to make the house impenetrable. Nothing is impenetrable. The goal is to make compromise so expensive, in time and effort, that most attackers move on.
The same logic applies to software. A well-defended system has four distinct layers, and each one maps cleanly onto the house:
| House component | Software equivalent | What it does |
|---|---|---|
| External perimeter | Minimal, hardened images | Reduces the size of the attack surface |
| Building materials | Compiler hardening + ASLR (stack canaries, PIE, FORTIFY_SOURCE) | Makes individual binaries expensive to exploit |
| Interior door locks | Mandatory Access Control (SELinux, AppArmor) | Confines compromised processes |
| Walls + cameras | Container isolation, Pod Security Standards, runtime monitoring | Limits how far an attacker can spread, and catches them when prevention fails |
The middle of this document walks through each layer. But first, the reason it matters more now than it did five years ago.
The AI Shift
In early 2026, Anthropic and Mozilla collaborated on what is now the clearest public demonstration of the shift. In February, Anthropic’s Claude Opus 4.6 model identified 22 security-sensitive bugs in Firefox. These were not exotic discoveries. They were human-discoverable defects, found at machine speed. Two months later, a newer model called Claude Mythos Preview found 271 additional vulnerabilities in the same codebase. Mozilla’s own CTO described the feeling as “vertigo.” Notably, Mozilla observed that none of the bugs found were beyond what an elite human researcher could have discovered. The difference was speed and scale, not capability.
The implications cascade:
Finding bugs just got cheap. Historically, discovering a previously-unknown vulnerability (a “zero-day”) required months of elite human research. That scarcity made each one valuable. AI collapses that cost toward almost zero.
Both sides have access to AI-assisted discovery. The same techniques are available to defenders and attackers. The gap between “a bug exists” and “someone notices it” is closing fast.
The reservoir is finite. Software has only so many bugs in it. As AI drains that pool at machine speed, the strategic question shifts from “how do we find more bugs faster” to “how do we make the bugs that exist not matter when they are found.”
That last shift is the whole point of Defense in Depth. The four layers below are how you make bugs not matter.
Layer 1: Shrink the Attack Surface
Most container images are bloated. These are the packaged units that modern applications ship in. They typically include shells, package managers, debugging tools, and libraries the application will never use. Every one of those components is potential attack surface.
A minimal image strips this down to only what the application actually needs to run. No shell, no package manager, no extras. Open source projects like Wolfi, Chainguard Images, and Google’s distroless make this practical.
Minimal images deliver two wins at once: fewer CVEs in the image and dramatically less scanner noise. When scanners flag a vulnerability in a tool your application never executes, that finding is technically true and operationally useless. Minimal images make that noise disappear.
Layer 2: Harden the Walls
Even after you strip the image, the code itself can be made expensive to exploit. Modern compilers and operating systems offer a set of protections that make memory-corruption bugs significantly harder to weaponize. These bugs are still the most common class of serious vulnerability:
- ASLR (Address Space Layout Randomization) is an operating system feature that randomizes the base addresses of memory regions (stack, heap, libraries) each time a program runs, so an attacker cannot reliably predict where to aim.
- Stack protection (stack canaries) is a compiler feature that detects when an attacker is trying to overwrite a function’s return address, the classic buffer overflow technique.
- FORTIFY_SOURCE is a compiler feature that adds runtime checks to common functions that have historically been exploited.
On an unhardened system, a single buffer overflow can lead to full system compromise. On a hardened system, the same bug typically requires the attacker to chain together multiple rare vulnerabilities just to bypass the protections. Most attackers will not bother. The walls do not need to be unbreakable. They need to be expensive.
Layer 3: Lock the Interior Doors
If an attacker does get code running inside a process, the next question is: what can that process do?
Mandatory Access Control systems like SELinux and AppArmor answer that question by confining every process to a specific security context by default. The web server can read its own configuration files and write its own logs. It cannot read /etc/shadow, cannot bind to arbitrary ports, cannot execute a shell. Even with full code execution inside the process, the attacker hits walls everywhere they turn.
This is the difference between “attacker compromised a process” and “attacker compromised the system.” That gap is the difference between an incident and a breach.
Layer 4: Isolate the Blast Radius
In container-based infrastructure, applications run inside containers. These are isolated units enforced by the Linux kernel. Containers share the host but cannot, by default, see each other’s files or processes.
In Kubernetes (the dominant system for orchestrating containers), the Pod Security Standards define three tiers of isolation, with the “Restricted” tier blocking the dangerous defaults. Network Policies define which connections are allowed between pods; anything not explicitly allowed is blocked. Tools like Falco watch the running system for suspicious behavior and alert when, for example, a shell appears inside a container that should not have one.
A compromise in one container, with these controls in place, has a very hard time spreading without being caught.
The Open Source Advantage
Every tool named in this primer is open source. That is not an accident.
When AI can read every line of code in a system, transparency stops being optional. A proprietary vendor sees 271 bugs as a reputational risk to hide. An open source project sees them as a roadmap. Linus’s Law (“given enough eyeballs, all bugs are shallow”) now applies with millions of virtual eyeballs reading at machine speed.
You cannot patch your way out of machine-speed discovery. The way off the treadmill is not faster patching. It is building systems where individual bugs do not matter.
That is what these four layers do. They turn “we found a bug” into “we found a bug that cannot escape this container, cannot read that file, cannot execute in this context.”
Defense in depth is not a luxury. In the age of AI, it is the minimum viable architecture.