The Radar Score

Every vulnerability feed can tell you a flaw is severe. Almost none can tell you it is likely to matter: fewer than 5% of CVEs are ever exploited at all, and CVSS alone happily ranks a never-exploited 9.8 above the 5.3 attackers are using today. The Radar Score exists to fix that: one number per image, workload, release, cluster or organization, summed from per-finding contributions that weight severity by real-world exploitation. And unlike the proprietary risk numbers shipped by most platforms, its formula is published here in full — every input is a public fact with a URL.

Each finding's contribution: likelihood × consequence

Every finding contributes 0 to 100 points, computed from its advisory alone; a thing's Radar Score is the sum of its findings' contributions:

contribution = 100 × impact × exploitability      # per finding, 0–100
Radar Score  = Σ contributions                    # per image, workload, cluster, org

impact          = CVSS base score / 10            # how bad, if exploited
exploitability  = 1.0                if in CISA KEV   # observed, not predicted
                  ∛ EPSS probability if EPSS exists   # cube root — see below
                  0.10               otherwise        # ≈ a typical CVE

The three inputs, and where each comes from:

• CVSS — the advisory's severity score, from the matched OSV advisory. It answers "how bad would this be if exploited?" and nothing else.
• EPSS — the exploitation probability published daily by FIRST.org, a prediction of how likely the flaw is to be exploited in the next 30 days.
• CISA KEV — the Known Exploited Vulnerabilities catalogue: flaws that have been observed exploited in the wild.

The inversion that is the whole point

The multiplication is what makes this a ranking rather than a restatement of CVSS: 100 × (9.8 / 10) × ∛0.0004 ≈ 7, while 100 × (5.3 / 10) × 1.0 = 53. Most findings contribute single digits, and that is correct rather than something to rescale away — a list where almost everything sits near zero and a handful of findings do not is the finding.

Why the cube root of EPSS

Raw EPSS probabilities are unusable as a weight: the distribution is extreme, with a median around 0.0005 and a long thin tail. Multiplied in linearly, every finding outside the top thousandth becomes arithmetically indistinguishable from zero and the score collapses to "the one CVE with a big EPSS number". The cube root spreads the range out:

The cube root is a monotone transform, so it never changes which of two findings ranks first — only how far apart they sit. It also uses the EPSS probability, not the percentile: percentile is uniform by construction, so using it would assert the median CVE is moderately likely to be exploited, when FIRST.org's own finding is that under 5% ever are.

When data is missing

Both obvious rules for missing data are wrong: treating it as zero buries a real vulnerability because nobody modelled it, and treating it as maximal floods the top of the list with the unmodellable. So each gap has a documented, deliberate rule:

• No EPSS score: EPSS covers CVEs, so this is advisories with no CVE alias — some GHSA- and PYSEC- records (most carry one and get its EPSS score), and every MAL-. The likelihood term is 0.10, the same value a typical EPSS score produces. The finding ranks on its CVSS alone. The UI shows EPSS — for these, never EPSS 0.10 — the number is our assumption, not FIRST.org's finding.
• No CVSS score (about a fifth of advisories, mostly distro ones that publish a severity band instead): a representative score for the band is assigned when the advisory is ingested — critical 9.5, high 7.5, medium 5.5, low 2.0 — so the finding ranks by its band rather than dropping to zero impact. The scoring SQL keeps its own band-to-score mapping as a backstop for any row that reaches it with a band but no stored score.
• Neither score nor band: 4.0, the middle of the scale.
• An unscanned image shows no score at all, never zero — "we haven't looked" is not "it's clean".

Why exposure sits beside the score, not inside it

Pod count, init-vs-serving, how long a finding has been open — none of it is folded into the number. These columns render next to the score instead, and the reason is the product's core credibility rule: every input to the Radar Score is a public fact with a URL you can check. A 1.15 multiplier for "runs in twelve pods" is not, and it is the part a security engineer would argue with first. Sorting by score and reading the pod count in the next column loses nothing, and keeps the number defensible.

The Radar Score itself: an unbounded sum

Images, workloads, Helm releases, clusters, and your whole organization each carry a Radar Score: the plain sum of their findings' contributions. The score is deliberately unbounded, because it is a magnitude, not a ranking — it answers "how much vulnerability debt does this carry?", it visibly falls as findings are fixed, and it composes: a cluster's Radar Score really is the sum of its images' Radar Scores.

What a sum gives up is worst-domination — five hundred trivial findings can outscore one exploited critical. That question is answered by two things that are never derived from the total: the colour band, which is always the band of the worst single finding in the rollup, and the KEV badge, which marks active exploitation regardless of where the finding sorts.

The boundaries sit lower than CVSS's because a contribution is a product of two fractions, which compresses the reachable range: a CVSS 9.8 with typical exploitation pressure lands near 10, and only measured exploitation lifts a finding above 40. Reusing the CVSS bands would label nearly everything "low" and hide the ordering the contribution exists to produce.

When scores change

Each contribution is stored as a database column generated from the advisory's CVSS, EPSS and KEV fields, so it can never drift from its inputs. EPSS and the KEV catalogue are each re-synced daily — KEV right after EPSS — and each sync is the recomputation — when a flaw's exploitation probability jumps or it lands in KEV, every affected contribution, and every Radar Score summing it, moves with it. No rescan needed. How findings are produced in the first place is covered in vulnerability matching.

Frequently asked questions