When your first scan finds hundreds of vulnerabilities, fix in this order: items attackers are already using, then items your code can actually reach, then the most severe, then anything with an easy fix. Most of the list will not need action this week. A short, ranked list beats a long, flat one.
TL;DR
- A big first number is normal. It does not mean your software is broken.
- Rank findings by five questions: Is it being exploited? Can my code reach it? Is it exposed to the internet? How severe is it? Is there a fix?
- Reachability analysis checks whether your code calls the risky part. It can take the urgent list from hundreds down to a handful.
- Keep a written record of what you decided not to fix, and why.
Definition: Reachability analysis traces the paths your own code takes into a library and checks whether any path leads to the vulnerable function. If no path leads there, the flaw is present in your files but your program never runs it.
Why is the first list so long?
A modern project pulls in many packages, and each package pulls in more. Safeguard's own explanation of reachability says it plainly: a dependency scan lists every known CVE in every package you ship, including code your service never calls.
A CVE is a public ID for a known flaw. A first scan is also the first time anyone has counted. Nothing got worse today. You are simply looking at old problems for the first time, like finding a drawer of unpaid bills after a move.
Three things inflate the number:
- Indirect packages. You chose ten packages. They brought two hundred more. See our post on direct versus transitive dependencies.
- Duplicates. One flaw in one package can appear once per project or once per image layer.
- Unused code. Many packages contain functions you never call.
Knowing this changes the goal. You are not trying to reach zero today. You are trying to find the few items that could hurt you soon.
What are the five questions to ask?
Work through these in order. Each question removes items from the "urgent" pile.
1. Is anyone exploiting it right now?
Some flaws are known to be used in real attacks. Others are only theoretical. Two public signals help. KEV is a list kept by the US cyber agency CISA of flaws seen exploited in the wild. EPSS is a score that estimates how likely a flaw is to be exploited soon. The Safeguard documentation lists both as inputs. Our CVSS, EPSS and KEV FAQ explains them.
If a flaw in your list is on KEV, move it to the top. Exploitation is not a guess any more.
2. Can my code reach it?
This is reachability. The Safeguard documentation describes several kinds. Static reachability builds a map of calls from your source and checks whether any path leads to the vulnerable spot. Dynamic reachability watches what your running software actually loads and calls. Each finding can then be marked reachable, conditionally reachable, unreachable or unknown.
Imagine a hardware store with a faulty power drill in a back room. If your shop never sells or uses that drill, it can wait. If you use it every day, it cannot.
The honest limit is that the analysis is not perfect. When it cannot decide, for example with reflection or native code, the documentation says it is marked conservatively as potentially reachable. So treat "unreachable" as "lower priority", not as "ignore forever".
For more on why this matters, see our post on prioritizing CVEs with reachability.
3. Is the affected thing exposed?
A flaw in a service open to the internet matters more than one in a tool only used on a laptop. A flaw in the live app matters more than one in a test script. Ask where the package runs and who can talk to it.
4. How severe is it?
CVSS is a 0 to 10 score of how bad a flaw could be in general. It is a fine tiebreaker, but a poor first filter. A 9.8 in code you never run is less urgent than a 7.5 that is already being exploited in a service on the internet.
5. Is there a fix, and is it small?
A fixed version is usually the cheapest path. Look for upgrades that change only the patch or minor part of the version number. Those rarely break things. A major version upgrade can break your code and needs more testing.
The Safeguard fixes demo groups available fixes into compatible, minor and major upgrades and marks the ones that may break your code. That is a useful way to batch work.
How do the five questions look as a table?
| Question | If yes | If no |
|---|---|---|
| Exploited in the wild? | Move to the top | Continue |
| Reachable by my code? | Keep high | Lower priority, note it |
| Exposed to the internet or customers? | Raise priority | Lower priority |
| Severe? | Keep in the queue | Park it |
| Easy fix available? | Do it in the next batch | Plan it, or consider another option |
You do not need a perfect score. You need a sensible order and a written reason for each choice.
What does this look like with invented numbers?
The numbers here are invented to show the method.
Your first scan lists 400 findings.
| Step | Findings left | What you did (invented) |
|---|---|---|
| Start | 400 | Raw list |
| Remove duplicates | 310 | The same flaw counted in several places |
| Keep reachable or unknown | 70 | Reachability marked 240 as unreachable |
| Keep high or critical | 18 | Dropped medium and low for now |
| Keep internet facing or exploited | 9 | Dropped items only in internal tools |
You now have 9 items for this week, not 400. Of the 9, you find fixed versions for 6, so six small upgrades go into one pull request. For the other 3, you write down the plan: upgrade next sprint, replace the package, or add a protective setting.
The other 391 findings are not forgotten. You parked them with a reason and a review date.
How do I record what I chose not to fix?
This step is easy to skip, and it saves arguments later. For each parked item, write down:
- what the finding is and where it lives,
- why you are not fixing it now (for example "not reachable", "internal tool only"),
- who decided, and
- when you will look again.
Safeguard's policy tools include an exception workflow: someone requests an exception, picks the policy and the finding, gives a reason and an expiry date, an approver decides, and the audit trail records it. Even if you do this in a spreadsheet at first, keep the expiry date.
Where do I look at all this in Safeguard?
Safeguard shows each product's vulnerabilities in one queue, with the signals that set priority and a clear status for each finding. The docs describe a Priority column and a Reachability column, and filters for reachable findings and for KEV listed ones. They also say the weights are configurable per tenant, so teams can tune the order.
Safeguard offers these generally available capabilities that match the steps above:
- Reachability analysis to mark findings as reachable or not.
- SBOM and dependency scanning to list everything you ship.
- Policies and gates to stop new critical findings from merging.
- Autonomous remediation with fix pull requests, off by default with every category on Manual, for the small fixes in step 5.
You can start without any account: the free scan at gold.safeguard.sh/scan checks up to 100 dependencies from a pasted file or an SBOM. For bigger projects, the Safeguard CLI scans a whole folder on your machine, and its assistant can also write code to apply a fix. See our CLI guide.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the seven steps and look for how the list shrinks once your own call paths are traced into each vulnerable function.
Quick check
Is a long first scan a sign my software is unusually bad?
No. Most projects carry many known flaws in indirect packages. The list is long because it is the first count, and because it includes code your program may never run.
Should I fix by CVSS score alone?
It is a weak first filter. A high score in code you never call can matter less than a medium score in a service that is exposed and being exploited. Use CVSS as a tiebreaker.
Can I ignore anything marked unreachable?
Not forever. It is lower priority, not zero. The analysis can be uncertain, and code changes over time, so a flaw that is unreachable today may be reachable after a refactor. Record it and review it.
What if there is no fixed version?
Look at options in this order: remove or replace the package, change how you use it so the risky part is not called, or accept the risk with a written reason and an expiry date.
Sources
- Reachability cuts the noise demo
- Vulnerability prioritization documentation
- Fixes available now demo
- Policies and gates documentation
- Safeguard Gold, Free Dependency Scan
Last reviewed: 19 October 2026.
