Severity estimates how bad the flaw would be if real. Confidence estimates how likely it is real. Triage on both. A high severity, low confidence result needs a quick look, while a medium severity, high confidence one may be the better use of the next hour. A tool reporting only severity hides half the story.
Two different questions
Severity answers: if an attacker can exploit this, what happens? Data theft and code execution rank above minor information leaks.
Confidence answers: is this finding actually correct? Static analysis infers behaviour without running code, so it is sometimes wrong. OWASP's overview of these tools notes false positives are common and that proving a report is a real vulnerability is hard.
Treating them as one number is the root of many triage arguments.
The four quadrants
High severity, high confidence. Fix first. Block merges here, if you block anything.
High severity, low confidence. Verify. A short investigation, maybe a test, decides whether it is real. Do not ignore it just because the tool hedged.
Low severity, high confidence. Real but minor. Batch these into routine cleanup or fix as developers touch the file.
Low severity, low confidence. Candidates for rule tuning or suppression. If a rule produces mostly these, ask whether you want it on.
What to ask a vendor
- Does each result carry a separate confidence or certainty value, and what does it mean?
- How is severity calculated: by rule type, by data flow context, by exposure? A flaw in an internet facing handler differs from the same flaw in an internal tool.
- Can I filter and gate on each separately?
- Are ratings consistent between the editor, the pull request and the dashboard?
- Can I override a rating and record why?
Beware of ratings that are only a copy of a generic vulnerability class score. They ignore your context, and your triagers will overrule them constantly.
Test it in the pilot
Take your labelled findings, real or not real. Group them by the tool's severity and by its confidence. Then check which field better predicts the label. In many tools, confidence separates real from not real more cleanly than severity does. If neither does, you have learned the ratings do not help you, and triage will be manual.
Record the share of real findings in each severity band. If the high band is mostly not real, a gate on high severity will block innocent pull requests.
Context beyond the tool
A tool can only judge the code in front of it. Add your own context: is the service internet facing, does it handle regulated data, is it in production? Some teams add a simple multiplier for exposure when ranking work. Whatever you do, write the rule down so triage is consistent between people.
Do not forget exploitability signals for dependencies
For open source dependency findings, additional signals exist, such as whether the vulnerable function is reachable from your code. The same idea applies: combine how bad it is with how likely it is to matter.
Try it yourself
Click through it at your own pace, or open it full screen. See how a second signal changes which findings deserve attention first.
Quick check
Which should I sort by first?
Use both. Start with high severity and high confidence, then verify the high severity, low confidence group.
Can I trust vendor severity labels?
Treat them as a starting point and check them against your labelled pilot findings.
Safeguard's reachability analysis adds that kind of context for dependency findings and is generally available. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
