The FFmpeg incident has been blowing up recently in the infosec community. So here's my attempt at describing the incident to a broader audience, since I think it opens a pretty important question about how AI will change the relationship between security researchers and open-source maintainers.

Okay, now to talk about FFmpeg

You've most definitely crossed paths with FFmpeg, if not directly, then countless applications built on top of it. FFmpeg is a suite of libraries that handle video and audio processing across the internet. Every time you stream a video, convert a file format, or watch content on platforms like YouTube, FFmpeg is likely working behind the scenes.

What's remarkable is that FFmpeg is the result of volunteers. Despite having a reach so vast that its leadership could have monetized it, they chose to keep it free and open-source.

AI's gotten good at finding security vulnerabilities

Now, AI agents have gotten really good at finding security vulnerabilities. By summer 2025, the capability had clearly matured. In July 2025, Google announced they'd scaled up Big Sleep and found over 20 vulnerabilities across multiple open-source codebases.

And, as you've guessed, one of those codebases was FFmpeg. Google's Big Sleep agent scanned the FFmpeg codebase and automatically generated vulnerability reports, which then got submitted through Google's Issue Tracker. At least 13 of them, in fact!

Why Maintainers Are Upset

Now, you'd imagine it's a good and wonderful thing when a security researcher points out a security flaw in your system, so you can keep it secure. But...

Sources: [1] [2]

What's going on? FFmpeg is outraged that a trillion-dollar company like Google, that uses FFmpeg for free, is filing a bunch of AI-found bug reports and invoking the 90-day disclosure policy on unpaid volunteers. They're even more outraged that the affected part of the code is an obscure, antiquated decoder that, in FFmpeg's allegations, Google itself almost certainly doesn't use (a codec format used for mid-90s game cutscenes).

Worse yet, if these bug reports are not addressed within 90 days, headlines will go around with:

We Found X Vulnerabilities in FFmpeg Using AI! FFmpeg Failed to Address It!

causing reputational damage to FFmpeg.

The use of AI in and of itself is not terribly offensive to FFmpeg maintainers. Rather, the ask that FFmpeg makes is that if a trillion-dollar company's AI can spend the time and token-money to find the bugs, surely the company can spare some time to send some tested patches, too.

Disclosure Policy, Pre- and Post-AI

For context on the 90-day disclosure policy, when a security researcher submits a vulnerability report, the vendor has 90 days to develop and release a fix. After that 90 days is up, the full details of the vulnerability get published. If the vendor patches the bug before the 90-day deadline, they get an additional 30 days for users to adopt the patch before disclosure.

And I should say I understand why such a deadline must exist. When you join a company's security department, you learn quickly that a vulnerability without a deadline or clear owner is a vulnerability that won't get fixed.

This policy is reasonable in a pre-AI world when vulnerability discovery is comparably slower and labor-intensive. It becomes harder to uphold when AI enables a single researcher to find and generate far more reports that previously would have taken weeks or months to produce.

Professional security researchers typically understand the full context of what they're reporting, and work collaboratively with maintainers to arrive at a fix that doesn't introduce new problems.

Yet the distribution of AI tools means that almost anyone can now scan for vulnerabilities and file reports, resulting in a lot of AI-generated reports.

On one hand, you do have legitimate reports, such as those by Google's AI agent. But with the distribution of AI tools, most members of the public can point an AI agent at their codebase, maintainers included. So "I found a bug in your project" becomes less of a contribution unless it is supplemented by the work that didn't become less labor-intensive because of AI, such as proposing patches and reasoning about whether those patches compose well with the rest of the system without introducing new issues.

On the other hand, you also have a slew of false reports, churned out by some eager randoms wielding AI, regardless of their understanding of how critical the vulnerability is or whether it's a legitimate vulnerability. The false reports have gotten bad enough that the open source project cURL has shut down their bug bounty program due to too many false reports that were generated by AI.

So who helps the volunteers work through these reports?

Not the AI agent, it can identify vulnerabilities and propose potential patches, but somebody ("body" as in person! person with human judgement!) must go back and forth with maintainers to make sure their patches won't break existing functionality or introduce new issues.

And before you say "just have the AI agent handle the back-and-forth with maintainers too," well, when you're a maintainer, the last thing you want to do is argue with a chatbot when you want a person who can be reasoned with and might change their mind.

You know the dread of calling customer support and getting a bot that doesn't actually solve your problem...

This can invite resentment from volunteer maintainers, who, from their POV, have been put on a countdown timer to close out the report, with reputational damage if they can't meet an externally-imposed deadline on what is volunteer work and not their full-time job. And, from the volunteer maintainer's POV, the security researcher gets to demonstrate their AI capabilities and collect the clout of having found a vulnerability in a commonly-used codebase.

From the security researcher's POV, the vulnerabilities are not getting fixed fast enough given the risk they represent. And the AI slop reports hurt them too, as a finding that they tastefully validated with their own two hands gets stuck behind a queue of low-quality slop reports, and receives undeserved hostility due to being met with an AI-weary maintainer.

It's Just a Rehash of the Engineer-vs-Security Divide, Now With AI

I'm inclined to say that this tension between open source maintainers and security research wasn't invented by AI, but rather brought attention to a cultural difference that already exists between security and engineering.

Even from 2018, there already existed advice columns floating around the tech blogosphere along the ilk of "How to Be a Security Person that Engineers Don't Hate" and "How to be an Engineer that Security People Don't Hate."

Bluntly put, in the tech industry, the security department is often seen as a Cost Center, and engineering as a marginally more redeemable Cost Center that builds the features that customers sometimes or someday hopefully will pay for. So in this light, the security department can be seen as some pesky troll bridge that's standing between engineering and shipping, that exists mostly to cover the company in case something goes wrong later.

Stop! Who approaches the Bridge of Deploy must answer me These Questions Three, ere the other side he see.

That as long as nothing is going wrong today, the engineering department's priority is on shipping the features that make money and justify the company's existence, don't worry about the hypothetical breach when you got a demo due this week.

(For what it's worth, when you join a very, very large company, you also get shocked the number of vulnerabilities that can be chilling in the backlog and how the company is... fine, in spite of all that. This fact is often shocking to the freshers who come out of offensive security and join a defensive team expecting every unpatched finding to be a SEV 1.)

While open source doesn't have literal revenue to map this onto, we can see a similar split in how a maintainer spends their time. "Profit center" work is the work that feels generative, like shipping features and improving the user experience. Meanwhile, the "cost center" work feels more hygienic, like bug fixes and dependency updates, that the user won't notice when it's done, but sure as day will notice on the rare occasion it isn't.

So from the POV of maintainer, a vulnerability report looks like any other bug report, except this bug has mysterious special privileges over other kinds of bugs. It has a deadline! And it comes with reputational damage if not fixed! Look at it, all high and mighty with ominous warnings of a security breach and an unflattering headline if we don't act now!

"We Hacked Insert Name of Your Project in XYZ Days, Why Don't Maintainers Care About Security?"

Without a way to independently judge how serious the researcher's finding is, it may appear to the volunteer maintainer to be a pesky bug report that gets artificially bumped to the top of the queue, ahead of the other work that they would find rewarding.

Nick Wellnhofer reached a similar conclusion in the months leading up to his stepping down as libxml's sole maintainer. After years of triaging security reports under deadline, he came to the bleak conclusion that the urgency around security was mostly performative, that it lends street credit to the security researcher, but remains invisible to the end user who won't notice whether the fix was shipped in 3 days or 90 or at all.

"The more I think about it, the more I realize this is the only way forward. I've been doing this long enough to know that most of the secrecy around security issues is just theater. All the 'best practices' like OpenSSF Scorecards are just an attempt by big tech companies to guilt trip OSS maintainers and make them work for free."

Full article at LWN.net.

As of November 2025, libxml2 is without a maintainer.

We must rethink how security research and open-source maintenance intersect. There are many volunteer-driven projects that power our infrastructure that may be headed for the same fate, if we don't figure out more sustainable norms around security disclosure and support the people maintaining them.

Can Corporations "Just" Fix This?

A common argument around this is that wealthy corporations should help by becoming maintainers of the open source projects they use. These companies have the resources and engineering talent to maintain the infrastructure they depend on.

This is already a common practice in industry. Big corporations are known to assemble teams of paid employees to drive development of open-source projects. We see this with Meta for PyTorch and React, Google for Kubernetes and TensorFlow, and Microsoft for TypeScript. It has been very good for the ecosystem.

I agree with these sentiments, but even with backing, our attention as humans has limits. There are only so many hours in a day, and simply hiring more people doesn't fix the problem.

Again, Human Slop Predates AI, and Paid Maintainers Get It Too

To this, I say that absurd vulnerability reports have existed even in the pre-AI era. Very, very sobering post from Dan Abramov, a maintainer of the open-source React @ Meta from 2021: npm audit: Broken by Design.

The amusing absurd reports:

Wait, what?! If the attacker can modify my app’s source code, they’ll probably just put a bitcoin miner in it. Why would they add SVG files into my app, unless you can mine bitcoins with SVG? Again, this doesn’t make any sense.

Verdict: this “vulnerability” is absurd in this context.

And goodness, when you scroll to the bottom of the post, you see a ton of discussion around how to filter out the absurd reports, which sound not too different from the post-AI debates we see today!

As any security professional will tell you, development dependencies actually are an attack vector, and perhaps one of the most dangerous ones because it’s so hard to detect and the code runs with high trust assumptions. This is why the situation is so bad in particular: any real issue gets buried below dozens of non-issues that npm audit is training people and maintainers to ignore. It’s only a matter of time until this happens.

And wow, he is proposing a solution that I originally wrote in my first draft of this post and then deleted! Deleted, because if a dude from 2021 proposed the same thing and we're still having the same modern problems, then that proposal clearly was not sufficient on its own.

... I also have a proposal: I need a way to mark for my users that a certain vulnerability can’t possibly affect them. If you don’t trust my judgement, why are you running my code on your computer? I’d be happy to discuss other options too.

And wow, he is saying precisely the thing that I am saying in my very post! Man, cut this out and tape it on the wall, that there is the MOTWAAW!

The root of the issue is that npm added a default behavior that, in many situations, leads to a 99%+ false positive rate, creates an incredibly confusing first programming experience, makes people fight with security departments, makes maintainers never want to deal with Node.js ecosystem ever again, and at some point will lead to actually bad vulnerabilities slipping in unnnoticed.

AI doesn't submit slop, but rather people use AI to submit slop. Irresponsible people have existed pre-AI, and irresponsible people have inundated maintainers with false reports pre-AI. The existence of AI simply multiplies their ability to submit false reports.

About that "multiplication in ability"

I think it'd be a misnomer to treat the exponential increase in bug reports as permanent. Rather, I'm increasingly convinced that the influx of reports is coming from two sources:

(A) piles of legitimate vulnerabilities that went undiscovered for years, that are now easier to mine once you point an AI agent at them. This has kicked off a gold rush for people who want easy CVEs.

(B) AI slop.

After the low-hanging fruit from (A) gets picked clean and the gold rush settles down, we're left with a trickle of legitimate reports and a whole lot of (B), and it'll be a situation not too different from the sorts of debates you see in Dan Abramov's pre-AI post npm audit: Broken by Design.

So the question we're dealing with sounds more like "how do we filter out slop from the smaller, steadier stream of vulnerability reports that're left" rather than catastrophizing "oh no!!! reports are going to keep growing exponentially forever and maintainers will never keep up." Maintainers were already barely keeping up seven years ago!

One idea that has been floating around that I find interesting is this idea of requiring reporters to pay a lump-sum deposit when filing a report, refunded only when maintainers validate the finding, on top of the standard bug bounty.

I think this could help with filtering out low-confidence, low-criticality reports, provided that the deposit is sized appropriately.

Though, as with any attempt to price something intangible, I can already picture all the disputes that can come from such a policy. It might encourage Tony the Token Tycoon who has lots of monies to spam a bunch of false reports, while discouraging Benny the Bedroom Bughunter who's a 16-year-old kid saving up money to submit their one excellent finding.

And if the lump sum is imposed without much reduction on the volume of reports, well, now you've given everybody a second thing to be aggrieved about.

Policy is hard.

Going Forward

I'm not sure anyone has answers yet - if we didn't have answers pre-AI we sure as day won't have better answers post-AI. And we're early enough into this wave of AI Security that our norms around disclosure and remediation haven't adjusted quite yet.

But we do need to be cognizant when we're reporting to volunteer-led projects, as their time and incentives differ considerably from a paid team. If I want responsive maintainers for the software I depend on, then I need to be part of making this responsiveness sustainable.