If you assume exploitation of each vulnerability is independent, the chance that at least one in a set is exploited in the next 30 days is one minus the product of each score's complement. FIRST's example is 100 vulnerabilities each scoring 0.05, which gives about 99.4 percent. It is a rough exposure estimate, not a forecast.
The formula
FIRST's Using EPSS page states it this way.
P(at least one) = 1 - product of (1 - p) over all vulnerabilities
Here p is the EPSS score of each vulnerability, and one minus p is the chance that vulnerability is not exploited in 30 days. Multiply those together to get the chance none are exploited. Subtract from one to get the chance at least one is.
A worked example
Take three findings with scores of 0.02, 0.05 and 0.10.
- Chance none exploited: 0.98 times 0.95 times 0.90, which is about 0.838.
- Chance at least one: 1 minus 0.838, about 0.162, or 16 percent.
Now take FIRST's larger case, 100 vulnerabilities at 0.05 each. The chance none are exploited is 0.95 raised to the 100th power, about 0.6 percent, so the chance at least one is about 99.4 percent. The point is how fast small numbers add up across a long list.
The expected count
FIRST also gives a simpler measure. The expected number of exploited vulnerabilities over 30 days is the sum of the scores. For 100 vulnerabilities at 0.05 each, that is 5. This is the number to track for trend. See adding up EPSS scores.
| Measure | Formula | Good for |
|---|---|---|
| Chance at least one | 1 minus the product of (1 minus p) | A single headline exposure figure |
| Expected count | Sum of p | Trend over time and comparing teams |
For most reports the expected count is easier to explain, and does not saturate near 100 percent as the list grows.
Caveats you must state
- Independence is an assumption. FIRST says to assume events are approximately independent. Real exploitation can cluster, for example when one attacker uses several flaws on the same product.
- Calibration must hold at portfolio level. FIRST says both aggregations depend on that and should be treated as estimates, not precise forecasts.
- It says nothing about presence or reachability. Run it only on findings you have confirmed exist in your environment, ideally those reachable.
- It ignores impact. Ten trivial exposures and one that holds your customer data do not carry the same weight.
- Scores change daily, so date every figure.
Steps to produce it
- Export your findings with CVE IDs.
- Remove those not present or not reachable, and say how you decided.
- Join today's EPSS scores from the daily file.
- Compute the sum and, if you want it, the chance at least one.
- Save the number with date and model version, and compare month to month.
If the number is falling because you fixed items, that is a useful, honest progress measure. If it is falling because the scores moved after a model change, say so. See why a score history jumps.
Safeguard's SBOM and dependency scanning give the list of findings, and reachability analysis helps trim it to what matters. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how the list shrinks once unreachable items are set aside, and how that would change a sum of scores.
Quick check
Why does the chance approach 100 percent with a long list?
Each extra vulnerability adds a chance of an exploit, and the chance that none are exploited shrinks with each one multiplied in.
Which figure is better for a monthly report?
The expected count is usually easier to trend and explain, since it does not flatten near 100 percent. State the assumptions with either.
Sources
Last reviewed: 19 October 2026.
