Which security debt to pay first: a decision guide

Pay first the security debt that attackers can actually reach, that gets more expensive each month, and that blocks other work you want to do. Ask four questions in order for each candidate. The answers will not give a perfect ranking, but they will stop you from fixing the loudest item instead of the important one.

Question 1: can it be reached?

A weakness in code that never runs, or in a service no untrusted party can contact, is a different animal from one on your public edge. Start by asking whether an outsider, or a compromised insider account, could plausibly trigger it.

For dependency issues this is often answerable with data. Reachability analysis shows whether your code calls the vulnerable function at all. Findings that are not reachable can move down the list, with a note to recheck when the code changes.

Question 2: how bad is the worst case?

Imagine the weakness is used. What is lost: one user's data, all customers' data, the ability to deploy code, or nothing sensitive? Rank by the worst realistic outcome, not the worst imaginable one. A flaw that exposes build credentials usually outranks one that leaks a harmless setting.

Question 3: does it get worse by waiting?

Some debt is static and some accrues interest. Falling behind on a framework's supported versions is a clear case: the longer you wait, the larger the upgrade and the closer you get to unsupported software. Static items can wait for a quiet sprint. Compounding ones deserve an earlier slot.

Question 4: what does it unblock?

Look at what fixing the item would make easier. Replacing a hand-rolled authentication layer might remove a dozen smaller findings. Upgrading a base image might clear a long run of scanner alerts at once. Prefer items with a high payoff beyond their own risk.

Put it together

Score each candidate on the four questions with a simple yes, no or partly, then sort. Two or three items usually rise to the top. Schedule those, state the cost, and move on.

A short worked example: the team has three open items.

1. An outdated image library with many findings, none reachable.
2. A shared service account with no rotation, used by the deploy pipeline.
3. A framework two major versions behind.

Item 2 wins on reach and worst case. Item 3 follows because it compounds. Item 1 waits, with a recheck after the next dependency change.

Try it yourself

The demo below shows how reachability narrows a long list of findings to the few that matter. Click through and compare the list before and after the reachability step.

Click through it at your own pace, or open it full screen.

Avoid these shortcuts

• Ranking only by severity score. It ignores reach and context.
• Fixing the oldest first. Age matters only if it adds risk.
• Paying down whatever is easiest. Easy items feel productive and leave the hard ones untouched.

Safeguard offers reachability analysis for dependency findings, and the free scan is a quick way to see how your own list changes once reach is considered.

Quick check

Last reviewed: 19 October 2026.