You can estimate how many vulnerabilities exist, including ones no scanner found, from the overlap between two scanners. Multiply what each found and divide by what both found. The result is a rough total. It tends to be too low, so read it as a floor.
The idea from ecology
Biologists count fish in a lake by catching some, marking them, releasing them, and catching again. If half of the second catch is marked, the first catch was probably about half the lake. The Lincoln Petersen estimate captures that: total is first count times second count, divided by the number seen in both.
Replace fish with vulnerabilities and nets with scanners.
A worked example
Illustrative numbers. Scanner A reports 80 real vulnerabilities in a codebase. Scanner B reports 60. Thirty five are found by both after you review them.
- Estimated total: 80 times 60 divided by 35, about 137.
- Found by at least one: 80 plus 60 minus 35, which is 105.
- Estimated missed by both: about 32.
So the team has found something like 77 percent of what is there, and roughly a third as many again may be hiding.
How to run it
- Scan the same target with two methods that work differently. Two tools that share the same database will overlap too much.
- Review each reported item and keep only the real ones. Overlap among false positives would inflate the count.
- Match items by a stable key, such as package and version plus advisory, or file and rule. Poor matching shrinks the overlap and inflates the estimate.
- Apply the formula. Repeat on a few targets to see the spread.
Why it underestimates
The method assumes each issue is equally likely to be found by each tool, and that the tools act independently. Neither is true in practice.
- Easy issues are found by everyone, and hard ones by no one. That raises the overlap and lowers the estimate, so the real total is probably larger.
- Tools trained on the same advisories share blind spots. A bug that is in no public database is missed by both.
Treat the output as a lower bound on the number of undiscovered issues, useful to show the unknown is not zero.
Better evidence for specific gaps
When you need to know whether a particular class is covered, do not rely on the estimate. Plant known issues and check that your tools find them. Our guide on testing a SAST tool with seeded bugs describes how. Pair the two: seeded tests for named gaps, capture recapture for the unnamed ones.
Quick check
Do I need two scanners to use this?
You need two independent sources, which could be a scanner and a manual review, or two reviewers. They must work differently enough that they do not share the same blind spots.
Can the estimate be exact?
No. It is a rough floor, and small overlaps make it unstable. Use it to size the unknown, not to report a precise count.
Last reviewed: 19 October 2026.
