Conversation
Reputation in security tooling is trust, and trust is *measured* false positives and reproducibility. Nothing in the repo currently measures whether the toolkit's detectors are accurate — so it can't make the one claim that earns credibility: "here is our false-positive rate, reproduce it yourself." BugBench adds that. What it is: - A ground-truth corpus (bughunter/bench/cases/*.json) of known-vulnerable AND known-safe cases. Each case carries a RECORDED input (the exact response a detector sees), never a live URL — so scores are identical on every machine and in CI. Cases are data: anyone can contribute one without touching Python. - A harness (bughunter/tools/bench.py) that runs each case's detector and scores precision / recall / false-positive rate. Detectors register a one-function adapter via @detector — adding one never touches the harness core (open/closed). The cors detector is wired first, against its real, pure classifier (offline). - A Markdown/JSON scoreboard leading with precision + FP-rate. Accuracy is deliberately NOT the headline: on a mostly-safe corpus a do-nothing detector scores high accuracy while catching nothing (a test asserts exactly this). Why the CI gate matters: - `bench.py run --min-precision 1.0 --max-fp-rate 0.0` exits non-zero on a regression, and a new `bugbench` CI job runs it. So a change can never quietly make a detector noisier or less accurate — "we measure quality" becomes an enforced guarantee, not a one-time claim. Design: the whole thing is pure-stdlib and deterministic. Data model, metrics, runner, scoreboard, and the gate are each independently unit-tested (28 tests in tests/test_bench.py), including the end-to-end run of the real cors classifier over the shipped corpus (100% precision, 0 false positives) and a gate test that proves a wolf-crying detector fails CI. This is self-contained and valuable on its own; it's also the measuring stick for a follow-up verification layer (prove-or-suppress) that will route findings through confirmation before they're ever reported. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The claim this unlocks
Almost no AI security tool can say that. Reputation in this space is trust, and trust is measured false positives + reproducibility. BugBench is the infrastructure that lets the project make — and keep — that claim.
Why it's needed
The repo generates findings (scanners, agent), captures them (
/poc), re-checks them (/replay), and prioritizes them (/oracle). What it has never had is a way to answer: "how often are the detectors actually right, and how often do they cry wolf?" Without that number, every accuracy claim is a vibe. BugBench makes it a measurement.What's in this PR
bughunter/bench/cases/*.json, with known-vulnerable AND known-safe cases. The safe cases are the point: they're what measure false positives. Each case carries a recorded input (the exact response a detector sees), never a live URL, so the score is byte-identical on every machine and in CI.bughunter/tools/bench.py: load → run detector → score. Detectors register via a one-line@detectoradapter (open/closed — adding SQLi/JWT/CRLF is a one-function change, the core never grows an if/elif tree). Thecorsdetector is wired first against its real, pure classifier, offline.test_accuracy_is_misleading_under_imbalance) proves a do-nothing detector scores 95% accuracy while catching zero bugs. That's why trust metrics lead.bugbenchjob runsbench.py run --min-precision 1.0 --max-fp-rate 0.0, which exits non-zero on regression. A change can never quietly make a detector noisier. "We measure quality" becomes enforced, not aspirational.The scoreboard today
(Starts with the CORS detector; the corpus is designed to grow — every new case and detector strengthens the guarantee.)
Quality
tests/test_bench.py), each layer isolated: data-contract validation, metric math (incl. the "accuracy lies" lesson), the runner against the realcorsclassifier, the scoreboard, and a gate test proving a wolf-crying detector fails CI.7 files changed, 803 insertions(+), nothing removed. A malformed corpus fails loud (never silently skews a score).How to extend (built for contribution)
bughunter/bench/cases/— no code.@detector("name")adapter inbench.py.Self-contained and valuable on its own; also the measuring stick for a follow-up prove-or-suppress verification layer.
Try it
🤖 Generated with Claude Code