Why is sorting a threat model's rated threats by score descending a poor fix order?

## The gap between a rating and a queue Rating answers "how bad would this be?". A fix queue has to answer "what should we do on Monday?". Those are different questions, and the second one takes inputs the rating never contained. A score descending sort silently asserts that severity is the only thing that matters and that every fix costs the same, which is never true. Five inputs beyond the score decide the real order. ## 1. Fix leverage — count coverage, not rows A modeled threat list is not a set of independent items. Several rows often share one root cause, and one change clears them all. In a session on an electric-vehicle charging back-office, thirty-one threats came out of one model; four of them collapsed into a single over-broad service role that a roaming partner's operator credential could assume — tariff adjustment, session cancellation, another operator's settlement data, and charger enrolment all rode on the same grant. Splitting that role into scoped identities is one piece of work that removes four rows. Ranked by score, three of those four sat mid-list; ranked by leverage, the shared fix is the first thing you do. The practical move is to cluster the list by root cause before ordering it. The unit of work is the **change**, not the threat, and the value of a change is the total risk it removes. ## 2. Effort and lead time A one-line configuration change and a quarter-long redesign do not belong in the same queue position just because they mitigate similarly-scored threats. Cheap band-reducers ship immediately; they are not a substitute for the redesign, but they buy time at almost no cost. And a long fix should *start* early precisely because it is long — sequencing it behind three cheap ones wastes its lead time. The right shape is usually: cheap mitigations ship now, the expensive one starts now on its own track, and nothing waits behind anything it does not depend on. ## 3. Irreversibility against a fixed date Some fixes get harder the longer you wait; some are equally easy forever. On an open-banking consent service with a fixed regulatory go-live, the ordering axis is not severity but **changeability after launch**. A consent record's data model, the scope granularity a third party is granted, and the audit trail's contents are all things you cannot quietly reshape once real delegated credentials and real payment mandates exist. A missing rate limit or a stricter token lifetime can ship the week after. So a mid-scored design decision that is baked at launch is pulled ahead of a higher-scored control that is easy to add later. "Can I still do this cheaply in three months?" is often a sharper ordering question than "how bad is it?". ## 4. Dependencies between mitigations Some mitigations only work once another exists. You cannot scope a service role usefully until the callers have distinct identities; you cannot enforce a per-tenant authorization check until requests carry a reliable tenant claim. A queue that puts the dependent fix first produces a sprint of half-done work. Order the enablers first even when they carry no score of their own — an enabler is not a threat, so it never appears in the rated list at all, which is exactly why a pure score sort loses it. ## 5. Confidence in the rating Ratings carry uncertainty and the score hides it. A High that rests on "we think that queue is reachable from the partner network" is worth less than a Medium everyone is certain of. The cheapest next action is often a half-day check that confirms or collapses the assumption, because it changes the order of everything below it. Treat "verify the assumption" as a schedulable item. ## Where the score does belong None of this makes severity irrelevant. It is the primary partition: the top band gets attention this cycle, the bottom band does not. Within a band — and bands are coarse by design — cost, leverage, dependency and deadline decide. A useful ordering pass looks like: cluster by root cause, keep only the highest band of each cluster as its severity, estimate effort per cluster, mark anything gated by a fixed date, then sort by removed-risk per unit of effort with the date-gated and dependency-enabling items pulled to the front. ## The failure this prevents The classic bad outcome is a team that spends a quarter on the single top-scored threat — usually the most architecturally expensive one — while eight mid-band threats that one afternoon of configuration would have removed stay open the whole time. The score was right and the order was wrong. An interviewer asking this is checking whether you can hold both facts at once: the rating is honest, and the rating is not the plan.