sg-deceptive-reachability-auditor skill

sg-deceptive-reachability-auditor

Reachability-audit skill for a fleet of AWS security groups. Takes the describe-security-groups output for the fleet (plus describe-instances for the instance-to-SG membership), composes the SG-to-SG references into a directed graph, and answers one question a per-rule read cannot: from a named entry point, what can actually be reached, and does any path reach the crown-jewel tier. It returns the shortest path, the blast radius, and any pivot hub, ranked by severity, then names exactly where the SG graph stops being able to answer the question.

The job is a graph problem, and the whole point of the skill is the composition the graph makes visible. A per-rule read sees "app accepts from web" and "db accepts from app" as two individually fine rules and never assembles that internet -> web -> app -> db is one reachable path. In a fleet of 10-13 security groups, that chain is buried among scoped tiers (bastion, monitoring, ci, ssm) and app-fed leaves (cache, queue, logs), and the loud 0.0.0.0/0 rule on the front door draws the eye away from it. This skill composes the edges instead of clearing each rule in isolation.

When to invoke

radius, or "can the internet reach the database."

• An agent is asked to review a security-group fleet for lateral movement, blast

reach a sensitive one transitively, not just directly.

• A fleet is being shipped or changed and the question is whether a low-trust tier can

pivot to.

• An incident assumes a host is compromised and the question is what that foothold can

confirmed against the actual edges rather than taken on trust.

• A fleet looks segmented and the claim "the database is isolated" needs to be

What this skill reads, and what it does not

It reads the static configuration of a fleet of security groups plus the instance-to-SG membership. Both are EC2 control-plane reads (describe-security-groups, describe-instances). That is the entire input. The audit is correct and complete for what the SG graph can tell you, and it is explicit about the rest. Reachability-on-paper is not exploitability, and every audit ends by naming the joins it cannot make:

referenced SG; it does not mean an instance in that SG is running and serving. An empty SG is a path to nothing. Join: SG graph to the live ENIs/instances in each SG.

• It does not confirm a live host is listening. An edge means an SG accepts the

path no matter what the ingress rules allow. Join: SG graph to the subnet route tables.

• It does not read route tables. Two SGs on unrouted subnets are not on a routable

and can deny traffic the SG graph would allow. Join: SG graph to the subnet NACLs.

• It does not read network ACLs. A NACL is a stateless layer below security groups

app token can stop a network-reachable hop from becoming access. Join: network reachability to the app-layer auth on each tier.

• It does not read app-layer auth. A database password, an mTLS handshake, or an

Every audit ends by naming these. A clean (segmented) fleet still gets a boundary section, because a network-segmented fleet is not a proven-safe system.

The model

Build a directed graph over security groups. An edge A -> B exists when SG B has an ingress rule whose UserIdGroupPairs includes SG A (B accepts traffic from A), meaning a host in A can reach a host in B. A synthetic node internet has an edge internet -> X for every SG X with a 0.0.0.0/0 (or ::/0) ingress rule.

From the entry point named for the audit (internet, or a compromised instance id that resolves to that instance's SGs), compute the transitive closure with BFS. A visited set makes cycles terminate. The findings fall out of the closure.

The methodology, in order

1. Parse the fleet into edges

Before any judgment, turn the JSON into the graph:

another SG in the fleet is an incoming edge: referenced-SG -> this-SG. This is the step a naive read skips. The SG-reference arrays are where the chain lives.

• For each SG, read its IpPermissions (ingress). Every UserIdGroupPairs entry naming

internet-facing: internet -> this-SG.

• Every 0.0.0.0/0 / ::/0 IpRanges / Ipv6Ranges entry makes the SG

compromised host) resolves to a set of start SGs, and so a tier with no running host can be flagged as a path to nothing at the boundary.

• Read describe-instances for the instance-to-SG membership, so the entry point (a

reads as internet -> web -> app -> db, not as a list of sg- ids.

• Label each SG by its tier / Name tag, then GroupName, then GroupId, so the path

2. Compute the closure and the path (P1)

Run BFS from the entry's start set. The reachable set is the closure minus the start. If the crown-jewel tier is in the closure, compute the shortest path (fewest hops) to it and report it as the headline:

shortest path as an explicit ordered hop list (internet -> cdn -> waf -> gw -> app -> svc -> db). No single ingress rule is alarming; each tier accepting the tier in front of it is routine. The edges compose into one path a per-rule read never assembles. This is the lateral-movement chain the audit exists to surface, and on a needle fleet it is the primary finding, named end to end, not a footnote under the loud public rule.

• P1 (critical) — a reachable path from the entry to the crown jewel. Report the

3. Report the blast radius (B1)

(distance >= 2 from the entry, i.e. beyond the directly-exposed front-door tier), report the full reachable set: the tiers a foothold at the entry can pivot to with no further misconfiguration. State explicitly whether the crown jewel is inside the radius. A fleet whose chain breaks after the first hop has no lateral reach and does not fire B1 — that distinction is load-bearing for the clean fleets.

• B1 (high) — the blast radius. When the closure composes at least one lateral hop

4. Find the pivot hub (H1)

intermediate reachable SG, recompute the closure with that node removed. If its removal disconnects two or more mutually-isolated regions of the blast radius, it is a true pivot (an articulation point), not just an ordinary hop on a linear chain. A shared-services SG (monitoring, CI, a jump tier) that every tier references is exactly this shape: it quietly joins tiers that were never meant to reach each other. Do not report the entry node or the directly-internet-facing front door as a hub; those are a different auditor's finding.

• H1 (high) — a pivot/hub SG bridging otherwise-isolated regions. For each

5. Stay quiet on the deceptive-clean fleet

This is the half of the skill that the naive read gets wrong in the other direction. A segmented, orphaned, or broken fleet where no path reaches the crown jewel is CLEAN, and the audit must say so instead of manufacturing a path. The same composition discipline is what proves it. Specifically:

accepts only an internal service-mesh CIDR, not the public SG) is not a reachable path. Do not report it as one.

• An orphaned deep chain (the deep tiers reference each other, but the front tier

path and not the headline.

• An intended public ALB taking 0.0.0.0/0 is the expected ingress, not the lateral

be spliced into a manufactured internet -> db route.

• A disjoint data island (a public region and an unconnected private region) must not

the cut.

• A broken mid-chain segment (the chain is cut at one hop) is not reachable across

about correctly-scoped tiers (bastion, monitoring, ci, ssm).

• Do not drown the real finding, or the clean verdict, in a wall of low-value nitpicks

On a clean fleet the audit reports: no reachable path to the crown jewel, the bounded blast radius (and the boundary it cannot cross), and the join checks that would confirm the segmentation holds. It does not invent a critical.