Blog 11 October 2026 3 min read
What a cloud attack path is, and how we score it out of 100
In short
An attack path is a sequence of links that look harmless one by one: a public address, a vulnerable version, an over-broad role, a database holding personal data. Ctadel connects them in a graph of your clouds and scores each path from 1 to 100 on three published factors: exposure, exploitability and the value of the target.
A security team receives hundreds of configuration findings a week. Taken one by one, almost none is serious. The problem is when four of them line up.
Harmless links, dangerous path
Take a web server with a public address. Alone, that is normal. The server ships a Java library in a version vulnerable to Log4Shell. Alone, that is an update to schedule. The server carries a role that can read a database. Alone, that is its job. The database holds account numbers and postal addresses. Alone, it is a customer database like any other.
Lined up, these four links form a path an attacker walks in an evening: reach the server from the internet, exploit the vulnerability, take the server’s identity, read the database.
This is what Ctadel calls a toxic combination. It exists in no single scanner: the configuration scanner sees the public address, the vulnerability scanner sees the version, the identity scanner sees the role, the data scanner sees the account numbers. You need a graph that connects them.
The graph, and two ways to walk it
Everything Ctadel reads in your accounts, and in your code repositories, lands in one graph: the resources, their real relationships (this server carries this role, this role reads this bucket) and the findings of every scanner, attached to the resource they concern.
Two mechanisms produce the paths.
- Hand-written chains describe known combinations: a public instance that hands out its role without a token, a role that reads a bucket classified as personal data. Each link is described by a concept (“public”, “administrator”, “sensitive data”) that resolves to real rules of the catalogue.
- A computed-path engine starts from every entry point reachable from the internet, follows weaknesses, identities and accesses, and stops on targets: data classified as sensitive, an administrator identity, an encryption key, a Kubernetes cluster. It needs no pre-written rule.
The same path found on the next run stays the same finding, with its history. It closes when any link disappears: the patched version, the reduced role, the removed address. Any one is enough.
Why a score from 1 to 100
The severity of a finding comes from its rule. It says nothing about the actual situation of the resource. An attack path carries a risk score from 1 to 100 that combines three factors.
- Exposure: is the first resource reachable from the internet, directly, behind a public load balancer, or through an exposed Kubernetes service.
- Exploitability: is the weakness exploitable remotely. For a vulnerability, the probability follows the EPSS publication, raised when the CVE is in the known-exploited catalogue or used by ransomware.
- The target: does it hold data classified as sensitive, an administrator identity, a key, a control plane.
For a computed path, the score is the probability of the path multiplied by the value of its target, scaled to 100. Each step has a fixed probability, the same for every customer, published in the attack paths documentation so an auditor can read it and challenge it.
The result sorts the toxic combinations page. The path in the example above comes out at 96. A valid access key found in a public bucket comes out at 81. A path whose entry is a private cluster endpoint and whose target is an unclassified database drops far below.
What it changes for the team
On Monday morning, the question is no longer “which of our eight hundred findings do we handle?” but “which of our twelve paths do we break first?”. And for each path, the answer is in the panel: the cheapest link to remove, the command or Terraform line that removes it, and the ticket that follows the fix.
The dashboard score follows the same logic: it counts only open toxic combinations, weighted by severity and divided by the number of resources. A scope with no path at all is worth 100, even with open configuration findings. That is deliberate: the path is what hurts, not the finding. The full calculation is in Severity and score.
You can look at real paths on the online demonstration, open to everyone.