Vulnerability prioritization: how to decide what to fix first

Why severity alone does not work

The default is to sort by CVSS and work down from critical. It feels objective, and it fails for three reasons:

• CVSS measures severity, not risk. It describes how bad a vulnerability would be if exploited. It does not say whether anyone is exploiting it, or whether it matters in your product.
• Too much of the list is urgent. Many published CVEs score high or critical, so a queue sorted by CVSS puts hundreds of findings at the top and gives no way to choose between them.
• The list is only as good as the inventory. A scanner that reads a lockfile reports development dependencies that never ship, and misses packages the build downloaded outside the package manager. Both distort the ranking before it starts.

Prioritization adds the missing questions: is it being exploited, how likely is it to be, and what happens to you if it is.

The signals

Signal	Question it answers	Source
CVSS	How severe is it if exploited? Scored 0 to 10.	FIRST (the standard); NVD and vendors publish scores
EPSS	How likely is exploitation in the next 30 days? A probability from 0 to 1.	FIRST, updated daily, free
CISA KEV	Is it already exploited in the wild?	CISA's Known Exploited Vulnerabilities catalog
SSVC	Given exploitation, impact and your mission, what should you do: track, attend or act?	CERT/CC and CISA decision trees
Your context	Does the vulnerable version ship? Is it exposed? How important is the product? Is there a fix?	Your inventory, architecture and asset records

The public signals describe the vulnerability. Only your context describes your risk, and it is the part most teams get from the least reliable source.

A practical prioritization method

Most programs end up with some version of these tiers. Set the timelines to what your policy and customers ask.

1. Fix now: known exploited, in software you ship. Anything on the KEV list, or with other evidence of exploitation, that is present in a released build. For comparison, CISA's BOD 26-04 gives US federal agencies as little as 3 days for a KEV entry on a publicly exposed system.
2. Fix next: likely to be exploited and severe. A high EPSS score combined with high or critical CVSS, in a shipped and exposed component. Pick an EPSS threshold that gives a queue your team can actually clear.
3. Fix routinely: everything else that ships. Batch it into regular dependency upgrades instead of handling each finding as an incident.
4. Document: not affected. The vulnerable package is present but the vulnerable code is not used, or the component does not ship. Record the reasoning as a VEX statement, so the same finding does not come back for review, and so customers who ask can see why.

Then re-rank continuously. A vulnerability that sat in tier three can move to tier one overnight when it is added to KEV or its EPSS score jumps.

The vulnerabilities you never get to rank

Every prioritization method ranks the findings in front of it. A vulnerable package the scanner never saw produces no finding, so it never gets a CVSS score, an EPSS score or a KEV match. It is not ranked low. It is not ranked at all, and it ships anyway.

This happens more often than it sounds, because most scanners work out what is in your software from files: the lockfile, the manifests, or the build's output. Anything the build fetches that no lockfile lists is a hidden dependency, and file-based tools miss it:

• Install hooks. Code downloaded by npm preinstall and postinstall scripts, the route the Shai-Hulud worm used.
• Build scripts. Rust build scripts, for example, that download code at build time.
• Base images. The base image of a container build and its operating system layers.
• Caches. Packages restored from a CI cache instead of installed from the lockfile.

Scanning the output afterward does not close the gap. A finished binary, especially compiled code such as Rust, leaves the scanner guessing what went into it. And because builds are not reproducible by default, rebuilding the same commit later is no guarantee of the same dependencies.

A build-time SBOM starts from the other end. CRACI runs your GitHub Actions jobs and sees the traffic coming into each build, so it records every package the job actually pulled in, hidden dependencies included. Each SBOM carries a completeness state that says when something could not be seen. In practice, CRACI has found vulnerable packages that Snyk and Aikido did not report, because their scans were missing the components. Those are exactly the findings a prioritization method never gets the chance to rank.

Context: the part scanners cannot score for you

Does the vulnerable version actually ship?

This is the question that removes the most noise. A test framework in a lockfile, a package pinned in a branch that never releases, a container stage that is thrown away: none of them reach customers. An SBOM recorded during the build answers the question from what the release build actually used, rather than from what the repository declares.

Which releases contain it, and since when?

A finding in a product you ship to customers, with every release since last spring affected, outranks the same finding in an internal tool. Knowing the exposure period also tells you what to disclose.

Can the vulnerable code be reached?

Reachability analysis traces whether your code can call the vulnerable function in a dependency. Several SCA tools offer it, and it is effective at pushing unreachable findings down the list. Treat it as one input: it only sees code paths the analysis can follow, and a reachable function is not the same as an exploitable one.

Is it exposed, and is there a fix?

An internet-facing service ranks above a batch job on a private network. A vulnerability with a fixed version is cheaper to close than one that needs a mitigation. Both change the order, not whether it gets handled.

Risk-based vulnerability management

Risk-based vulnerability management is the program-level name for the same idea: rank by exploitation evidence, likelihood, severity and business context, measure how fast the riskiest findings close, and accept that low-risk findings may stay open. The metrics change with it. Instead of the total count of open vulnerabilities, track how many known exploited vulnerabilities are open in shipped software, and how long they stay open.

Vulnerability prioritization tools

Three kinds of tools do most of the ranking today:

• Infrastructure vulnerability management platforms such as Tenable, Qualys and Rapid7 score hosts, endpoints and cloud assets with their own risk ratings, built on exploitation intelligence.
• SCA and application security tools such as Snyk, Endor Labs and Semgrep rank dependency findings, several of them with reachability analysis.
• Open-source tools such as Grype, which reports EPSS and KEV data with its findings, and Dependency-Track, which analyzes SBOMs continuously.

Vulnerability management tools compared goes through them one by one.

How CRACI supports prioritization

CRACI starts where the ranking goes wrong most often: the inventory. It runs your GitHub Actions jobs and records the packages each job actually fetched, including transitive dependencies, packages restored from caches and hidden dependencies that no lockfile lists.

• Findings for what shipped. Monitored SBOMs are re-evaluated continuously, and organization views aggregate findings across builds and repositories. Each package shows its advisories with severity and the packages that pull it in.
• Exposure period. Build history shows which past builds contained a vulnerable dependency, direct or transitive, so you know which releases were affected and for how long.
• Triage and routing. Security teams triage findings and send each one to the team that owns the fix. CRACI supports VEX for recording that a vulnerability does not affect your product.
• Gates. Policy gates can block a build on findings, including a build that contains a specific CVE.

CRACI does not offer reachability analysis. If that is the signal you need most, choose one of the SCA tools that offer it. See vulnerability tracking for the full capability.

Vulnerability prioritization: frequently asked questions

What is vulnerability prioritization?

Vulnerability prioritization is deciding which known vulnerabilities to fix first, which can wait and which do not affect you at all. It ranks findings by how likely they are to be exploited and how much damage that would do in your environment, not by severity alone.

How do you prioritize vulnerabilities?

Start from an accurate inventory, so you rank vulnerabilities in software that actually ships. Put anything on CISA's Known Exploited Vulnerabilities list first, then rank the rest by exploitation likelihood (EPSS) and severity (CVSS), adjusted for your context: exposure, the importance of the product and whether a fix exists. Record the ones that do not affect you as VEX statements.

Is CVSS enough to prioritize vulnerabilities?

No. CVSS measures how severe a vulnerability is, not how likely it is to be exploited or how much it matters to you. Ranking by CVSS alone marks a large share of the backlog as high or critical, and most of those vulnerabilities are never exploited.

What is risk-based vulnerability management?

Risk-based vulnerability management ranks and fixes vulnerabilities by the risk they pose to your organization, combining exploitation evidence, likelihood, severity and business context, instead of working through them by CVSS score or age.

What is the difference between EPSS and KEV?

EPSS is a forecast: the estimated probability that a CVE will be exploited in the next 30 days. KEV is a record: CISA's catalog of vulnerabilities with evidence of exploitation in the wild. A KEV entry is a fact; an EPSS score is a likelihood. Use KEV first and EPSS to rank everything else.

Does reachability analysis replace prioritization?

No, it is one more input. Reachability checks whether your code can call the vulnerable function in a dependency. It removes findings that cannot be triggered, but it says nothing about how likely exploitation is, and it only covers code the analysis can follow.