When two vulnerabilities tie, fix first the one that attackers can reach most easily and that would hurt most. Break ties in order: evidence of exploitation, exposure to the internet, whether the vulnerable code runs, the damage if it is abused, and finally how cheap the fix is.
Why ties are common
Scoring systems group many findings into the same band. A CVSS number describes severity of the flaw, and FIRST says plainly that numerical scores should be labeled by the metrics used to produce them. Two findings can both sit at "high" and still differ hugely in real risk.
EPSS adds a probability of exploitation in the next 30 days, but FIRST notes it does not measure damage or whether the issue affects your environment. So after the standard signals, you still need local tie-breakers.
The tie-breaker order
- Exploitation evidence. A vulnerability on CISA's known exploited list, or with reliable reports of use in the wild, goes first. SSVC calls this the Active value, and defines it as shared, observable, reliable evidence of use by threat actors.
- Exposure. Reachable from the internet beats reachable only from an internal network.
- Reachability. Does your application actually call the vulnerable function? If one finding is reachable and the other is not, the reachable one wins.
- Impact if abused. Credentials, customer data, and build systems carry more weight than a low value internal tool.
- Fix effort. If risk is truly equal, do the one that takes an hour before the one that takes a week. It clears the queue and lowers total exposure sooner.
Worked example
Take two high severity findings. One is in a logging library that your service imports but never calls in the affected function. The other is in a request parsing library on an internet facing API.
Neither is on a known exploited list. Exposure separates them at step 2: the API one goes first. The logging library issue still gets fixed, just on the routine schedule.
A quick scoring table
| Question | Yes | No |
|---|---|---|
| Known exploited? | Fix first | Go on |
| Internet facing? | Move up | Stay |
| Vulnerable code reachable? | Move up | Move down |
| Handles sensitive data or credentials? | Move up | Stay |
| Fix is a small safe bump? | Do it in this pass | Schedule it |
Do not turn this into arithmetic. Multiplying scores together creates false precision, and it is better to apply the questions in order and write down which one decided the tie.
Record the tie-breaker you used
Write one line in the ticket, such as "ranked above X because internet facing". It makes the decision reviewable and teaches new team members how you think.
Try it yourself
Open the demo and compare the same findings before and after reachability is applied. Look at how many items drop in the queue once the unreached code is marked.
Click through it at your own pace, or open it full screen.
Quick check
Should I add EPSS and CVSS together to break a tie?
No. They measure different things, and combining them hides which signal drove the decision. Apply them as separate questions.
What if both findings are equally exposed and reachable?
Pick the one with the greater impact, then the cheaper fix. Either way, record why.
Sources
Last reviewed: 19 October 2026.
