Back to blog
August 31, 20265 min read

Open source is drowning in fake security reports.

Every open-source founder I talk to has the same new problem: a flood of AI-generated security reports that look real and aren't. Each one costs a maintainer a night to disprove. So we built a workflow that checks whether there's a real, exploitable issue underneath — before a human ever sees it.

Mykola Savin
Mykola Savin
Chief Technology Officer

The nightmare every maintainer is describing

I've been talking to a lot of open-source founders lately about the security side of their projects, and they all describe the same new problem.

Their repos are flooded with security issues and pull requests that aren't real. Someone points an AI at the project, it writes up a “vulnerability” or opens a fix that looks completely legitimate, and sends it in. Multiply that by the reach of a popular project and the volume is genuinely crazy.

And this isn't anecdotal. curl — one of the most-used pieces of software on Earth — reported that by mid-2025 roughly 20% of its incoming security reports were AI slop, and only about 5% turned out to be real vulnerabilities, down from 15%+ historically. The report volume doubled. In the end they shut their bug bounty down.

A GitHub issues panel full of AI-generated security reports flowing into a validation step, which sorts them into one confirmed, reproduced bug and a pile of filtered AI slop.
Every incoming report, validated before a maintainer sees it

Why it's so corrosive

Every security report has to be taken seriously. A maintainer can't just ignore one — so they stop what they're doing, read the PR, trace the code, try to reproduce it. Most of the time there's nothing there. It just looked real.

That's the cruel part. The report costs the sender nothing — one prompt — and costs the maintainer a night. It's the same asymmetry we keep seeing with AI in security: making a claim is free, disproving it is expensive.

Making a claim is free. Disproving it is expensive. And most reports, after all that work, turn out to be nothing.

For projects run by a few people on their own time, this is becoming impossible to maintain. Some are already so worn down they're tightening or closing their security channels entirely — which is exactly the wrong outcome.

So we built a workflow to prove the report, not just receive it

The problem with a security report is that it's a claim. Reading it more carefully doesn't settle it — the only thing that does is whether the vulnerability actually reproduces. So that's what the workflow does.

  • It reads the report. It parses the reported issue or pull request and works out exactly what's being claimed — the vulnerability, the affected path, the supposed fix.
  • It tries to reproduce it. The claim goes through the same validation engine that proves our own findings: it actually attempts to exploit the issue against the real code, on a live target, instead of just pattern-matching the diff.
  • It returns a verdict. CONFIRMED, with a reproduction you can run. NO REAL ISSUE, filtered out. Or BLOCKED, when it genuinely needs context it doesn't have — stated honestly, never guessed.
  • Only the real ones reach you. The confirmed bugs surface with proof attached. The slop — the 90-something percent that goes nowhere — never lands on a maintainer's desk.

A security report is a claim. The only thing that settles it is whether the bug actually reproduces.

Proof over noise

It's the same principle behind everything we build. A finding only counts when it's real and reproduced — whether it comes from our own agents or from a stranger's pull request. The slop is only a problem while a human is the one who has to disprove it.

If you maintain an open-source project drowning in this, we'll set it up for you and prove every report that comes in — completely free.