There is a comfortable lie that has taken root in information security domain.
It goes like this: "We have invested in the best tools. We have CSPM. We have CNAPP. We have ASM, ASPM, EDR, SIEM. We are covered."
Boards believe it. CISOs present it. Security budgets are built around it.
And while everyone is looking at dashboards full of green, two things are quietly true:
One — attackers are not trying to beat your tools. They are looking for what your tools were never designed to see.
Two — the most dangerous gaps in your security posture today are not gaps in your tooling budget. They are gaps in visibility, knowledge, and the fundamental understanding of what your own systems are supposed to do — and whether they actually do it.
No tool solves that. Only people do.
The Tool Trap
The security industry has industrialized the idea that protection is a purchasing decision.
Spend enough. Deploy enough. Integrate enough. And you will be secure.
This thinking has produced something genuinely useful — a generation of powerful tools that automate detection, surface known misconfigurations, and reduce the manual burden on security teams. CSPM catches publicly exposed storage buckets. EDR detects malware. SIEM correlates suspicious behavior across logs. These tools matter and they work — within the boundaries of what they were designed to see.
But there is a boundary. And most organizations have no idea where it is.
The boundary is this: every security tool operates on known patterns, defined rules, and observable configuration state. None of them operate on context. None of them understand intent.
And intent — what a system was supposed to do, how it was supposed to be accessed, what data it was never supposed to expose — is exactly where the most dangerous vulnerabilities live today.
The Dangerous Gap Nobody Has Named Yet
Security practitioners are familiar with the concept of IoM — Indicator of Misconfiguration. A wrong setting. An overpermissioned role. A flag that flipped. Tools like CSPM, ASPM, ASM and CNAPP are built to catch these — comparing configuration state against known benchmarks, compliance frameworks, and best practice rules.
But there is a sub-category of IoM that sits entirely above what any tool can detect. It has not been cleanly named or articulated in the industry — which, from my point of view, can be called an 'Architectural Intent Gap'.
Architectural Intent Gap
The configuration is technically correct. The architecture is contextually wrong.
This is not a misconfigured setting. This is a system that was built in a way that violates its own purpose — and passes every automated check because no automated check knows what the system's purpose was.
No CSPM rule catches it. No CNAPP policy flags it. No ASM scanner surfaces it. Because catching it requires answering one question that no tool can answer:
"What was this system supposed to do — and does the way it is built actually enforce that?"
That knowledge does not live in configuration files. It does not live in cloud metadata. It lives in human heads, architecture diagrams, design decisions made under deadline pressure, and assumptions that seemed reasonable at the time.
When those assumptions are never formally validated against the actual implementation, the gap between intent and reality becomes an attack surface. Silent. Invisible to every tool in your stack. And entirely real.
The two examples below are not theoretical. They happened. And they were not caught by any security tool.
Real Example 1 — The Internal Application That Was Publicly Reachable by Anyone With a VPN
An enterprise application — classified as internal, meant to be accessible only by employees — was deployed on AWS behind a public Application Load Balancer.
To restrict access, the security team whitelisted the company's VPN gateway IP addresses on the ALB security group. The logic was straightforward: employees connect through corporate VPN, VPN traffic comes from known gateway IPs, only those IPs are allowed through. Internal access enforced.
Every tool in the environment scanned this setup. CSPM returned green. CNAPP returned green. The security group had restricted inbound rules. The ALB had access controls. From a configuration policy standpoint — against every benchmark, every CIS rule, every cloud provider best practice — nothing was wrong.
But there was a critical flaw hiding inside a correct-looking configuration.
The VPN gateway IPs belonged to a commercial VPN provider — shared infrastructure. The same IP ranges were used by thousands of other organizations and individuals who were customers of the same provider. Any person anywhere in the world, using the same VPN service, could originate traffic from those whitelisted IP addresses — and land directly on the application's login page.
An application meant to be strictly internal was, in practice, reachable by a significant portion of the global internet.
No tool flagged it. Because no tool knew the application was supposed to be internal.
The CSPM rule "ALB should not be public-facing for internal applications" does not exist in any ruleset — because rulesets do not contain the word "internal" in relation to this specific workload. That classification existed in someone's head and in an architecture decision that was never formally validated against the implementation.
The correct architecture — routing through a VPC with an internal load balancer, using AWS PrivateLink or Amazon VPC for limited employee access — would have enforced the intent. The implemented architecture looked right, passed every check, and violated the intent entirely.
Architectural Intent Gap: The configuration was technically correct. The architecture was contextually wrong.
Real Example 2 — The QA API That Was Public, Documented, and Completely Open to Abuse
An internal QA team used an API for application testing. The API had a full Swagger interface — comprehensive documentation of every endpoint, every parameter, every expected input and output. It was designed to be internal. Traffic was supposed to flow through the company intranet.
Somewhere in deployment, the routing shifted. The API was reachable on the public internet. The Swagger documentation — a complete self-service map of the internal API surface — was fully accessible to anyone who found the URL.
ASM vendor have discovered the endpoint and added it to an asset inventory, but they have flagged the unauthenticated Swagger exposure as a medium-severity finding — because exposed API documentation is a known and medium risk pattern.
But they would not flag it as a critical architectural misconfiguration. They had no context that this API was internal-only. They had no visibility into the intended traffic path. They see what is exposed — not what was never supposed to be.
That alone was serious. But it was not the whole problem.
During a pre-launch security review, product / application security team conducted a threat modeling session with the developers. Not an automated scan. Not a tool. A conversation — where a security person sat with the development team and asked questions about how the system worked, who used it, and what could go wrong.
One question surfaced something nobody had considered:
"Is there any rate limiting on this API?"
There was none. No rate limiting on any endpoint. Whatsoever.
A publicly reachable API, fully documented via Swagger, with no rate limiting — meant that any attacker who found it could automate requests indefinitely. Credential stuffing against every authentication endpoint. Systematic enumeration of every endpoint in the Swagger spec. Scraping, probing, fuzzing — all of it, uncapped, with a complete documentation guide provided free of charge.
No scanner caught the missing rate limiting. No ASPM policy flagged it. No tool in the stack surfaced it as a risk. A DAST would have caught that, but it was not there in the security tech-stack.
It was found because a human asked a basic question in the right context, at the right time, before the application launched.
Architectural Intent Gap: Two gaps in one system. One caught through architecture review, another caught through a single question in a threat modeling session. Neither caught by any tool, both caught by humans having correct mindset.
What Tools Cannot See — And Why That Matters More Than Your Tool Budget
Let us be precise about what the current generation of security tooling is actually doing — because this is not a criticism of the tools. It is a description of their design boundary.
| Tool | What It Sees | What It Cannot See |
|---|---|---|
| CSPM | Configuration state vs. known benchmarks | Whether the architecture matches the application's intended access model |
| CNAPP | Cloud workload risks, known misconfiguration patterns | Architectural decisions that are contextually wrong but technically valid |
| ASM / ASPM | What is exposed and reachable externally | Whether a specific exposure violates an internal classification or intended traffic path |
| EDR / CWPP | Malicious behavior on endpoints | Architectural flaws that allow legitimate access to the wrong people |
| SIEM | Anomalous patterns in log data | Misuse that looks like normal traffic because the architecture permits it |
Every tool in this list is doing exactly what it was designed to do. The gap is not in the tools. The gap is in the belief that these tools — collectively — cover everything worth covering.
They do not. And the gap they leave is not a small one.
The Organizational Belief That Is Getting Companies Breached
Most organizations operate with an implicit security investment hierarchy that looks something like this:
Tools → Processes → People
Spend on tools first. Build process only when and where it's needed. Hire people to just to deploy and manage those tools and process.
In practice, tools consume the vast majority of security budgets. Processes are underdocumented and inconsistently followed. And the human expertise that should be asking "but does this architecture actually enforce what we intend?" is either absent, overloaded with alert triage, or not involved until after something is already in production.
The result is a security program that is very good at detecting known threats — and almost entirely blind to the class of risk that lives in the gap between architectural intent and implementation reality.
This is not a money problem. Most of the organizations carrying these gaps are not under-resourced. They have invested in tooling and compliance that any CISO would be proud to present to a board. The problem is not budget. The problem is in the budget allocation. Most portion of budget goes to tools, and to the belief that tools are sufficient. That means the human processes — threat modeling, architecture review, contextual security validation — were treated as optional or secondary (In some cases, they don't even know such things exist).
They are not optional. For the risk category described in this post, they are the only control that works.
IoC and IoA Are Not Enough — And Here Is the Risk Nobody Is Talking About
The security industry's dominant investment thesis is built around two threat signals:
IoC — Indicator of Compromise — Something bad already happened. Find the evidence.
IoA — Indicator of Attack — Something bad is happening now. Detect the behavior.
Both are reactive by nature. They tell you about threats that are already in motion. And the entire tooling ecosystem — SIEM, EDR, threat intel, behavioral analytics — is built to surface these signals faster and more accurately.
This investment is not wasted. But it creates a dangerous organizational blind spot.
When your entire security investment is oriented around detecting active threats, you are implicitly accepting or assuming that the architectural foundation your systems are built on is sound and strong — that the guardrails are in place, that access controls reflect intent, that systems classified as internal are actually internal.
For organizations carrying Architectural Intent Gaps, and I believe there are many, this assumption based investment is fundamentally flawed. And no amount of IoC and IoA tooling will surface that wrongness — because an attacker exploiting an Architectural Intent Gap does not look like an attacker. They look like a legitimate user accessing a system that was inadvertently made accessible to them.
No alert fires. No behavioral anomaly surfaces. No IoC is generated. The SIEM stays quiet. The EDR sees nothing.
The exposure is invisible to every reactive control in the stack.
What Actually Catches Architectural Intent Gaps
There are no shortcuts here. The controls that catch this category of risk are human-driven, process-dependent, and require security expertise that understands both architecture and adversarial thinking simultaneously.
Threat Modeling — Before Deployment, Not After
The rate limiting gap in Example 2 was caught in a threat modeling session. Not a sophisticated one — a conversation where someone asked basic questions about how the system worked and what an attacker could do with what was exposed. Threat modeling forces the question: who should and should not be able to reach this system, and what happens if someone who shouldn't be able to reach it does? It is the single most effective control for Architectural Intent Gaps — and one of the most consistently skipped steps in application security.
Architecture Review as a Security Gate
Any system with an internal classification should require an architecture review that explicitly validates the access model, traffic path, and exposure surface before deployment. Not a tool scan. A human review that asks: does this architecture actually enforce the intent? The ALB example would have been caught here — the moment someone asked whether a public ALB with shared VPN IP whitelisting genuinely enforces internal-only access.
Application Classification That Drives Architecture Decisions
If an application is classified as internal, that classification needs to follow every infrastructure decision made around it — load balancer type, DNS configuration, traffic routing, network architecture. When classification is documented and enforced as an architectural constraint — not just a label — intent gaps shrink significantly.
Security Involvement Before Code Is Written
Both examples share a common condition: The security review happened a bit later than expected, fortunately, not too late. The architectural decisions that created the gaps were made earlier — under deadline pressure, or by teams focused on making systems work, or by not enforcing security intent. The earlier security expertise is involved in design decisions, the cheaper and easier it is to close these gaps. After deployment, the cost multiplies.
Asking Simple Questions Consistently
The rate limiting gap was found by asking one basic question. The ALB gap was found by someone thinking through what the VPN IP whitelist actually meant in practice. These are not exotic security techniques. They are what happens when a security-minded person who understands both the system and the threat landscape sits down and thinks critically and fundamentally about what was built.
That is not a tool. That is a human with the right knowledge, the right context, and the time to actually use both.
The Investment Rebalancing That Needs to Happen
This is not an argument against security tools. It is an argument against the belief that security tools are sufficient.
The organizations that will be most resilient are not the ones with the largest tool budgets. They are the ones that treat people and process as first-class security investments — not afterthoughts to tool deployment.
That means:
- Threat modeling as a standard part of every application development lifecycle — not an optional exercise for high-risk systems only
- Architecture review with security representation — before infrastructure is provisioned, not after it is in production
- Security expertise that spans both cloud architecture and adversarial thinking — people who can look at a system design and ask "what did the attacker just see that we didn't?"
- Process that enforces application classification through infrastructure decisions — so that "internal" is an architectural constraint, not just a documentation label
- Investment in security knowledge, not just security tooling — because the gaps being exploited today are not gaps in detection capability, they are gaps in the understanding of what can go wrong
Closing
The two examples in this post did not happen because the organizations involved lacked security tools. They had them. The tools were running. The tools returned results. The tools found nothing wrong — basically nothing was wrong by the standards the tools were designed to measure against.
What was missing was not a tool. It was a person asking the right question at the right time with enough context to understand what the answer meant.
"Is this application actually only accessible to our employees — or just to anyone using the same VPN provider?"
"Is there any rate limiting on this API that is now reachable from the public internet?"
Two questions. Neither requires a tool to ask. Both require a human who understands the system, understands the threat, and was given the time and the mandate to look.
Security is not a tool problem. It never was.
The most dangerous gaps in your environment right now are not the ones your tools are flagging. They are the ones your tools do not have the context to understand — and the ones nobody has thought to ask about yet.
Invest in people who ask those questions. Build processes that make asking them mandatory. And please stop mistaking a green dashboard in the name of a secure architecture.
Top comments (0)