Attack-Path Framing

A security review delivers 47 findings on a five-by-five likelihood-impact grid: nine high, twelve medium, twenty-six low, each with a numeric score. Nine weeks later, two are fixed. The review was competent and thorough, and it produced almost no change in the system.

The scores are the problem. A score is the product of two guesses, and multiplying them discards the thing an engineer needs, which is which guess is doing the work. Likelihood 2 with impact 5 and likelihood 5 with impact 2 both score 10 and require completely different responses. Worse, a score is arguable, so the review is spent negotiating ratings rather than discussing fixes.

Why it matters

Any prioritisation scheme that can be argued with will be argued with instead of acted on. The pack's job is to cause a small number of specific changes and to cause the rest to be knowingly not made, and a scored register does neither: high findings are disputed, low findings are ignored, and a pack that is 55% items nobody will act on teaches its reader to skim the 20% that mattered.

Attack-path framing changes what is arguable. A path is falsifiable on facts: an engineer who knows the system can say "that route is already blocked, because the endpoint is behind the mesh's mutual TLS", which is the fastest way to find the review's own errors and the fastest route to a real fix.

Implementation patterns

Each finding takes five fields and fits in a paragraph:

• Entry point — where an attacker with a stated starting position begins.
• What they get — the concrete impact, in data or capability, not a category name.
• What stops them today — often "nothing except network reachability", which is the sentence that moves people.
• The one change that removes the path — naming the component, route or configuration.
• The cost — in engineer-days, so it can be planned against.

Then: state the attacker's starting position explicitly (unauthenticated internet, any pod in the namespace, a compromised low-privilege employee account), because impact without a starting position is not assessable. Cap the pack at what will be acted on, moving the rest to a backlog the security team owns. Keep already-mitigated paths in an appendix with the mechanism named, because the reason a path is blocked is the design constraint the next service must also satisfy. And require three fields on any accepted risk: a named accepter, a date and an expiry, after which it returns to the pack automatically.

Industry example

The form mirrors how published breach write-ups read after the fact. A postmortem of a data-exposure incident is always a path: this endpoint was reachable from there, a caller with this position saw that data, and nothing but an assumption stood in the way. Public reviews of cache and connection-pool bugs published since 2020 read exactly this way, and so do the findings that would have prevented them. A finding written as a path reads like the postmortem that would have followed it, which is what gets it fixed.

An archetype for the contrast: a healthcare platform serving two national health systems replaced a 40-finding scored register with eleven attack paths and fixed seven within two sprints, because each one named the route to change and cost between one and four engineer-days. The nine high-severity rows in the old register had been open for five months.

Failure scenarios

• The path is written without a starting position, so it reads as speculation and is dismissed.
• The "one change" is a programme ("adopt zero trust"), which cannot be estimated or scheduled.
• The cost is omitted, so the finding cannot compete with product work in planning.
• Accepted risks accumulate with no expiry, so the register becomes a record of findings that were deleted while looking managed.
• The security team writes the change without the owning engineers, and proposes a fix that the system's constraints rule out, spending credibility on a wrong recommendation.

Trade-offs

Attack-path framing costs more per finding to write, perhaps an hour each with the owning engineer, and it cannot cover 47 items. That is a feature disguised as a cost: the discipline forces the review to decide what matters, which the scored register let it avoid. It also gives up the comparability a numeric register offers to auditors and boards, who legitimately want a count and a trend.

The practical resolution is two artefacts from one review: the register for reporting, the paths for engineering. Producing both costs a day more than producing one.

When not to use it

Where a standard or an auditor mandates a scored register, keep it and produce the path pack alongside; fighting the mandated artefact spends credibility you need for the fixes. For a routine dependency-scan backlog, paths are over-engineered — the finding is "upgrade the library", the cost is known, and a list with versions is the right form. Attack paths are for findings that require judgement about reachability, which is where scores fail worst.

Interview question

Q: A thorough threat model produced 47 findings and two fixes in nine weeks. What would you change about the artefact, and how would you get the security team to agree to drop their scoring?

What a strong answer covers: the score as a product of two guesses that hides which one matters; arguability as the reason nothing moves; the five-field path form; the accepted-risk fields that make acceptance real; keeping mitigated paths as reusable design constraints; and the trade offered in the review so both sides give up something visible.

Quick check

Quiz: Why does a likelihood-impact score reduce action? It is a product of two guesses, so it hides which one is load-bearing, and it is arguable — so the meeting negotiates ratings instead of discussing fixes.

Flashcard: What five fields make a security finding actionable? Entry point, what the attacker gets, what stops them today, the one change that removes the path, and the cost of that change.