How to Prioritize Vulnerabilities

The first time you run a security scan and get a hundred findings, the natural reaction is to freeze. You cannot fix everything today, and trying to would burn you out on issues that do not matter. The skill that separates effective security work from busywork is prioritization: fixing the few findings that actually put you at risk before the many that do not. This guide gives beginners a simple, defensible order to triage in, using signals you can get from a scanner today.

What you will accomplish

You will take a raw, unordered list of findings and turn it into a short, ranked worklist, with clear reasons for why each item sits where it does.

Prerequisites

• A recent scan with a list of findings. If you do not have one, run sg scan first.
• The Safeguard CLI, installed in Step 1.
• A willingness to leave low-risk findings alone for now. That is a feature, not neglect.

Step 1: Get your findings in one place

curl -sSfL https://get.safeguard.sh/install.sh | sh
sg scan

Note the total count. The goal of the next steps is to shrink that total into a handful you act on this week.

Step 2: Sort by severity first

Severity, usually expressed as a CVSS score from 0 to 10, is your coarse first filter. Start with critical and high; push medium and low down the list:

sg scan --min-severity high

Severity alone is not the whole story, but it is the right first cut. A critical-rated remote code execution belongs above a low-rated information leak every time.

Step 3: Factor in exploitability

Two findings with the same severity are not equally urgent if one is being actively exploited in the wild and the other has never been weaponized. Two signals help here:

• EPSS, a probability score that a vulnerability will be exploited soon.
• KEV, the Known Exploited Vulnerabilities catalog, a list of issues confirmed to be exploited in real attacks.

Anything on the KEV list jumps to the top of your worklist regardless of its base severity, because attackers are already using it.

Step 4: Ask whether the code is reachable

This is the step that eliminates the most noise. A vulnerability in a package you install but never actually call is far lower risk than one on a code path your app runs on every request. Reachability analysis answers this for you:

sg scan --reachable-only

A critical finding in dead code can often wait, while a high finding your entrypoint calls cannot. Reachability is frequently the difference between a hundred findings and the five that matter.

Step 5: Consider exposure and data sensitivity

Finally, weigh context that no scanner fully knows:

• Is the affected service exposed to the internet, or only reachable inside a private network?
• Does it handle sensitive data such as credentials, payment details, or personal information?

An internet-facing service that touches customer data raises the priority of every finding on it. An internal batch job with no sensitive data lowers it.

Step 6: Write your ranked worklist

Combine the signals into a simple order. A practical ranking for beginners:

1. On the KEV list, or reachable and critical.
2. Reachable and high, especially on internet-facing or sensitive services.
3. High but not reachable, or reachable medium.
4. Everything else, tracked but not urgent.

Fix from the top. Re-scan after each fix and let the list re-rank itself.

How to know it worked

• Your action list for this week is short, on the order of a handful of items, not a hundred.
• You can state a one-sentence reason for the rank of your top item, such as "reachable, critical, internet-facing."
• The findings you deferred are recorded somewhere, so they are deprioritized, not forgotten.

If you can point at your number-one item and defend why it comes first, you have prioritized correctly.

Next steps

1. Set thresholds so your build fails on the categories you decided are urgent, and only those.
2. Revisit deferred findings on a schedule, because reachability and exploitability change over time.
3. Learn the scoring systems in depth, including how CVSS, EPSS, and KEV relate, in the concepts library.
4. Document your policy so the whole team ranks the same way.

Reachability is the single biggest noise reducer, and you can read how it works under software composition analysis. When the ranked list still feels long, Griffin AI can triage findings and draft fixes for the top items so you review rather than research. Compare what different tiers include on the pricing page, and build the habit with the Safeguard Academy.

Frequently Asked Questions

Should I always fix critical vulnerabilities first? Usually, but not blindly. A critical finding in code your application never actually executes can be lower real risk than a high finding on your main request path. Severity is the right first cut, then reachability and exploitability refine the order. A critical on the Known Exploited Vulnerabilities list, however, should jump straight to the top.

What is reachability and why does it matter so much? Reachability tells you whether the specific vulnerable function is actually invoked along a path your app runs. It matters because a large share of findings are in code you install but never call, so filtering to reachable findings often shrinks a hundred alerts down to the few that are genuinely exploitable.

What are EPSS and KEV? EPSS is a score estimating the probability that a vulnerability will be exploited soon, and KEV is a public catalog of vulnerabilities confirmed to be exploited in real-world attacks. Together they tell you not just how bad an issue could be, but how likely it is to actually be used against you.

Is it okay to leave some vulnerabilities unfixed? Yes, as long as it is a recorded, intentional decision rather than something you forgot. Every team defers low-risk findings; the discipline is to track them, set a threshold for what must be fixed, and revisit the rest periodically since their risk can change.

Want your findings ranked by real risk automatically? Create an account at app.safeguard.sh/register, and sharpen your triage skills in the Safeguard Academy.