A finding is a fact. A verified path is a decision.
Every cloud scanner produces thousands of findings. The hard problem is not detection — it is knowing which handful of them combine into a route an attacker could actually walk to something that matters, and what that route is worth in dollars. Onam treats that as a graph-reasoning problem, solved the same way every time.
This paper describes the method end to end: how Onam ingests 7 clouds read-only, normalises everything into one property graph, derives the relationships an attacker would exploit, searches for routes from internet-reachable entry points to crown jewels, and — critically — verifies every edge across five independent security domains before it is ever called a confirmed path. Each hop is mapped to a MITRE ATT&CK technique; the full set of paths is reduced to its top five choke points; and the resulting exposure is priced with the FAIR model, so the output is a board-ready number rather than a severity label.
A modern multi-cloud estate generates findings faster than any team can trace them. The industry's default answer is severity: sort by Critical, work down the list. But severity is a property of a finding in isolation. It cannot tell you that a "medium" public endpoint, a "low" over-permissive role and an unencrypted data store are — together — a single four-hop route to your customer records.
Attackers do not read your list. They chain. A route is only as strong as its weakest link, and the link that matters is rarely the one with the scariest CVSS score. To prioritise like a defender who thinks like an attacker, you have to reason over the relationships between findings, not the findings themselves.
Onam holds no standing credential in your cloud — only a reference it exchanges for a token that expires.
The method starts with telemetry that is safe to collect. Onam connects to each cloud with the lowest standing privilege that permits a security read, and stores no long-lived credentials — only a reference to the role or principal, exchanged for short-lived tokens at scan time.
| Cloud | Connection | Privilege posture |
|---|---|---|
| AWS | Cross-account IAM role via sts:AssumeRole, unique External ID per tenant | SecurityAudit + ReadOnlyAccess; STS credentials ≤ 60 min |
| Azure | Entra service principal | Reader + read-only Graph |
| GCP | Service account or keyless Workload Identity Federation | 6 read-only roles |
| OCI | IAM user + signing key | inspect + read only |
| Alibaba / IBM | RAM read-only · Service ID | Read-only, exchanged for a short-lived Bearer token |
| Kubernetes | Read-only ServiceAccount | get / list / watch |
Full detail of the trust model is in Whitepaper 04.
Everything normalises into a single per-tenant property graph. Assets are nodes; edges are typed — containment, attachment, IAM trust and network reachability. Catalog-driven derivers then add the abuse edges: the relationships an attacker would actually use, as distinct from the ones the cloud provider documents.
This is the step that makes cross-cloud reasoning possible at all. A path that starts in one provider and ends in another is only visible when both are described in the same vocabulary. Architecture detail is in Whitepaper 03.
Search is breadth-first from internet-reachable entry points toward crown jewels — the assets a customer has designated as mattering. Breadth-first matters: it finds the shortest route first, and the shortest route is usually the one an attacker takes.
A path that exists in the graph is a hypothesis, not a finding. Before Onam calls a path confirmed, every edge is verified across five independent security domains — identity, network, data, workload and configuration state. An edge that only one domain supports does not survive.
Each verified hop maps to a MITRE ATT&CK technique, so the route reads as an attack narrative rather than a list of resource IDs. The full set of paths then reduces to its top five choke points — the nodes appearing on the most confirmed routes, where one change removes the most attack surface.
Finally the exposure is priced with FAIR, producing an Annualised Loss Expectancy per path and a roll-up across the estate. Method detail is in Whitepaper 02.
One claim, repeated at every stage: a finding is a fact, and only a verified route is a decision.