✓ Human-authored analysis; AI used for formatting and proofreading.
You separate cloud security into silos for a good reason: operational efficiency. The DevOps engineer owns the Terraform. The developer owns the Go and the Java. The security team owns IAM. Each person secures their domain, signs off, and moves on. Every silo passes.
The attacker doesn't have silos. They have never had silos. To an attacker, your application code, your application config, your infrastructure config, and your infrastructure-as-code are one contiguous execution environment. A single surface they move across without noticing the boundaries you spent so much effort drawing. This is the Silo Fallacy. It's the largest structural advantage attackers hold over defenders in the cloud. A perception gap. You are looking at four pictures. They are looking at one.
1. The Interface Blind Spot
Defenders secure the silos. Attackers exploit the interfaces between them — and nobody owns an interface.
A textbook path:
- Application code — an SSRF vulnerability sits in the Java.
- Infrastructure config — the EC2 instance's IAM role permits access to the Instance Metadata Service.
- Application config — an environment variable points the app at a specific S3 bucket.
- Infrastructure code — that bucket was provisioned in Terraform with public access allowed, for a legacy reason everyone has agreed to live with.
Look at how this reads inside each silo. The Java developer triages the SSRF as low priority. It requires a specific request pattern, there's no obvious target. The cloud engineer sees the IAM role as standard; instances need metadata access. The Terraform owner sees the bucket as known, documented legacy. Every one of those judgments is locally reasonable. Every silo passes its own review.
No one sees the unbroken line running through all four. The line that lets an attacker chain SSRF to metadata to credentials to a public bucket and walk out with the database. The vulnerability isn't in any silo. It's in the path that crosses all of them, and the path has no owner.
2. The Context Gap in Risk Scoring
When you score a vulnerability, you score it inside its silo:
- The vulnerability scanner finds a CVE in a library and rates it High.
- The infrastructure scanner finds a wide-open security group and rates it High.
Two findings. Two "High" scores. Two separate tickets, teams and sprints.
The attacker does not see two High risks. They see that the vulnerable library is reachable because of that open security group — and reachability is the whole game. To them, the CVE and the security group aren't two risks. They're one functional exploit. The config upgrades the library bug from theoretical to Tuesday.
Now watch what the silo does to your prioritization. Under deadline pressure, you fix the High-scored library CVE first, because it's labeled High and it's "the vulnerability." You leave the security group, because in isolation it's just a config item — maybe even scored Low. You have just patched the half of the exploit that was inert and left the half that made it live. The attacker, holding the unified view, prioritized their time better than you prioritized yours. They knew which finding actually mattered. Your scoring couldn't tell you, because it never put the two findings in the same room.
3. The State-vs-Logic Contradiction
Hold two definitions side by side:
- Application code is logic — how data moves.
- Infrastructure config is state — who has permission.
You treat these as different categories owned by different departments. The attacker treats them as one thing connected by a rule you forgot: logic can change state.
Here's the trap. You look at an IAM policy and conclude it's safe, because only "Admins" can assume it. That's what the policy says. But somewhere in the application layer there is a piece of code — a CI/CD runner, a Lambda function, a deploy script that holds the permission to modify IAM. The attacker who compromises that code doesn't need to be an admin. They rewrite the configuration (state) by exploiting the code (logic). The "Admins only" guarantee evaporates because the thing that enforced it was itself editable by something you classified as a different department's problem.
The Lambda developer, in this picture, is effectively a super-admin. Nobody on the org chart wrote that down, because "IAM management" and "Lambda development" are different boxes. The attacker read it off the permissions in about thirty seconds.
4. Lateral Movement Through Your Own Documentation
When an attacker lands a foothold in a container, they don't bring tools. They "live off the land". The land is your configuration. The first minutes after a foothold are a reconnaissance read across your silos:
- Application config (environment variables) tells them the names of your databases, queues, and downstream services.
- Infrastructure config (instance metadata) hands them credentials.
- Infrastructure code (resource tags) tells them whether they're standing in Prod or Dev, and blast-worthiness of this host.
This is the part defenders most consistently forget: your config is internal documentation for the attacker. You wrote it to make the system operable by humans. It is equally a map for anyone who gets inside. Because you keep these as separate silos, you routinely leak the keys to one kingdom (app config) that happen to unlock an entirely different kingdom (infrastructure). The environment variable that just names a bucket, next to the metadata endpoint that just issues a role credential, is a complete set of directions.
The house analogy
The defender hires a locksmith for the front door (infra code), a carpenter for the windows (app code), and an interior designer for the furniture (app config). Each professional makes sure their part is up to code. The locksmith's locks are excellent. The carpenter's windows are sound. The designer's furniture is beautiful and well-placed.
The attacker doesn't care about the professional labels. They notice that if they climb the furniture (app config), they can reach a window (app code) that the locksmith never connected to the alarm system (infra config). Three flawless jobs. One open path. The flaw was never in a job. It was in the seam between them, which is the place none of the three professionals was hired to look.
The fix: become a unified defender
The reason a reasoning-engine approach matters is that it forces your defense to see what the attacker already sees: pulling code, application config, infrastructure config, and IaC into a single snapshot. It changes the question you're able to ask.
The siloed question is "Is this IAM policy safe?" — answerable only within one box, and therefore answerable wrongly. The unified question is "Does any path exist from this code to this data?" A question that doesn't respect the code/config boundary because the attacker doesn't either. You stop scoring nodes in isolation and start tracing edges across the whole graph: this SSRF, through this role, across this network rule, into this bucket, out to this PII. That path is the finding. The individual hops are not the finding.
The silos in your org chart exist for the same good operational reasons they always did, and they can stay. The silo in your data has to dissolve. Keep the DevOps engineer, the developer, and the security team in separate rooms. But stop letting their findings live in separate rooms. Unify the snapshot even while you keep the org chart.
Because the asymmetry is not going away on its own: the attacker is a unified adversary. The only thing that beats a unified adversary is a unified defender.
Stave is an open-source cloud risk reasoner built around exactly this idea: it evaluates code artifacts and cloud configuration as one unified snapshot, then traces paths across the full graph of code-and-config relationships instead of scoring each silo alone. Deterministic, no cloud credentials required. Break the silos in your data, even if you keep them in your org chart. Apache 2.0.
Top comments (0)