Your triage cut is 'EPSS above 0.1' - what changes if you cut on EPSS percentile instead?

## Two numbers, two meanings Every scored CVE carries both an **EPSS score** and an **EPSS percentile**. - The **score** is an absolute probability between 0 and 1 that exploitation activity will be observed in the wild in the next 30 days. It is comparable across CVEs and across time: 0.1 means the same thing in March as in November. - The **percentile** is the score's **rank** within the current population of scored CVEs. It says "this flaw is more likely to be exploited than this fraction of all scored flaws". It is comparable across CVEs on the same day, and much less comparable across time, because both the population and the model move. ## The skew is the whole point The distribution of EPSS scores is heavily concentrated near zero: the overwhelming majority of CVEs are never broadly exploited, and the model reflects that. A small absolute probability can therefore already sit high in the ranking. Illustratively, a finding with a score around 0.09 can land in the mid-nineties percentile - the same flaw, two fields, and two completely different impressions of urgency. This is why writing a policy as "EPSS 0.9" when you meant the ninetieth percentile, or vice versa, is not a rounding error. One admits a handful of the most actively exploited flaws in existence; the other admits a tenth of everything published. ## What each cut does to your queue | Cut | Holds constant | Floats | |---|---|---| | `score >= X` | The risk bar - every admitted item clears the same absolute probability | Volume, which spikes when a wave of exploitable flaws lands | | `percentile >= Y` | Volume, roughly a fixed share of scored CVEs | The risk bar - the weakest admitted item can be much less likely in a quiet period | A **score cut** is defensible to an auditor or a customer: "we work everything above a one-in-ten chance of exploitation". Its failure mode is capacity. When something mass-exploitable is published and its whole dependency family lights up, the queue triples overnight and your team is the constraint. A **percentile cut** is defensible to your own delivery plan: it produces a predictable amount of work every week. Its failure mode is silence about absolute risk. In a quiet period you are working items that are, in absolute terms, unlikely to be touched, while your metrics look busy. Worse, in a bad period the percentile cut does **not** widen - the genuinely dangerous mass of new flaws still competes for the same top tenth. ## The practical answer most teams land on Use the percentile to **size** the queue and the score to **set the floor**, and put a hard override above both: 1. Anything with evidence of observed exploitation - a listing in a known-exploited catalog - is worked regardless of either number. 2. Anything above an absolute score floor is worked, however large that batch turns out to be. 3. Below that, take the top slice by percentile down to whatever the team can genuinely absorb, and be explicit that the rest is deferred rather than resolved. That structure gives you one bar you can defend externally and one dial you can turn internally, and it keeps the two from being confused. ## Volatility and re-scoring Both fields are recomputed daily. An item can cross your cut in either direction after it was raised. Decide the policy explicitly. A common and sane rule: a re-score may **promote** a finding into the queue, but never silently **demote** one that has already been raised and assigned - otherwise findings evaporate from a work board with no human decision recorded, and you cannot answer "who decided this was fine?" later. ## Unscored findings Both cuts share a blind spot: a finding whose advisory carries no CVE identifier has neither number. A numeric threshold alone will drop it. Route unscored findings to manual review rather than letting the arithmetic decide.