To rank hundreds of vulnerabilities, ask four questions of each one: is it being exploited, can the vulnerable code be reached, is the system exposed, and how much does the system matter. Fix the items with the most yes answers first and schedule the rest.
TL;DR
- Most findings never become real attacks, so do not treat all of them equally.
- Ask four questions in order: exploited, reachable, exposed, important.
- Score each yes as one point. Fix the highest scores first.
- Record a decision for every item you defer, with a review date.
Why does a long list of vulnerabilities feel impossible?
A first scan can return hundreds of findings. Each one has a label like High or Critical, so everything looks like an emergency. If everything is an emergency, nothing gets done.
The good news is in the numbers published by FIRST, the non-profit behind the EPSS model. In its FAQ, FIRST says that in any 30 day window roughly 2.5 to 3 percent of published flaws are seen being exploited, and that the CISA Known Exploited Vulnerabilities catalog lists roughly 0.5 percent of published flaws. Put plainly, only a small slice of all known flaws ever gets used in real attacks. Your job is to find your small slice.
A vulnerability is a flaw in software that could be misused. A finding is one report from a scanner that a flaw exists in something you run. One flaw can create many findings if it appears in many places.
What are the four questions?
Question 1: Is it being exploited?
This is the strongest single signal. CISA keeps the Known Exploited Vulnerabilities catalog, called KEV. A flaw joins it only when it has a CVE ID, there is reliable evidence of exploitation in the wild, and there is a clear fix action. CISA recommends that organizations use the catalog as an input to their prioritization framework.
You can also look at EPSS, which estimates the probability that a flaw will be exploited in the next 30 days. FIRST explains that a score of 0.05 means about 1 in 20 similar flaws will see exploitation activity, and that because the base rate is so low, even a 5 percent score ranks in roughly the top 10 percent of all scored flaws. So small numbers can still be meaningful.
Give one point if the flaw is on KEV, or if its EPSS score is high compared with your other findings. Learn more in EPSS scores in plain language and the CISA KEV catalog guide.
Question 2: Can the vulnerable code be reached?
Software often includes whole packages where you only use a small part. If the flawed function is never called by your program, the flaw cannot be triggered through your program. Checking this is called reachability analysis. Read the reachability FAQ for how it works and where it can be wrong.
Give one point if the vulnerable code is reachable or if you cannot tell. When unsure, assume yes.
Question 3: Is the system exposed?
A flaw on a server that anyone on the internet can contact is easier to attack than a flaw on a machine that only a few staff can reach. Exposure includes public websites, public application programming interfaces (APIs, which are doors that other programs use to talk to yours), and anything reachable from outside your network.
Give one point if the system is exposed to the internet or to untrusted users.
Question 4: Does the system matter?
Consider what is at stake. A system that handles customer data, money, or the ability to run your business matters more than a test tool. Keep it simple with three levels and give one point for the top level.
How do you turn answers into an order?
Add the points. The maximum is four.
| Points | What it means | What you do |
|---|---|---|
| 4 | Exploited or likely to be, reachable, exposed, important | Fix now, this week |
| 3 | Three of four | Fix this sprint |
| 2 | Two of four | Fix in the next cycle, or when touching the code |
| 0 to 1 | Low practical danger | Track with a review date |
One override: anything on KEV that runs in your environment moves up a level, because someone is already using it against real targets.
CVSS severity still helps. Use it to break ties inside a group, but remember that FIRST says a base score measures severity and should not be used alone to assess risk. Our post on what a CVSS 9.8 tells you goes deeper.
A worked example with invented numbers
The numbers below are invented to show the method. They do not describe any real company.
A team scans five applications and gets 500 findings. They run the four questions in a spreadsheet, filtering one column at a time.
| Step | Filter | Findings left |
|---|---|---|
| Start | All findings | 500 |
| 1 | Exploited (KEV or high EPSS) | 12 |
| 2 | Of those, vulnerable code reachable or unknown | 9 |
| 3 | Of those, system exposed | 6 |
| 4 | Of those, important system | 4 |
That gives:
- 4 findings with four points: fix this week.
- Several more with three points, found by counting across the filters: suppose 30 findings. These are fixed this sprint.
- Suppose 90 findings with two points: fix in the next cycle.
- Suppose 376 findings with zero or one point: tracked, reviewed monthly.
The team now has a clear start: four items this week. In a list of 500, that is the difference between being stuck and making progress. The 376 low items are not forgotten. They are recorded and reviewed.
What if a finding has no fix yet?
Sometimes there is no patched version. Then you have three options: reduce exposure, turn off the vulnerable feature, or accept the risk for a short time with a recorded reason and an end date. See ageing vulnerabilities: when to fix versus mitigate and accepting an unfixable vulnerability.
How often should you re-rank?
Rankings change. A flaw with a low EPSS score today may be added to KEV next month. CISA's catalog keeps growing. At the time we reviewed it, the catalog page showed 1748 entries. So re-run the ranking weekly, or automatically whenever new data arrives.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many findings drop out of the urgent list once you ask whether the vulnerable code is actually used.
How can Safeguard help?
Safeguard produces an SBOM and scans your dependencies, then runs reachability analysis to show which findings sit in code your application uses. You can write policies and gates so that your own ranking rules become automatic checks on pull requests. For flaws with a fix, autonomous remediation can open a fix pull request. It is off by default, and every category starts on Manual, so nothing changes without a person turning it on. Try the free scan at gold.safeguard.sh/scan.
Quick check
Do I need special tools to use the four questions?
No. A spreadsheet works for a first pass. Tools help by filling in the exploited and reachable answers automatically and by keeping the list fresh.
What if I cannot tell whether code is reachable?
Treat it as reachable and score the point. You can lower the score later once you confirm the code path is not used.
Is EPSS or KEV better for the exploited question?
They answer slightly different things. KEV lists flaws with evidence of real exploitation. EPSS estimates the chance of exploitation in the next 30 days. Using both is reasonable.
Does a low score mean I can ignore the finding?
No. It means the finding can wait. Keep it on the list with a review date, since the facts can change.
Sources
- FIRST, EPSS Frequently Asked Questions
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
- CISA, Known Exploited Vulnerabilities Catalog
- FIRST, CVSS v4.0 User Guide
Last reviewed: 19 October 2026.
