The question this answers
What does this infrastructure diagram look like when you read it the way an attacker would?
The architecture review approved a design that meets the availability and latency requirements. Nobody in the room asked which of those boxes is reachable from the internet, which identity can read the database credentials, or what an attacker who lands on one container can reach from there. The design is correct and the review was incomplete.
A repeatable second pass over an existing diagram that produces a specific list: what is reachable from outside, which identity each component acts as, which links are encrypted, where trust changes hands, and what each compromise reaches next.
The same topology, read twice
An infrastructure diagram is normally drawn to answer availability and data-flow questions: where does a request go, what happens if this zone dies. The Security View reads the identical topology and asks a different set of questions of every node and every edge. Not "does this work" but "who can reach this, as whom, and what do they get".
The mechanical part is annotating exposure on each node — public, private or internal — because most findings fall straight out of that one act. A component whose exposure nobody could state is a component nobody has thought about. But exposure alone is not a verdict, and this is the discipline the whole domain depends on: a public load balancer on 443 is the design working correctly, while a public database on 5432 is the finding. Reading the annotation without reading the context produces a security review that cries wolf and gets ignored. Public Exposure, Read With Context is the lesson that teaches that judgement properly.
The topology below is an ordinary three-tier design, correct from an availability standpoint, with the overlay applied. Four flags come out of a two-minute pass: an administrative interface reachable from anywhere, a database credential passed as a plain environment variable, an unencrypted hop that leaves the load balancer, and a container running with an identity far broader than its job. None of these are exotic. All four are the ones that show up in real incidents.
The seven things the overlay highlights
The overlay is a checklist precisely so that it survives being applied by a tired person on a Friday. Seven passes, each answering one question about every node or edge in the diagram. It takes minutes on a small design and it is the highest-value security activity available to a team that does not have a security engineer.
The output is not a score. It is a list of specific, arguable findings, each with a context sentence explaining why this instance is or is not a problem. A finding that cannot state its context — "public endpoint detected" with no reasoning — is the kind of automated noise that trains engineers to dismiss security tooling entirely.
Two of these passes deserve special attention because they are the ones most often skipped. The identity pass asks what each compute node *acts as*, and it is where over-permissioned workloads surface. The blast-radius pass asks, for each node in turn, "if an attacker owns this, what do they own next" — which is the only pass that finds problems arising from the *combination* of otherwise reasonable decisions.
| Pass | Question asked of every node or edge | Typical finding |
|---|---|---|
| 1. Exposure | Is this reachable from the internet, from the private network, or only from inside the host? | A management port or data port with a public address and no business reason for one |
| 2. Reachability | Which specific sources can open a connection here, on which ports? | A security group allowing the whole VPC where it needed one peer group — see Security Groups: The Stateful Firewall |
| 3. Identity | What does this component act as when it calls something else? | A container using long-lived static keys, or a workload borrowing a human's credentials — see Human vs Workload Identity |
| 4. Secrets | Where does each credential live, how does it get there, and who can read it? | Credentials in environment variables, in the image, or in the IaC state file — see Secrets in Infrastructure |
| 5. Encryption | Is this link encrypted in transit, and is this store encrypted at rest with a key you control? | A plaintext hop that is "inside the VPC", which stops being reassuring the moment anything inside is compromised |
| 6. Privilege | Which resources can change other resources, or mint credentials? | A deployment role that can create identities, or an identity that can disable the audit trail — see Audit Trails |
| 7. Blast radius | If an attacker owns this node, what do they reach next, and with what? | One compromised container reaching every bucket in the account because its policy used a wildcard |
Blast radius is what turns a list into a decision
The first six passes produce findings. The seventh ranks them, and it is the one that makes the review actionable. "The API container has wildcard read on object storage" is abstract. "One remote code execution in the API means every customer document in the account is readable, including the billing exports" is a sentence a product owner can prioritize.
Work it node by node. Assume the attacker has code execution on the node. What credentials are in reach — environment variables, instance metadata, mounted files, a token in the process memory? What can those credentials do? What can they reach on the network from here? The answer is usually much larger than anyone expected, and it is almost always the *identity* rather than the *network* that carries them furthest. Network segmentation stops lateral movement between subnets; it does nothing to stop a stolen workload identity being used to call the storage API from anywhere.
The panel below is the same API container from the topology, read as blast radius. Note that the fix is not a new component. It is the removal of a wildcard, and it costs one afternoon of finding out which prefixes the service actually uses. Most overlay findings are like this: cheap to fix, expensive to have ignored.
- storage:GetObject on *
- storage:ListBucket on *
- storage:PutObject on uploads/*
- storage:GetObject and storage:PutObject on uploads/tenant-*/ only
Blast radius: Any code execution in the API — a deserialization bug, a vulnerable dependency, a server-side request forgery reaching the metadata service — yields read access to every bucket in the account: database exports, backups, billing documents and the terraform state file, which itself contains further credentials. Narrowing the wildcard to one prefix reduces the same compromise to the tenant data the service was already handling.
Key points
- Every infrastructure diagram gets a second reading: exposure, reachability, identity, secrets, encryption, privilege, blast radius.
- Annotating exposure on every node is the cheapest high-value step, and a node whose exposure nobody can state is a node nobody has considered.
- Exposure is not a verdict. A public load balancer on 443 is the design; a public database on 5432 is the finding. Context decides.
- The identity pass finds more real problems than the network pass, because a stolen workload identity ignores your subnet boundaries entirely.
- Blast radius is what turns a list of findings into a prioritized decision, and most of the fixes it produces are the removal of a wildcard rather than the addition of a component.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • Take the existing topology unchanged — this is an overlay, not a separate diagram that will drift from reality.
- • Annotate every node with an exposure value and every edge with the protocol, port and whether it is encrypted.
- • Mark every compute node with the identity it acts as, and every credential with where it lives and who can read it.
- • Mark trust boundaries on the edges that cross them — see Infrastructure Trust Boundaries.
- • For each node, write one sentence answering "if this is compromised, what is reached next". Rank findings by that sentence, not by severity labels.
- • Run the overlay at design review, not after launch. It costs minutes before build and weeks after.
- • Re-run it whenever the topology changes, because exposure is added by small changes: one new managed service, one convenience rule, one debugging port left open.
- • Keep the annotations in the same artifact as the diagram. A security view maintained separately is stale within a month.
- • Automate the mechanical passes — public exposure, wildcard policies, unencrypted links — and keep the blast-radius pass human, because it depends on what the data actually is.
- • Record accepted risks explicitly with their reason. "Public on purpose because it is the front door" is a finding that has been reviewed, and that is different from one that was never noticed.
- • The overlay produces a list nobody owns; findings are noted, nothing changes, and the next review notes the same ones.
- • Reflexive flagging of every public endpoint, which produces noise, gets dismissed, and buries the one finding that mattered.
- • A security view that has drifted from the deployed topology, so it reassures about an architecture that no longer exists.
- • Findings ranked by a severity label rather than by blast radius, which systematically over-prioritizes low-impact exposure and under-prioritizes wildcard identities.
- • Perimeter thinking: everything inside the VPC treated as trusted, so the entire review reduces to "is the front door locked".
- • The manual overlay is genuinely practical up to roughly a few dozen components; past that, the mechanical passes have to be automated or they stop being run.
- • Findings grow with the number of edges rather than the number of nodes, because reachability and trust crossings are edge properties.
- • Multi-account or multi-project structures reduce blast radius faster than any single control, because they cap what one compromised identity can enumerate.
- • The dimension that runs out first is review attention, which is why the finding list must be ranked and short.
- • This lesson *is* the security view, and every other lesson in the domain carries a
securityfield for the same reason: security is a reading of the design, not a component added to it. - • The overlay is a lightweight threat model. It does not replace the Security Engineering domain's treatment of threat modelling, attack trees or defence in depth — it makes infrastructure reviews start from the same facts.
- • The output is deliberately arguable. A finding with a context sentence invites the right conversation; a finding with a score invites a workaround.
- • The overlay itself costs review time and nothing else, which makes it the best-value security activity available to a small team.
- • Its recommendations do cost money: private connectivity instead of public endpoints, per-service identities, encrypted links with managed keys, separate accounts per environment.
- • The counterfactual matters: the wildcard-identity finding costs an afternoon to fix and an incident-response engagement to have ignored.
- • Count of components with an unstated exposure value — this should be zero and rarely is.
- • Count of identities holding wildcard permissions, tracked over time as a trend rather than a snapshot.
- • Unencrypted internal links, which tend to reappear whenever someone adds a service in a hurry.
- • Audit-trail alerts for public-exposure changes, which is the automated version of pass one — see Audit Trails.
- • The signal that lies: a clean vulnerability scan. Scanners find known CVEs in packages; they do not find that your container identity can read every bucket in the account.
- • For a two-component system, three questions cover most of the value: what is public, what identity does the app use, and where does the database password live. Do not build a process heavier than the system.
- • Provider posture-management tooling automates the mechanical passes and is worth turning on early — but it cannot do the blast-radius pass, because it does not know what the data is.
- • A full structured threat model (STRIDE, attack trees) is the right tool when the system handles regulated data or faces a motivated adversary. The overlay is the cheap, always-run version, not a replacement.
- • Structural prevention beats review: separate accounts per environment and an organization-level policy denying public data ports removes a whole class of findings without anyone having to notice them.
- • Buys a repeatable, shared way to see exposure and blast radius; costs review time on every design change and a finding list somebody has to own.
- • A checklist is fast and consistent, and it will miss the novel attack path a real threat model would find.
- • Its recommendations trade convenience for containment: per-service identities, private endpoints and scoped policies all make day-to-day work slightly harder.
What people believe, and what is true
Anything with a public address is a security problem.
Public is a property, not a verdict. Load balancers, CDN edges and static sites are public on purpose. The finding is a public *data* or *management* endpoint with no reason to be one.
Inside the private network is trusted.
Private means not directly reachable from the internet. It does not mean authenticated, encrypted or safe — a compromised container is inside the private network too.
Security review is a phase before launch.
Exposure is added incrementally by ordinary changes. The overlay is re-run per topology change, or it describes an architecture that no longer exists.