Needle problem? Just drop a haystack on it

I've just come off a pretty solid run of conferences - BSides Canberra, then Offensive AI Con - and every hallway conversation eventually ended up in the same place. Triage.

I'm also seeing a lot of bug bounty hunters ranting at triagers at the moment. Complaining is fine (and yes, triage is a mess across the board rn), but targeting individual triagers is not. Some of the frustration is justified, but a lot of it rests on an assumption that triage is easy... repetitive, hard to get wrong, and fixable by throwing more people at it. None of that is true, so I want to build a little empathy here and then make some recommendations about what actually needs to shift.

We had a needle problem, and we dropped a haystack on it

That's how I explained it to someone over a beer in Canberra.

AI has cut the cost of writing and sending a submission to almost nothing, so it matters a lot less to the submitter whether it's valid. People gaming bug bounty with spammy submissions in the hope of getting paid has always been a thing. Now it's turbocharged.

At the same time, AI has made it far easier for anyone to find legitimate vulnerabilities. Signal and noise have both gone up by, let's call it, a factor of ten, and the problem is the gap between the two.

Zoom out a bit and three things shifted at the same time: the value structure of vulns (incentive), the cost structure of triage (processing and filtering), and the barrier to entry (education). Each of them was already broken when that happened, fwiw.

Obvious junk is cheap to close. The expensive part is the plausible stuff... reports that look like they might be real, take a skilled human an hour to qualify out, and turn out to be nothing.

The assumption that's breaking

One of the design principles behind the triage queues we built at Bugcrowd (and at a lot of other places) was that a real vulnerability should never be allowed to become a false negative. Saying something isn't vulnerable when it is represents real risk, so we built systems to avoid that at almost any cost.

I still think the principle is right. A false positive costs you an hour. A false negative costs you the bug, the researcher who learns your queue isn't worth the effort, and possibly the next person to find it, who might not be the reporting type.

The problem is that we've built too much around it. When the queue's job is to never miss, every plausible report gets the benefit of the doubt and a skilled human's time to disprove it. That works when plausible-but-wrong is rare. When plausible-looking slop can be generated at enormous volume, it's exactly what breaks.

You could reduce this to the math (take an 80/20 signal-to-noise ratio, multiply both sides by ten, and look at the size of the absolute gap), but that's the cheap answer. The more honest version is that the stress of making those judgment calls was always there, and what's changed is the scale of it. The queues were built for a capacity that isn't supportable anymore.

None of this is new, btw. It's an old problem that's been magnified, and now it's getting called to the mat.

Nodding so hard my head nearly fell off

That was me in Joe Miller's talk at Offensive AI Con, "The AI Submission Surge: Vulnerability Disclosure Programs in the Age of AI", on what it's like to run Microsoft's queue from the inside

Again, none of it was new. What made it land was who was saying it. Microsoft owns its queue end to end - vendor, triager, fixer, and payer, all in one building - so they get to talk about the ugly numbers in ways others sometimes can't. A platform is triaging on behalf of customers it can't name, with commercial optics on every stat, and most vendors don't have the data or the appetite to say "nearly half of what came in was nothing" out loud.

A few numbers that stuck: submissions up 10x and now running at around 10,000 a month, an engineer spending at least an hour validating that a reported issue doesn't exist, and a "nothing to fix" rate that peaked at 42% and is now down to 24%. The ratio improved and the absolute load still exploded, which is the needle-and-haystack shape exactly. Their conclusion was that triage is the highest-leverage place to put effort, because everything downstream starts there. Completely agree.

The part I have to own

Total aside, but an important one: some of this is my fault.

We built a big chunk of this industry, and I was very much part of building it, on selling security to people who don't actually care about it. If the buyer doesn't care, you differentiate on volume, volume squeezes margin, and you compensate for thin margin with... more volume. At some point the receiving end goes "shut the fsck up," which is roughly what's happening with all the program pauses, shutdowns, and quiet moves to private.

Then AI showed up with a tanker of fuel.

Gating the top of the funnel is a Band-Aid

The most common response right now is upstream restriction: limiting AI-assisted submissions, limiting lower-reputation researchers, one-at-a-time rules. As a temporary measure to buy time, fine. As a long-term fix it's a bandaid at best, and the wrong answer. If someone finds a vulnerability, they've found a vulnerability. That's risk that needs to be reported, and telling them they can't because we're struggling to process it in the middle fixes the wrong part. The middle is what's choking.

That's not me saying the pre-submission quality problem isn't real. It is, and it causes lag for everyone. It just needs fixing with education and better tooling on the researcher side, not a locked door.

What I'd actually do

Start with empathy. Triagers aren't the enemy, and neither are the researchers yelling at them. Both are stuck inside a model designed for a different world.

Then review the assumptions that model was built on. I'm not talking about AI versus humans in the middle, that's not my point. Some of those assumptions need revising, some need to be thrown out, and some parts need to be started again from scratch. The three shifts from earlier are a decent map of where:

The cost structure of triage

Prove positive, don't prove negative. Most triage is set up to prove a report is NOT real, which is the never-miss principle doing exactly what we built it to do, and precisely what plausible slop exploits. Flip it. Reproduce before you filter, and let machines do that part: spin up an isolated environment, reproduce from the steps provided, check the required evidence is attached, dedupe. A report that reproduces goes to a human. One that doesn't goes back to the submitter with the reason and a way to fix it, NOT straight to closed, because "my harness couldn't reproduce it" is a fact about the harness, not proof the bug isn't there. Confirm fast, deny slowly.

Put the approve/disapprove call on the program owner. A triager can reproduce, dedupe, and grade, but whether something actually matters is a call for the people who own the asset (and own the fix). Part of why Microsoft can run its queue the way it does is that one org owns that whole loop.

Measure your false negatives as hard as you measure throughput. Re-check a sample of what you closed as N/A, track how often a closed report later turns up as a valid duplicate, a vendor fix, or a CVE, and publish the number. If queue size is the only thing anyone gets judged on, the queue will get smaller in the most dangerous way possible.

The value structure of vulns

Fix the incentives. If you can't absorb a 10x jump in triage, remediation, and patching overnight, you're not ready for a paid bounty, and a VDP as a lightning rod is a better fit. Cut payouts for stuff you genuinely don't care about only if you pay more for what an attacker would actually value. Put your evidence bar in your policy, make it machine-readable, and keep it current.

The barrier to entry

Educate, don't gate. Make triage a grade, not a wall: score submissions at intake, tell researchers their score, and coach them before the report reaches an engineer, because most people submitting junk don't know it isn't landing. The goal is a smarter research base, including how people use AI to validate their own findings before they hit submit.

Case in point: last week BugBunny open-sourced the triage skill they use internally to filter out false positives and non-actionable reports before they go anywhere. That was partly in response to some pretty harsh criticism, and I said at the time, without any irony or guile, that it was an epically classy response. Be a part of the solution.

There's a bigger conversation in here about who actually pays for the remediation side of all this (spoiler: mostly nobody right now), but we can discuss that another time.