Ask for both. Precision is the share of reported findings that are real. Recall is the share of real issues the tool found. A tool can score high on one and poorly on the other, so a single accuracy figure in a review hides the trade-off you care about.
The definitions
The scikit-learn documentation defines both using three counts: true positives (correct results), false positives (unexpected results) and false negatives (missing results).
- Precision is true positives divided by true positives plus false positives.
- Recall is true positives divided by true positives plus false negatives.
The same page gives an intuition: precision is the ability not to label a negative sample as positive, and recall is the ability to find all the positive samples.
A worked example with invented round numbers
Suppose a test app has 10 known vulnerabilities. A tool reports 8 findings. Six match known vulnerabilities and two do not.
- Precision is 6 divided by 8, which is 0.75.
- Recall is 6 divided by 10, which is 0.6.
These numbers are made up to show the arithmetic and do not describe any product. The point is that 0.75 sounds good while 0.6 means four real issues were missed.
Which one matters more for you
It depends on the job.
- If reviewers are overloaded, low precision creates alert fatigue and hides real issues in noise.
- If you protect a high-risk system, low recall is the worse failure, because missed issues stay in production.
- For a blocking pull request gate, low precision breaks builds for no reason, so precision usually matters more there.
Write down your priority before you read any review.
Questions to ask a review
- Which counts were used: true positives, false positives, false negatives, true negatives?
- Were results split by vulnerability type?
- How were false positives decided, and by whom?
- Were the numbers from one run or several?
- Was the sample realistic, or synthetic?
Our guide to fair scanner tests explains how to build the labels these numbers depend on.
Why a single accuracy figure misleads
Accuracy as one number depends on how many real issues exist in the test. If a test app has few vulnerable places and many safe ones, a tool that reports nothing can look accurate, because most of its answers are correctly negative. That is why reviews built around one headline percentage deserve a follow up. Ask for the raw counts behind it and the split by vulnerability type. A tool might handle injection flaws well and miss weak cryptography, and an average hides that. If the review offers a curve or a combined score, ask how the two kinds of error were weighted, since the weighting is a choice somebody made.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how the list of findings shrinks. Ask yourself which findings you would have wanted to keep.
Where Safeguard fits
Safeguard offers reachability analysis, which is designed to cut down findings that cannot be reached by your code, and a free scan at gold.safeguard.sh/scan.
Quick check
Is a higher detection count better?
Not on its own. A tool that reports everything has high recall and may have very low precision.
Sources
Last reviewed: 19 October 2026.
