Bug bounty programs were built on a single assumption: that finding a vulnerability was the hard, scarce, expensive part worth paying for. That assumption held for about a decade, then AI erased it. When anyone can point a model at your code and receive a plausible-looking finding back in seconds, a crowd of finders stops being your advantage. This is because the person you’re defending against has the same tool, plus the one thing the crowd doesn’t have, which is context on your live system and the intent to use it.
What bug bounty was paying for
Bug bounty was a wager on scarcity. For most of its history, finding a real security problem in mature software meant a skilled human spending weeks reading code, forming a theory, building tooling, and poking at edges until something gave. That work was genuinely rare, so paying for it made sense, and the price the market settled on was a bargain next to a full-time hire. Daniel Stenberg, who ran curl’s program for over six years, has made the point directly: when hunting for flaws was that slow and that manual, a bounty was a fair way to reward the people willing to do it.
The numbers backed the logic. For years, curl confirmed real vulnerabilities in something north of 15% of the reports it received. That’s a strong signal-to-noise ratio for an open program, and that ratio created the pricing model. Discovery was the constraint, so discovery was the thing you rewarded.
What changed when discovery became cheap
The constraint broke and not just for Curl. Starting in 2025, curl’s confirmed-vulnerability rate collapsed from above 15% to below 5%, meaning fewer than one in twenty reports described anything real. The inbox filled with submissions that read like security findings, referenced specific functions and code paths, and described attack scenarios that sounded credible, and then dissolved the moment anyone technical looked closely. One report arrived complete with debugger sessions and register dumps for a function that doesn’t exist anywhere in the curl codebase. The program shut down at the start of February 2026 to kill the incentive.
A part most people missed is that a month later, curl reopened the program, and the slop was mostly gone, replaced by high-volume reports that are genuinely, technically accurate. The confirmed rate climbed back to the 15-to-16% range, matching the pre-AI baseline, while total volume ran roughly double the 2025 level, which was already more than double the years before that. The models improved, and the burden became heavier anyway.
Better reports didn’t help because finding the bug wasn’t the expensive part. The expensive part is reading the claim, verifying whether it’s real, judging how much it matters in context, deduplicating the ten other people who prompted the same model and received the same answer, and shipping a safe fix. The bottleneck moved from discovery to remediation, but the bounty still pays for discovery. Stenberg is careful to note this is one project’s data and too thin to carry hard statistics, and he’s right to say so. But the direction shows up everywhere else too, from platforms cutting their open-source payout tiers sharply to projects pausing programs they could no longer triage.
Follow the money and the problem becomes obvious. A bounty pays the person who reports a finding, and it pays nothing to the people who then have to prove it, rank it against everything else in the queue, and write the fix. When discovery was the scarce input, that was a fair trade. Now that a model can generate ten confident findings while you read this sentence, the same trade conscripts your team as a free triage desk for anyone with an API key and a grudge. The reporter’s cost went to zero while yours went up, and the reports you most need to see are now buried under the ones that only look like them.
Before AI, a bounty paid for most of the real cost of a finding. After AI, it pays for the sliver that became cheap.
A crowd isn’t an adversary
A crowd is optimized to surface possible bugs in code, but an adversary is optimized to produce a specific outcome in your running system, and those are not the same job. This is the distinction that matters but it’s also the one the crowdsourcing pitch skips.
A bounty crowd is distributed, incentive-shaped, and blind to your environment. It looks at code, or at a public endpoint, and reports what could be wrong in the abstract. It has no idea which of your workloads is internet-facing, which service account is over-permissioned, or which path reaches your sensitive data. An attacker targeting you has the opposite profile: one focused human carrying real context about your specific deployment, now augmented by the same models the crowd uses, and working toward one reachable outcome in your live system rather than a wall of maybes.
And the thing that makes an elite attacker dangerous is the same thing that makes an elite researcher valuable, which is exactly the thing a model can’t supply on its own: judgment. A model can tell you a payment field accepts a number, but it takes a human to realize that a negative quantity in that field triggers a refund because nobody validated for positive integers. The same gap shows up in chaining, where a model will flag a low-severity SSRF on its own, and it takes a person to walk that SSRF into an internal service, then into an auth bypass, and turn three minor findings into one critical breach. That’s business-logic reasoning and creative chaining, and it’s where the real damage lives and where automation alone is weakest. A thousand automated finders running without that judgment is still zero understanding, multiplied.
So crowdsourcing scales the one thing that stopped being scarce: findings. What it can’t scale is judgment, context, or intent. Your adversary brings all three, aimed at your environment specifically. You can’t assemble enough strangers to stand in for one motivated person who knows where you live.
What’s scarce now is knowing what’s live
The scarce thing moved to somewhere a bounty inbox can’t reach. Even leaders inside the bug bounty world now say: not every bug is a vulnerability, not every vulnerability reproduces, and not every reproducible vulnerability is exploitable in a given environment. Each of those filters throws away most of what came before it.
Think about what that means for a CVE. The same identifier can describe a catastrophe or a non-event depending entirely on context. A vulnerable function sitting in a library you ship but never load at runtime isn’t the risk that the identical function is when it’s loaded, internet-facing, and one hop from your data. The same goes for identity: a token or service account only matters to the degree it can reach something, and in most cloud environments the non-human identities quietly outnumber the human ones. Severity scores don’t know any of that. Most disclosed vulnerabilities are never exploited at all, and only a small share have public exploit code in circulation. I know, that’s a stack of qualifiers in one breath, but each one is a place where a wall of “valid” findings collapses down to the handful that can hurt you.
This is why the enterprises running these programs keep telling the platforms the same thing: they want validated, genuinely exploitable findings, not more alerts, because they’re already drowning in false positives from every scanner they own. The expensive, scarce question stopped being “does a bug exist somewhere in this code?” And it became “is this reachable, running, and being touched in my environment right now?”
Runtime is where you meet the adversary
Your adversary doesn’t operate in your code repository or your bounty inbox, they operate in your running system. That’s the only place you see the adversary in the open, rather than as a hypothesis about what they might do. You can’t scan or crowdsource your way to a gap that a live attacker has already stepped through, because by the time a report describes the door, they’re already inside it.
A report describes a world that might exist and runtime shows the world that does exist. At runtime, the adversary’s behavior is the signal you were missing: a process spawning a shell it has no business spawning, a workload reading credentials it never touches, egress to an address it has never talked to. Take the supply-chain compromises that have hit npm and PyPI this year, where a poisoned package calls home during installation, before the build has even finished resolving dependencies. No scanner flagged those versions as malicious in advance, and no crowd could have because the tell wasn’t in code anyone could read, it was in what the package did the moment it ran. None of that requires a CVE to be known first, and none of it shows up in a queue of code-level findings from people who have never seen your environment. This is the bet Upwind makes, that the signal worth trusting is the behavior your workloads emit while they run. Which is also the one place you can catch an adversary carrying context you could never crowdsource.
Most of my work is tracking supply-chain attacks and what stands out to me is how ordinary a malicious package looks right up until it runs. In the npm and PyPI compromises my team pulled apart this year, the tell was never in the published code for a reviewer or a bounty hunter to catch. It surfaced at install time, when the package reached for credentials and called out to infrastructure it had no reason to touch.
So this isn’t a case for shutting down your bug bounty program. Plenty of them still surface real issues, and the strong researchers who treat AI as a tool rather than a slot machine are producing better work than they ever have. It’s a case for being honest about what the model can and can’t do for you. Bug bounty was never built to stand in for live visibility against a real adversary, and treating a crowd of finders as if it were that visibility is how you end up with a mountain of confirmed findings and no idea which one is being used against you as you read this. Discovery became cheap, but knowing what’s live did not, and that’s the part worth every penny now.
Key Takeaways
- Bug bounty was priced on the assumption that finding vulnerabilities was scarce and expensive; AI collapsed the cost of discovery and broke that assumption.
- curl’s confirmed-vulnerability rate fell from above 15% to below 5% during the 2025 AI-slop flood, then recovered to 15-16% once report quality improved, while volume roughly doubled and the triage burden kept rising.
- The expensive work was never discovery; it’s verifying, judging severity, deduplicating, and fixing, and a bounty funds none of that.
- A distributed crowd of finders can’t replicate a single focused attacker who carries context on your live environment and the judgment to chain findings into real impact.
- The scarce question is no longer whether a bug exists in code, but whether it’s reachable, running, and being exploited right now, which is a runtime question.
