Find attack paths before someone else does
Atlas follows network rules, roles and data permissions the way an attacker would: in from the internet, through a workload and the role it runs as, to the data at the end. Every path is ranked by what it reaches.
- 1Trace the path hop by hop
The internet reaches checkout-lb on 443, which routes to checkout-api on 8080. checkout-api runs as checkout-task-role, which can read customer-exports.
- 2See why it ranks Critical
The header names three causes: a security group open to 0.0.0.0/0, a role with s3:* on *, and PII in the bucket at the end.
- 3Measure the role's full reach
The role also reaches payments-archive (PCI), claims-lake (PHI) and ci-config secrets, 14 targets in all. The fix belongs on the role too.
A thousand findings, and no idea which one is reachable
Scanners list issues one at a time. An attacker chains them. These rows show where that gap hurts.
A number is not a consequence
What usually happens: The report says 342 findings are internet-reachable. It doesn't say which of them leads anywhere that matters.
How CloudLens resolves it: Each path ends at a named resource, like customer-exports with 2.4M PII records, so the first ticket is obvious.
ResolvedThe role is often the bigger problem
What usually happens: The team closes the open port and moves on. The workload still runs as a role that can read every bucket in the account.
How CloudLens resolves it: The path shows the role as its own hop, so the fix covers the network rule and the permissions together.
ResolvedCVE queues never get shorter
What usually happens: Inspector reports hundreds of package CVEs, and patching follows CVSS order regardless of where the package runs.
How CloudLens resolves it: A CVE on a workload the internet can reach becomes a step in a path and moves up the queue.
ResolvedOne path, from detected to closed
Marcus is one of two security engineers at Lumora Retail. This is how the top path of the week was handled.
Lumora Retail is a fictional company. The people, names and numbers are sample data.
The checkout path is ranked first
He reads the hops
Creates SEC-77 from the path
Checkout narrows the role
The overnight scan confirms it
Map your attack paths with a read-only scan
Edges come from your own configuration
A path is only useful if every hop is real. Atlas derives reachability from the rules that allow traffic, then follows identity and data permissions to the end of the chain.
Security-group rules become edges you can check
- Inbound rules become REACHES edges
- Load balancer to workload to database
- No workload, no edge
- 1Read the inbound rules
checkout-lb-sg admits 443 from 0.0.0.0/0. checkout-api-sg admits 8080 only from checkout-lb-sg.
- 2Watch each rule become an edge
Each allowed source adds a REACHES edge, ending with checkout-api reaching orders-db on 5432. Every edge traces back to one rule.
- 3Skip the empty CIDR range
orders-db-sg also allows 10.20.0.0/16, and nothing runs in that range. No edge is drawn for it.
- Data-class aware ranking
- Reach view for every role
- Jira issue from the path
- 1Scan the ranked list
Four paths, ordered by what they reach. customer-exports with 2.4M PII records is first, and the support-tickets path ranks on reach only because that table isn't scanned.
- 2Open the top path
The drawer draws the hops and lists what the role reaches: customer-exports, orders-db with 8.1M PII records, and 12 more targets.
- 3Create the Jira issue
One click creates SEC-77, linked to the path. Its Jira status syncs back next to the finding.
A CVE on the path moves up the queue
- Inspector package vulnerabilities
- Unsupported software on reachable resources
- Fix guidance on the finding
- 1Inspector flags a package on checkout-api
Amazon Inspector reports libxml-parse 2.9.1 with CVE-2026-1182 on the running image. The finding attaches to the checkout-api node.
- 2Confirm the internet can reach it
The path runs from the internet through checkout-lb to checkout-api. A reachable CVE moves ahead in the patch queue.
- 3Follow it to the data
From checkout-api the path continues through checkout-task-role to customer-exports. The fix shown is libxml-parse 2.9.4 in checkout-api:2026.09.2.
- Account, frameworks and owner
- Risk, owner, related, remediation
- Path drawn hop by hop
- 1Ask what the risk is
Port 22 on checkout-api is open to the internet, and its role can escalate and read 2.4M PII records. Each is High alone, Critical together.
- 2Ask who should fix it
The team=checkout tag assigns the finding to the Checkout team. Nobody has to guess the owner from a resource name.
- 3Check the related findings
sg_open_to_world, iam_privilege_escalation and CVE-2026-1182 on checkout-api are listed. Each one can still be closed on its own.
- 4Read the remediation plan
Allow port 22 only from bastion-sg, remove iam:PassRole and * actions from the role, then patch and redeploy checkout-api.
Network, identity and data in one chain
Internet exposure
Public load balancers, open security groups and CloudFront origins mark where a path can start.
Identity reach
Wildcards and privilege-escalation permissions on a workload's role extend the path.
Data at the end
Classified stores holding PII, PCI, PHI or secrets decide how much a path matters.
Known CVEs
Inspector findings on reachable workloads join the chain as a step instead of sitting in a separate list.
About attack paths
No. Atlas reads configuration through a read-only role and computes paths from it. Nothing is probed and no traffic is sent.
The path is ranked on reach alone and the store is labelled Not scanned. It is not treated as holding nothing sensitive.
Yes. Each path is a finding with severity, triage state, comments and Jira linking, so it goes through the same workflow as everything else.
Find the paths in your own cloud
Connect a read-only AWS role or Azure service principal. We'll walk you through your bill, your security graph and the first things worth fixing.