Defence in depth inside the application: modelling routes instead of counting findings

A backlog of ten can be more dangerous than a backlog of a thousand. A spreadsheet-sized way to work out which.

Imagine your application's vulnerability backlog falls from 1,000 findings to ten. Everyone is pleased, and they should be: that is real work.

Now ask a different question. Do those ten findings stay confined to minor effects, or do three of them line up so that an ordinary customer account can reach an administrator session, and from there a job that executes code on the server?

A finding count cannot answer that, and neither can a list of severity scores. The question is how findings connect, which needs a different unit of analysis: the route.

Disclosure: the method in this post comes from Rings of Risk, a working research draft by Kolega Labs, where I work. It is published with open ledgers, and you can adopt the method without a product.

What existing measures answer, and what they do not

Security teams already have good instruments. The problem is asking them questions they were not designed to answer.

CVSS rates the technical severity of an individual vulnerability. FIRST, which maintains it, explicitly warns against treating the Base score as risk. To its credit, the CVSS v4.0 user guide explains how an analyst can score a known chain. But that starts with a chain someone has already identified. It does not discover one.

EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days. CISA's KEV catalogue records CVEs with evidence of exploitation. SSVC is a decision tree for what to do about a known vulnerability. All three are valuable for published CVEs. None of them can score an unpublished flaw in your own code, and none tells you whether two of your findings compose.

Attack paths are not a new idea either. MulVAL (2005) derived attacker capabilities from network facts and rules, and Topological Vulnerability Analysis represented exploit dependencies across a network. Today's exposure-management products draw paths across assets and identities and highlight choke points. What is mostly missing is the same reasoning inside application code, where an identifier leaked by one feature becomes the key another feature trusts.

Three measures, kept separate

The method uses three measures. The discipline is in not collapsing them into one number.

1. Position: where does the attacker stand? Access Rings rank privilege from the core outward:

RingNameExample positionAR5OutsideAnonymous, or holding only a link or an identifierAR4Standard userAn ordinary logged-in customerAR3Delegated authorityAnother principal's authority: an admin role or a victim's sessionAR2Control planePlatform or tenant administration; secret and key storesAR1Crown jewelsServer-process code execution; control of the datastore or identity root

2. Consequence: how bad is the outcome? Four bands: B1 Critical (loss of an essential function or authority), B2 Major (substantial data or operational harm), B3 Moderate (bounded, recoverable), B4 Limited (local, readily reversed).

Position and consequence are different measurements. A B1 Critical account takeover can end at AR3, because the attacker now holds someone else's authority but not the server. Server-process execution ends at AR1. Both are critical, but they are not the same place.

3. Role: what does this finding contribute? Reach rings classify a finding by what it can reach from a declared starting position:

• RR1 Critical reach: reaches a B1 outcome with no other code flaw.
• RR2 Major reach: reaches B2 with no other code flaw.
• RR3 Chain-dependent: contributes to B1 or B2 only together with another flaw.
• RR4 Bounded reach: reaches only B3 or B4.
• RR5 No established reach from this starting position.

RR3 is the interesting class. An RR3 finding looks unimportant in a list, and it may be the step that completes every route to the crown jewels.

A finding is an arrow

The notation is simple. Lay the rings out as columns, outside on the left and crown jewels on the right. Every finding is an arrow: its tail is the ring the attacker occupies when exploiting it, its head is the ring they hold afterwards. The arrow's length is what the finding gives.

Every arrow ends in a circle. A final circle is a protected outcome; an intermediate one is a position gained on the way, such as an administrator session or a leaked secret, and the next arrow starts from it. A finding used by several routes is drawn once.

Non-code steps matter too. A phished password, open self-registration or a victim clicking a link are drawn as dashed lines that place the attacker in a ring. They are conditions, not vulnerabilities, but leaving them out makes routes look harder than they are.

A five-column diagram from AR5 Outside to AR1 Crown jewels. Five findings drawn as arrows chain into two routes; both routes to server execution pass through one finding, F5, so one fix closes both. Schematic of a fictional application, using the notation of Rings of Risk. Arrows are findings; circles are positions or outcomes.

Read the map and two things stand out that a list would hide. F1 is a modest information leak on its own, and it is the first step of an account-takeover route. F5 sits behind a control-plane credential, so a list ranked by reachability from the internet might deprioritise it, yet two different routes converge on it. Fix F5 and both routes to server execution close.

Why you should not add the routes up

It is tempting to turn this into a score, where three routes to server execution are three times worse than one. Routes do not work that way.

If routes were independent and each had a known success probability, the chance that at least one succeeds would be 1 − ∏(1 − pᵢ). Application routes share steps, credentials and conditions, though, so independence rarely holds, and nobody has measured the pᵢ values anyway. A second route to the same outcome does not double the harm. It means more opportunity, and possibly another fix.

So the method keeps the evidence visible instead. For each protected outcome it records an outcome profile:

• Consequence: the resource, operation, affected population and band.
• Entry difficulty: the least demanding routes, with their starting ring and conditions.
• Route count: distinct supported routes, with unconfirmed candidates listed separately.
• Known-route closure set: the smallest set of fixes or controls that interrupts every known route.

That last field is what turns a vulnerability list into a remediation plan. A compact profile reads like this: "Critical customer-data disclosure; ordinary-account entry; three supported routes; two fixes close the known routes."

Doing this with a spreadsheet

You do not need tooling to start. Take one protected outcome you care about and fill in a route ledger, one row per route.

Get the route-ledger template: make your own copy in Google Sheets

Three rules keep the ledger honest: every code step cites the source lines that support it, every non-code condition is written down as an assumption, and a route stays a candidate until something executes it. That execution step is the subject of a later post in this series.

What this method does not claim

It does not find every route, and it is not a standard or a score. The Rings of Risk study applied it to 15 open-source applications from source alone; nothing was executed and no attack was observed. Its 246 route records are a review inventory, with overlapping variants, not 246 proven chains. That is the right level of claim for a first map, and it is why validation comes later in this series.

The method changes the question from "how many findings do we have?" to "which protected outcomes can still be reached, from where, and what would close them?" Next, I turn to the tools that produce findings in the first place, and how to tell whether a benchmark of those tools is telling you the truth.

References

1. Pellew, J. and Raza, F., Rings of Risk: Consequence and Reachability in Application-Code Vulnerability Chains, working draft, 22 October 2026.
2. FIRST, CVSS v4.0 User Guide.
3. FIRST, Exploit Prediction Scoring System (EPSS).
4. CISA, Stakeholder-Specific Vulnerability Categorization (SSVC) and Known Exploited Vulnerabilities Catalog.
5. Ou, X., Govindavajhala, S. and Appel, A. W., "MulVAL: A Logic-based Network Security Analyzer", 14th USENIX Security Symposium, 2005.
6. Jajodia, S., Noel, S. and O'Berry, B., "Topological Analysis of Network Attack Vulnerability", in Managing Cyber Threats: Issues, Approaches and Challenges, Kluwer Academic, 2003.
7. OWASP, Risk Rating Methodology.