You inherit a large application portfolio and a backlog of security findings spread across the OWASP Top 10 categories. How do you decide the order of work, and why is the list's own ranking a poor prioritisation input?

## Why the published order is the wrong input The list ranks categories using incidence measured across a sampled corpus of applications, combined with generic exploitability and impact weightings. Every term in that computation is about a population, not about your system. Your portfolio has a specific exposure surface, a specific data classification and a specific privilege topology. Two applications with identical findings can differ by orders of magnitude in risk because one sits behind an internal network and mutual authentication and the other is public. Using an industry ranking as a work order is substituting someone else's prior for your own evidence. There is a second, subtler problem: **your backlog is itself a biased sample**. It contains what your tooling can see, and the tooling is strongest exactly where the taxonomy is weakest. A backlog with two hundred dependency findings and no access-control findings is far more likely to mean nobody modelled authorisation than that authorisation is sound. So the first prioritisation act is often not to rank the backlog but to close the coverage gap that the backlog's shape reveals. ## The four ranking axes **Reachability.** Who can invoke the path? Unauthenticated internet-facing beats authenticated user-reachable, which beats operator-only, which beats reachable only by an internal batch job with vetted inputs. This is the single most discriminating axis and the one most often skipped, because tooling reports the defect at its location rather than at its entry point. Tracing from an untrusted entry to the sink is real work and it is worth doing before the ranking, not after. **Privilege of the executing principal.** The same defect has wildly different consequences depending on what the process holds when it is exercised. A code path running with a narrowly scoped read-only credential and a code path running with an ambient administrative identity are separated by a factor that no severity score assigned to the defect class captures. This axis also tells you the cheap mitigation: reducing the principal's privilege caps the impact of every current and future finding on that path without fixing any of them. **Data sensitivity and blast radius.** What is reachable once the boundary is crossed — a public catalogue or the credential store? Does crossing enable *pivot* (reach another system) or *persistence* (survive the fix)? Findings that yield credentials, tokens, signing keys or code execution in a build pipeline dominate everything else, because they convert a bounded incident into an unbounded one. This is why integrity failures in the supply chain rank far above their raw frequency: compromising what produces the artefact compromises every deployment of it. **Fix durability and cost.** Prefer fixes that remove the class. If twelve findings share a root cause — no central authorisation choke point, no managed HTTP client for outbound fetches, hand-rolled query construction in one utility — the structural change is one unit of work that also prevents the thirteenth. Individually patching twelve instances is more expensive and leaves the generator running. Conversely, some categories are cheap and continuous by nature: dependency currency and configuration baselines are pipeline problems that, once automated, cost almost nothing per unit and should not be sequenced behind design work at all. ## Sequencing, not just ranking A portfolio plan has dependencies. **Logging and monitoring failures come early** despite modest headline severity, because without them you cannot tell whether anything else is being exploited, cannot verify a fix in production, and cannot detect the residual risk you consciously accepted. **Inventory comes before everything**: you cannot rank exposure across services you cannot list, and unknown services are systematically the worst configured. **Automatable categories run in parallel** with the modelling work rather than competing with it, because they consume different people. And a **structural control that fails closed** — a deny-by-default authorisation point, an egress proxy for outbound fetches, an enforced managed data-access layer — earns its priority by making the *next* finding of that class impossible rather than by closing the current one. ## Using the taxonomy correctly here The list still has a job in this exercise, just not as a work order. It is a **completeness check**: walk the ten categories against the portfolio and ask what evidence exists for each. Silence in a category is a finding about your assurance coverage. And it is a **communication frame**: risk owners who cannot follow a discussion of an ownership predicate can follow "broken access control, our top category, in the customer portal". Using it to name and group the work while ranking the work on your own reachability, privilege, data and cost analysis is the combination that survives review.