Estimate what your testing did not find.
You found 104 bugs. Nobody in the room can tell you how many are left.
Every security review and QA cycle ends with a list of findings and silence on the only question leadership asks. Unknown turns the overlap between your detection methods into a number: found, estimated total, remaining, and whether that clears your bar to ship.
Two release candidates with a known injected defect population. The estimator never sees the true count, and every number below is computed from the overlap in your browser.
The problem
"We fixed everything we found" is not an answer to "is there more".
A review ends, the findings get triaged, the fixes land, and someone has to sign the release. The two things usually offered at that moment are a count of what was found, which says nothing about what was missed, and a coverage percentage, which measures effort rather than results. Eighty percent line coverage and zero remaining bugs are unrelated statements. So the decision that actually matters, ship now or keep testing, gets made on how tired everyone is.
The insight
Ecologists answered this question in 1896 and it transfers exactly.
You cannot count every fish in a lake. What you can do is survey it twice. If the second survey keeps pulling up fish the first one already tagged, you have found nearly all of them. If it keeps pulling up new ones, the lake is much bigger than your net. The size of the overlap estimates the size of what neither survey saw. Bugs work the same way. Static analysis and manual review, two reviewers, a fuzzer and a scanner: the defects both methods found, measured against the defects only one found, estimates the defects neither found. That converts "we found 104" into "we found 104 of an estimated 175, so about 71 remain", which is something a release manager can actually act on. The assumptions are strong and stating them is not optional. The methods have to be genuinely independent, and defects have to be roughly equally findable. Neither holds perfectly in real code. Unequal findability biases the estimate downward, which means the true remaining count is usually worse than this reports, not better. When the overlap is small the honest output is a warning rather than a number, and this product gives you the warning.
Chapman’s bias-corrected Lincoln-Petersen estimator on each pair of methods, which stays finite at zero overlap where the plain estimator divides by zero. Seber variance for the interval. With three or more methods, the median of the pairwise estimates, because the spread across pairs is itself the tell for whether independence is holding. The warning fires below an overlap of seven and hardens below three. The ship gate is stated as a residual budget, not inferred: coverage above 90%, three or fewer estimated remaining, and no pair carrying a warning.
How it works
Four steps, no data science team
Static analysis and manual review. Two reviewers who did not read each other’s notes. A fuzzer and a scanner. Independence is the assumption doing all the work, so methods that share a rule set or a checklist will overstate your coverage.
Which defects each method found, joined on a stable identifier. The join is the input that matters and it is the part teams get wrong, so the tool spends most of its effort on making duplicates and near-duplicates reconcile.
Estimated total, estimated remaining, and an interval. When the overlap is thin you get the warning instead, because a confident number from five shared findings would be worse than nothing.
A release-readiness verdict with the coverage, the residual estimate, the interval, and the assumptions printed on the same page. When it says keep testing, it says how much more testing.
Who it is for
The person whose name goes on the sign-off
Security leads and QA managers who personally sign a release. The ones who have already been asked "so are we done?" in a room and heard themselves answer with a count of what they found.
Pricing
- –Paste two finding lists, get the estimate
- –Every assumption spelled out
- –No account
- –Finding reconciliation across tools
- –Release-readiness verdict per candidate
- –Coverage trend across cycles
- –Ship gate in CI
- –Self-hosted
- –Client-facing report export
- –SSO and audit log
- –Method independence review
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| Defect Density benchmarks | Bugs per thousand lines, compared against an industry table. | Tells you what an average project of your size contains. Says nothing about yours, and nothing about what your specific testing effort missed. |
| Coverage tools | Line, branch, and mutation coverage. Genuinely useful, and mutation testing is the strongest of them. | Measures what your tests exercised, not what your reviews missed. A hundred percent branch coverage says nothing about the logic error every branch happily executes. |
| Vulnerability management platforms | Aggregate findings from every scanner and track remediation. | Built to close the findings you have. The overlap between the tools is sitting right there in the database and none of them estimate from it. |
| A pentest report | A specialist tells you what they found and, if they are good, what they did not have time for. | Qualitative, and a point in time. Unknown is what you would compute across two of those reports. |
The honest risk is that the estimate is biased and the bias points the wrong way for a safety product. Real detection methods are not independent, because two reviewers read the same design doc and two scanners inherit overlapping rule sets, and real defects are not equally findable, because some live in code nobody reads. Both violations inflate the apparent overlap, which inflates apparent coverage, which means the number that ships is optimistic. The demo shows exactly this: hold the population at 160, make a third of it hard, and the estimator comes back 35% low with no warning attached. A product that says "you are done" when you are not is worse than one that says nothing, and someone will eventually ship on this number and get hurt. The mitigation is to sell it as a floor rather than an answer, refuse to emit a number when the overlap is thin, and put the assumptions on the artifact itself instead of in a docs page. Commercially the risk is that this is a spreadsheet a smart security lead builds once and never pays for. The defence is the reconciliation work, not the arithmetic.
Market
Attached to the security and QA budget of every company that ships software on a schedule
A single pentest runs $15k to $50k and a security program manager costs far more than that. Unknown is a small line beside either, sold to the person who already owns the sign-off. Three thousand product lines at the Team tier is $14M ARR, and consultancies resell it per engagement, which is the same install sold many times.