Ask each vendor which signals drive their priority order, show a worked example on your code, and explain how a user can override it. Good answers mention more than severity: known exploitation, exploit likelihood, and whether your code can actually reach the vulnerable function.
Why prioritization deserves its own section
Most teams do not suffer from a lack of findings. They suffer from too many. A tool that reports 4,000 issues with no useful order shifts the work to your engineers. In an RFP, prioritization is where tools differ most, so spend questions here.
Know the common signals
- Severity scores, such as CVSS, describe how bad a flaw could be, not whether anyone is exploiting it.
- CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of exploitation in the wild. CISA describes it as one input to prioritization, and each entry carries a due date for action.
- EPSS, from FIRST, is a model that estimates the chance a published CVE will be exploited in the wild in the next 30 days. It gives a daily score from 0 to 1 and a percentile, and the data is free to download.
- Reachability asks whether your application actually calls the vulnerable code. This is a property of your code, so no public feed can supply it.
None of these is a complete answer alone. Ask how the vendor combines them.
Questions to ask
- Which signals feed your priority ranking, and can we see the weighting?
- Do you use the KEV catalog, and how quickly does a new KEV entry change a finding's priority?
- Do you use EPSS or a similar likelihood score? Which version of the data, and how often is it refreshed?
- Do you perform reachability analysis? For which languages, and what does the tool report when it cannot determine reachability?
- Can users override priority, suppress a finding with a reason, and have that decision expire?
- Show one finding on our sample repository and explain, step by step, why it ranks where it does.
- How are new vulnerabilities for already scanned projects surfaced, without a new scan?
Question 6 is the most useful. A vendor who cannot explain one ranking in plain words probably cannot explain it to your developers either.
Test it, do not just ask
In the proof of concept, take 20 findings your team has already triaged by hand. Hide the answers, run the tool, and compare. Count how many of your "fix now" items land in the tool's top group, and how many of its top items you would have deferred. This is more convincing than any demo. The post on measuring false positives in a trial shows how to set it up.
Red flags
- A single proprietary risk number with no explanation
- No way to see why a finding was downgraded
- Claims that reachability removes all noise. It reduces noise, but it can also be wrong, so ask how a missed true positive would be caught
Safeguard offers reachability analysis and policy controls, and the free scan at https://gold.safeguard.sh/scan shows how findings appear on a public repository.
Sources
Quick check
Is a high CVSS score enough to prioritize a fix?
No. CVSS describes severity in general. Pair it with exploitation evidence and whether your code reaches the flaw.
Does EPSS replace KEV?
No. KEV lists vulnerabilities with evidence of exploitation. EPSS estimates likelihood for ones that may not be exploited yet. They answer different questions.
Last reviewed: 19 October 2026.
