Skip to content

How EffectivePriority works

A CVE’s severity tells you how bad it is in the abstract. EffectivePriority answers a narrower, more useful question: given how your project uses the package and how exposed it is, how much should you care right now? It is a score from 0 to 100, computed from three independent layers.

Usage - how your code touches the package. Evidence gathered by av reach analyze ranges from the package not being present at all, through being a transitive-only or direct dependency, up to being imported in your own source. The more directly you use it, the higher the priority; a transitive dependency you never import pulls it down. Absent evidence is treated neutrally - a missing signal never raises priority.

Exploit context - how exploitable the CVE is in the wild. This layer folds in the EPSS probability and percentile, whether the CVE is on the CISA KEV list of known-exploited vulnerabilities, and the attack vector parsed from the CVE’s CVSS data.

Exposure - whether the project is reachable. A network-exploitable CVE on a project you have declared internet-facing scores higher; a local-only attack vector, or a project that is not internet-facing, dampens it. You set this on the project in Settings.

The score is summarised as a band on each alert:

  • Likely exploitable - high priority; treat it as real until shown otherwise.
  • Needs review - a genuine “check this” - the signals are mixed.
  • Likely not exploitable - low priority; the evidence suggests limited real risk here.
  • Unanalyzed - no usage report has been uploaded for the project yet.

If a CVE is on the CISA KEV list, its verdict is pinned to the top band regardless of the other layers. Something actively exploited in the wild is never quietly deprioritised by a weak usage or exposure signal.

EffectivePriority and its verdict annotate and prioritise an alert. They do not change the alert’s own RED / YELLOW / GREEN tier, and they never suppress an alert. A human override always wins over the computed verdict.