✓ Human-authored analysis; AI used for formatting and proofreading.
OWASP recently published the Subtractive Security project, and it names something the industry has been doing backwards for twenty years.
The default approach to security is additive. Add a scanner. Add a SIEM. Add an EDR. Add a CSPM. Each tool watches more things. Each tool generates more alerts. The budget goes up, the dashboard count goes up, and the question nobody answers is: did any attack paths disappear?
Matt Frenz, the project lead, borrows a hierarchy from reliability engineering and applies it to security:
Erase the attack path. Remove it architecturally so it can't exist.
Constrain the path if erasure isn't possible. Restrict it so exploitation requires more conditions.
Monitor only what can't be erased or constrained. Detect what you couldn't prevent.
The hierarchy is a priority order. Erasure is better than constraint. Constraint is better than monitoring. The industry inverts this: most budget goes to monitoring, some to constraining, almost none to erasure.
Monitoring an attack path that could be deleted is paying to watch a fire you could have prevented.
The problem with the additive model
Every monitoring tool you add to an environment that still has erasable paths creates the same dynamic: more alerts about problems that shouldn't exist.
An IAM role with AmazonEC2FullAccess attached to a Lambda function generates GuardDuty findings when that Lambda makes API calls it shouldn't. The monitoring works. The alert fires. An analyst investigates. They determine it's a misconfiguration, not an attack. The role gets noted for remediation. It sits in the backlog for weeks.
The subtractive approach: scope the role to the specific actions on the specific resources the function needs. The overprivileged path is erased. The GuardDuty finding stops firing. The analyst never sees it. The backlog doesn't grow. The signal-to-noise ratio of every other monitoring tool improves because there's one less thing to watch.
This is Frenz's point. Every path you erase from the configuration improves the effectiveness of every monitoring tool downstream. Erasure doesn't compete with monitoring. It makes monitoring work better.
Erasure in practice
An erasable path is a configuration property that creates attacker optionality and can be changed. In AWS, these are specific and concrete:
A security group with 0.0.0.0/0 egress. An attacker who compromises a workload behind this group can reach any destination on the internet. Scope the egress to what the workload needs. Path erased.
An IAM role with a wildcard action (s3:*) on a wildcard resource (*). Any credential that assumes this role has full S3 access. Scope to the specific buckets and actions required. Path erased.
An unused access key on an IAM user with admin permissions. A credential that works but nobody uses. Delete the key. Path erased.
An EKS node group allowing IMDSv1 with hop limit > 1. Pods on the node can reach the instance metadata service and steal the node's IAM credentials. Enforce IMDSv2 and set hop limit to 1. Path erased.
Each of these is a binary property. The path exists or it doesn't. It's verifiable from a configuration snapshot. No runtime data, behavioral analysis or LLM inference needed. A predicate evaluates to true or false.
Compound paths are higher-value erasures
The subtractive framing becomes most powerful when applied to compound paths. Attack chains that exist only in the composition of individually survivable configurations.
Consider: a Bedrock agent role grants broad lambda:InvokeFunction on Resource: *. Separately, that agent references a Lambda function that no longer exists (a ghost ARN). Separately, the agent role has overbroad S3 write access.
Each configuration is individually common. Together they create a data exfiltration path: prompt control gives the mechanism, the ghost ARN gives the exploitation vector, S3 gives the destination.
The subtractive insight: erasing any one leg erases the entire compound path. Scope the Lambda invoke to specific function ARNs. This erases the compound path. Delete the ghost reference. This erases the compound path. Scope the S3 write. This erases the compound path.
One configuration change, one erasure, multiple TTPs removed. That's the prioritization logic Frenz describes: "path erasure A eliminates 5 TTPs across 1000 assets... readily apparent that action A will result in a greater reduction in attacker optionality."
A monitoring tool that detects the agent making an unusual Lambda call is operating at level 3 of the hierarchy. It's watching a fire. The compound path erasure prevents the fire. Both are useful. One is structurally better.
Path Erasure Rate is the metric executives need
Frenz introduces Path Erasure Rate: paths erased divided by paths eligible for erasure. It's binary, clear, and trends in one direction.
This answers the executive question that the industry has been struggling with for decades: "how do I measure security progress?" Not compliance percentage, alert closure rate or MTTR. Paths erased.
A tool that finds 34 erasable paths in an IAM configuration gives you PER = 0/34. When the team scopes the first overprivileged role, PER = 1/34. When all 34 are resolved, PER = 34/34 = 1.0.
The number goes up. It never comes back down for the same path. Every increment structurally reduces the attack surface, deterministically.
For compound paths, the math is even better. Erasing one leg of a five-leg chain removes one finding but eliminates the entire chain. The PER increment is 1, but the attacker optionality reduction is the full compound path. This is the only metric where a smaller action produces a larger effect.
The hierarchy explains the market's blind spot
Most of the cybersecurity industry's revenue comes from monitoring. EDR, SIEM, NDR, XDR, SOAR. These are all level-3 tools. They detect, alert, investigate and respond. They operate after the path has been traversed.
Level-1 and level-2 tools that erase and constrain paths represent a tiny fraction of the market. Infrastructure-as-code scanners, CSPM tools, and configuration verifiers operate here, but they're treated as compliance tools rather than security tools. "Check the box" rather than "erase the path."
Frenz's hierarchy explains why the industry has 11,000 alerts per day and 40% of them go uninvestigated: the paths that produce those alerts were never erased. The monitoring is correct. The architecture is wrong.
The subtractive approach doesn't eliminate monitoring. It reduces the load on monitoring to the paths that genuinely can't be erased. The ones where detection is the right answer because prevention isn't possible. The remaining alerts are the ones that matter, because every erasable path has already been removed.
What this changes
The OWASP project number makes this a reference, not an opinion. When a practitioner argues that scoping an IAM role is more valuable than adding another SIEM rule, they can now cite a framework with a hierarchy, a metric, and an OWASP project backing it.
The industry's default question has been "what should we monitor?" The subtractive question is "what should we delete?"
The tools that answer the second question, identify erasable paths, prioritize compound erasures, and measure PER trending toward zero are the ones operating at the top of the hierarchy. Everything else is watching.
Stave is an open-source cloud configuration verifier. Each finding names an erasable path. Each chain finding names a compound path where erasing one leg eliminates the entire chain. No credentials required.
Top comments (0)