OWASP Turns to "Security by Removal" in a Bid to Cut Off Attack Paths
A new OWASP project reframes defense around architecture: reduce the routes attackers can use, rather than relying mainly on alarms after the fact.
Cybersecurity teams often add more tools when risk rises: more alerts, more dashboards, more sensors. OWASP’s new Subtractive Security Top 10 pushes in the opposite direction. The idea is simple but demanding - if a system has fewer reachable failure states, attackers have fewer places to start.
The initiative is led by Christopher Frenz and is described as a security engineering effort focused on removing architectural conditions that make cyberattacks possible. That matters because many real-world intrusions do not begin with exotic malware. They begin with unnecessary exposure, weak trust boundaries, or privileged pathways that should not have existed in the first place.
Fast Facts
- OWASP has launched a project called Subtractive Security Top 10.
- Christopher Frenz is identified as the project lead.
- The project emphasizes removing attack-enabling architecture, not just adding detection.
- The core aim is to reduce cyber risk by eliminating attack paths where possible.
- The approach aligns with threat modeling and secure-by-design thinking.
Why subtraction is getting attention
From a defensive perspective, this is a useful correction. Detection still matters, but it is not the same as prevention. Logging can tell you that an intrusion is underway; it cannot erase the bad design choice that made the intrusion feasible. A subtractive approach asks teams to identify what can be removed, collapsed, or hardened before an attacker ever touches production.
That maps closely to established secure-by-design practice: reduce attack surface, limit privilege, and define clear trust zones early in the lifecycle. It also fits threat modeling, where defenders trace possible routes from entry points to high-value assets and decide which routes should be blocked outright. In that sense, an "attack path" is not a metaphor. It is a real sequence of trust decisions, dependencies, and permissions that can be mapped and broken.
MITRE’s attack-path analysis work is one example of how that mapping can be done in a more structured way. The value is practical: one well-placed architectural change can sometimes disrupt several routes at once, especially in complex systems where many services share identity, network, or privilege assumptions.
At the time of writing, public information has not fully established the project’s full methodology, scoring model, or long-term scope. The available information supports a risk analysis, not a definitive prediction that every deployment will become safer simply by adopting the label.
What defenders should take from it
The broader lesson is not to abandon monitoring. It is to stop treating monitoring as a substitute for architecture. Security teams can get more value by asking a harder question: which components, trust relationships, and access edges can be removed without breaking the business?
That question is uncomfortable because it often exposes design debt. But it also points to more durable protection. Fewer exposed paths usually means fewer places for credential abuse, lateral movement, and privilege escalation to begin. In a system built that way, the attacker’s job becomes harder before the first alert ever fires.
Conclusion
OWASP’s new project is a reminder that mature security is not only about seeing more. It is about building less of what attackers can use. The strongest defense is not always a louder alarm - sometimes it is a door that was never installed.
TECHCROOK
Hardware security key: A simple way to reduce reliance on passwords and add stronger login protection for email, admin consoles, code repositories, and other sensitive accounts. For teams focused on attack-path reduction, it is one practical step that can help narrow common routes used for account takeover.
WIKICROOK
- Attack path: A route an attacker can use to move from an initial foothold to a target asset.
- Threat modeling: A design process for identifying threats, likely abuse cases, and mitigations before deployment.
- Secure-by-design: A security approach that builds protections into architecture instead of adding them later.
- Attack surface: The total set of exposed components, interfaces, and trust relationships that can be targeted.
- Least privilege: A principle that gives users and services only the access they need to perform their tasks.
