Because EPSS scores are calibrated probabilities, you can add them up. The sum across a set of vulnerabilities is the expected number that will see exploitation activity in the next 30 days. A related formula gives the chance that at least one of them does. Both are program level estimates, not forecasts for any one flaw.
Expected count: just add
FIRST's guidance is simple. The expected number of exploited vulnerabilities in a set over the next 30 days equals the sum of the individual EPSS probabilities.
Worked example from FIRST: 100 vulnerabilities each scoring 0.05 give an expected count of 5. That matches the plain reading of 0.05, which is 5 in 100.
This number is useful as a trend. If your open backlog sums to 12 this month and 20 next month, your exposure grew even if the raw count of findings stayed flat.
Chance that at least one is exploited
Assume exploitation events across vulnerabilities are roughly independent. Then multiply together the chance that each one is not exploited, which is one minus its score, and subtract the result from one.
For the same 100 vulnerabilities at 0.05, FIRST puts the chance that at least one is exploited in 30 days at about 99.4 percent.
You can check it. The chance a single one is not exploited is 0.95. Raise 0.95 to the power of 100 and you get roughly 0.006. One minus that is about 0.994.
The message to leadership is not alarming for its own sake. It shows why a long tail of "low" scores can still add up to a near certainty that something in the pile gets hit.
A small spreadsheet recipe
- Export open findings with their CVE ids.
- Join the daily EPSS file on the CVE id. The file has three fields: cve, epss and percentile.
- Sum the epss column for the expected count.
- Keep one row per CVE, not per affected asset, if you want an estimate for distinct flaws. Decide which you mean, and say so.
- Record the date, since scores change daily.
You can also compute the sum for tiers, such as internet-facing assets only, or for a single product, and compare them.
Limits you should state out loud
- Calibration must hold at portfolio level. FIRST says to treat the results as estimates, not precise forecasts.
- Independence is an assumption. Flaws in one product or one exploit kit are often exploited together. The at-least-one figure can be off for that reason.
- EPSS measures observed exploitation activity by its data partners, not attacks on you.
- It ignores your environment. A summed score on components you do not run, or code you never call, overstates your exposure. Filter for presence and reachability first.
Using it to justify work
The sum is a decent way to show the effect of a fix. Remove the five highest scoring findings and show the expected count dropping. Compare that to the effort. It turns a fuzzy request into a number that can be checked next month.
Safeguard's reachability analysis helps with the filter step, so the sum is taken over findings that matter in your code. See the reachability demo.
Quick check
What does the sum of EPSS scores represent?
The expected number of vulnerabilities in the set that will see exploitation activity over the next 30 days, as an estimate.
Can I use the sum to predict which flaw will be hit?
No. It is a portfolio level estimate. Use individual scores only as a ranking input.
Sources
Last reviewed: 19 October 2026.
