Attack Path Analysis
Attack Path Analysis connects individual security findings — misconfigurations, identity risks, network exposures, and vulnerabilities — into chains that reveal exactly how an attacker would move from an exposed entry point to your most critical assets. Rather than presenting a long list of disconnected findings, Onam builds a graph of your estate and searches it for the routes that actually reach something worth protecting.
This page explains how the graph is built and verified, how paths are found and ranked, how MITRE techniques are attached per hop, and how choke points tell you the one fix that severs the most paths.
How the graph is built
After every scan, the Attack Path engine rebuilds a graph database of your estate from the scan's results:
Nodes are every resource in the asset inventory — EC2 instances, S3 buckets, IAM roles, Lambda functions, RDS databases, Kubernetes pods, secrets, and the rest — carrying their properties, findings, and classification.
Edges are relationships that represent possible attacker movement. They are produced by catalog-driven edge derivers, each specialized in one kind of evidence:
- IAM policy derivation — role assumption, PassRole, resource-policy access
- Network exposure — internet-facing endpoints, load balancer chains
- Security group rule matching — which sources can actually reach which ports
- KMS and encryption relationships — who can decrypt what
- CDR behavioral edges — movement actually observed in audit logs
- Public-exposure classification —
is-publicon buckets, snapshots, images
The resulting edge types read like attacker verbs: CAN_ASSUME, CAN_REACH, CAN_READ_SECRET, CAN_READ_OBJECT, CAN_DECRYPT, CAN_INVOKE.
Edge verification
A candidate edge is not enough — a security group may permit traffic that IAM forbids, or a policy may grant access a network path never reaches. Every edge is marked CONFIRMED, BLOCKED or GAP from the evidence behind it. Only confirmed edges are walked, which is why the engine produces paths that can actually be taken instead of every theoretical route.
Path traversal
The engine runs BFS traversal from entry points toward crown jewels:
- Entry points — the internet, admin and other identities, CI/CD, third parties, and other clouds, each with its own starting likelihood. Classification is catalog-driven, so new exposure patterns are added without code changes.
- Crown jewels — data stores such as S3 buckets, RDS and DynamoDB, encryption keys, and other targets the catalog marks as high value. Stores that Data Security finds sensitive are flagged as crown jewels too.
Likelihood decays with every hop. Each path is then scored:
- Likelihood × impact — the path's likelihood times the value of the crown jewel it reaches gives a 0–100 score and a severity
- Controls — a WAF or MFA on the route lowers the score
- Exploitability — a hop with a high-EPSS vulnerability raises it
Crown jewels also feed the Risk Quantification engine: a finding on a crown jewel gets a higher asset multiplier in its loss estimate.
Per-hop MITRE ATT&CK chains
Every hop in a path is tagged with the MITRE ATT&CK technique an attacker would use to take it, and the engine tracks capability accumulation along the path — what the attacker holds (credentials, network position, data access) after each hop. The result reads like a red-team narrative: entry, escalation, lateral movement, objective.
| Graph element | MITRE technique |
|---|---|
| Public S3 bucket to IAM credential exposure | T1552.005 — Cloud Instance Metadata API |
| IAM role to lateral movement | T1078.004 — Valid Accounts: Cloud Accounts |
| EC2 to RDS network path | T1021 — Remote Services |
| Secrets Manager access | T1555 — Credentials from Password Stores |
Choke points
Choke points are the resources that many attack paths share. Fixing one choke point blocks every path that runs through it. For each choke point, the engine records how many paths would be blocked if it were fixed, and every hop on a path carries its own remediation step. Findings on choke points also get a higher loss estimate in Risk Quantification. See Choke Points for the console view.
Remediate choke points before individual paths. One choke-point fix can close many paths at once — it is the highest-leverage action the platform can recommend.
Integration with other engines
| Engine | Contribution to the graph |
|---|---|
| CSPM | Entry-point misconfigurations, node-level findings |
| CIEM | Identity edges — assumption chains, permission graphs |
| Network Security | Reachability edges from effective exposure analysis |
| Vulnerability | CVE nodes enriched with EPSS and KEV |
| CDR | Behavioral edges — movement actually observed in logs |
| Data Security | Crown-jewel classification from data discovery |
| Risk Quantification | Reads attack-path signals to raise the loss estimate of findings on paths |
FAQ
When is the graph built? Automatically after every scan. The graph is rebuilt in full each time, so a route you have fixed is simply absent from the next result.
Do I need to tag crown jewels? No. Crown jewels come from the catalog of high-value targets and from data-security classification, so paths are found without any tagging.
Next steps
- Threat Detection — how posture, behavior, and correlation fit together
- Risk Quantification — how attack-path signals raise loss estimates
- CIEM — the identity chains that become graph edges
- Book a demo — see the choke points in your own estate