With two engineers and no security team, triage a backlog by asking four questions of every finding: is it reachable, is it exposed to the internet, does it touch sensitive data, and is a fix available now. Fix the few that answer yes to most, schedule some, and close the rest with a written reason.
Why severity alone fails
A scanner's severity score describes the flaw in general. It does not know whether your code calls the vulnerable function, whether the service faces the internet, or whether anything valuable sits behind it. Teams that fix in score order burn weeks on issues that cannot be reached.
The four questions
- Reachable: does your code actually use the vulnerable component or path?
- Exposed: is the service reachable from the internet, or only from inside?
- Sensitive: does it handle customer data, credentials or payments?
- Fixable: is there a patched version or a simple config change today?
Give one point for each yes. Add a point if the issue is known to be exploited in the wild, which you can check in public catalogues of exploited vulnerabilities such as the one CISA maintains.
What to do with the score
- Four or five points: this week, stop other work if needed.
- Two or three: in the next sprint, with a named owner.
- Zero or one: close or accept, with a reason and a review date.
The written reason matters. When a customer or auditor asks why something stayed open, the note answers it.
Cap work in progress
Two engineers can handle two or three security items at once. Put a cap on the board. A queue that is limited and owned gets finished. A list with fifty items does not.
Make fixes cheap
Batch dependency upgrades weekly. Keep tests that catch breakage so upgrades are low risk. Prefer removing unused packages to patching them.
Where tooling helps
Reachability analysis answers the first question automatically for dependencies, and is the largest single reducer of noise. Safeguard offers it, along with fix pull requests that stay under your control. This demo shows the idea.
Click through it at your own pace, or open it full screen.
Common pitfalls.
Common mistakes: treating the scoring as precise when it is only a way to sort, re-scoring everything each week, and letting the same item sit in the top bucket for months. If something has been urgent for a month, either it is not urgent or the team lacks capacity, and that second case is a message for leadership. Review the closed with reason list each quarter, because conditions change. A service that was internal can become exposed, and a deferred item may then deserve a fresh look.
Finally, share the result. A short note to the wider team saying what was fixed this month, and what was deliberately deferred, builds trust and makes the next trade off conversation easier.
Quick check
Can we ignore low severity findings?
You can defer them with a reason. Combined with exposure and exploit evidence, a low item can still matter.
Last reviewed: 19 October 2026.
