If you test n items and find zero problems, the true problem rate could still be as high as about 3 divided by n at 95 percent confidence. Check 30 items with no failures and the rate may be up to 10 percent. Zero observed does not mean zero exists.
Where the three comes from
Suppose the real failure rate is r. The chance of seeing no failures in n independent checks is (1 minus r) raised to the power n. You can ask: how high could r be before a clean sample becomes less than 5 percent likely? Solving gives r of roughly 3 divided by n for reasonable n. The exact value is 1 minus the nth root of 0.05, and the shortcut is close.
For n of 30 the exact answer is about 9.5 percent. For n of 100 it is about 3 percent. For n of 300 it is about 1 percent.
Where this shows up in security work
- You pen test 20 login endpoints and none had the bug. The true rate across similar endpoints could still be around 15 percent.
- You review 50 pull requests for a secret and find none. Up to 6 percent of PRs could still contain one.
- You test your alerting on 10 simulated attacks and all fire. That is encouraging, but the miss rate could still be near 30 percent.
- A sample of 40 dependencies shows no malicious packages. The share across the whole tree could be a few percent, which is a lot at a thousand packages.
How to use the rule
- Decide the rate you can tolerate. Say 1 percent.
- Divide 3 by that rate. You need roughly 300 clean checks to claim the rate is under 1 percent with 95 percent confidence.
- If you cannot afford that many, claim less. Say "under 10 percent" instead of "no issues".
This turns a vague "looks fine" into a statement someone can challenge.
What the rule does not cover
It assumes the checks are independent and drawn at random from what you care about. Real samples often fail on both counts.
- If you picked the cleanest, newest repositories, the sample says nothing about legacy ones.
- If checks are not independent, such as 20 endpoints sharing one vulnerable library, you effectively have one check, not 20.
- If the test cannot detect the problem in the first place, a clean result is meaningless. A scanner that does not look at a file type will report zero for it every time.
For that last case, a seeded test is the cure. Plant a few known issues and confirm the method finds them. Our guide on validating a reachability tool with seeded tests shows the pattern.
Writing it up
A sentence that survives scrutiny: "We reviewed 60 randomly chosen services and found no hard coded credentials. At 95 percent confidence the true share is below 5 percent." Auditors and executives usually value the bound more than a bare "none found".
Quick check
I found nothing in 100 samples. Is the rate zero?
No. The best you can say is that it is likely under about 3 percent at 95 percent confidence, assuming a random, independent sample.
Does the rule work for rare but severe issues?
Yes, and it is most useful there. Rare severe issues need large samples, so a small clean sample should never be read as proof of safety.
Last reviewed: 19 October 2026.
