A vulnerability management tool should give you a complete inventory, rank findings with exploitation evidence instead of severity alone, show a fix path, route work to owners and keep dated evidence. Judge it on how well it prioritises and closes findings, not on how many it finds. No tool removes the need for human decisions.
This guide describes categories and criteria. It does not rank vendors, and you should test any tool on your own code.
What should it find first?
You cannot manage what you cannot see. Ask how the tool builds its inventory. For software, that means direct and indirect dependencies across your package managers, container layers and any binaries or vendor SBOMs you receive. Ask what it misses: private registries, vendored code and build time tools are common gaps.
How should it rank findings?
Severity scores alone create long lists. Look for these signals, which are public and well defined.
Known exploitation. CISA's Known Exploited Vulnerabilities catalogue is described by CISA as the authoritative source of vulnerabilities exploited in the wild, and it tells organisations to use it as an input to prioritisation. Each entry carries a due date.
Probability of exploitation. EPSS, from FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. Scores run from 0 to 1 and are published daily for every CVE. It is a probability, not a verdict.
Decision logic. CISA's SSVC decision tree uses five decision points: exploitation status, technical impact, automatable, mission prevalence and public well-being impact. Its outcomes are Track, Track star, Attend and Act. Ask whether a tool lets you set your own rules in this spirit.
Reachability. Is the vulnerable code actually called in your application? Reachability analysis separates the library you ship from the function you run. Safeguard includes reachability analysis, and you should ask any vendor how it is computed and what it cannot see.
What about fixing?
A finding without a path is a ticket. Look for the fixed version, whether the upgrade is a patch, minor or major change, and a way to open a pull request or a clear manual step. Ask how breaking changes are flagged and whether you can run in a mode where nothing changes without review.
What operational features matter?
Ownership routing so each finding reaches a team. Integration with your issue tracker and chat. Policy gates for CI and pull requests that you can start in warn mode. Exceptions with an owner and an expiry date. Exports in open formats, since SARIF is an OASIS standard for static analysis results and CycloneDX or SPDX cover inventories.
Deployment options also matter: some teams need scans that run on their own machines or in an isolated network. Safeguard offers a local runner for that, and also runs in Full AI, Zero AI or bring your own model modes, so check any tool for similar control over where data and models go.
What are the honest limits?
Scanners depend on advisory data, and advisories lag. A zero day will not be in any feed. EPSS and KEV describe what is known, not what is next. Reachability analysis can be conservative and mark a finding reachable when it is not. Prioritisation reduces the list. It does not make it empty.
Compare tools by running them on the same repository and reviewing the top twenty findings by hand.
What to do
- Write your inventory requirements: ecosystems, containers, vendor SBOMs, binaries.
- Run a trial on one real repository and count what each tool misses.
- Check that ranking uses KEV, EPSS and reachability, and that you can explain a ranking to an engineer.
- Test fix paths on five real findings.
- Confirm exports, API access and where data is stored.
- Set a target for time to fix by severity and measure it after 90 days.
Quick check
Is a high CVSS score enough to prioritise?
No. Severity does not say whether a flaw is exploited. Combine it with the KEV catalogue, EPSS and whether the vulnerable code is reachable in your application.
What does EPSS predict?
The probability that a published CVE will be exploited in the wild within the next 30 days, as a score from 0 to 1.
Sources
- CISA: Known Exploited Vulnerabilities Catalog
- FIRST: EPSS
- CISA: Stakeholder-Specific Vulnerability Categorization
- OASIS: SARIF v2.1.0
Last reviewed: 18 October 2026.
