You may never have heard of FFmpeg, but you’ve used it. This open source program’s robust multimedia framework is used to process video and audio media files and streams across numerous platforms and devices. It provides tools and libraries for format conversion, aka transcoding, playback, editing, streaming, and post-production effects for both audio and video media.

FFmpeg’s libraries, such as libavcodec and libavformat, are essential for media players and software, including VLC, Kodi, Plex, Google Chrome, Firefox, and even YouTube’s video processing backend. It is also, like many other vital open source programs, terribly underfunded.

Corporate Responsibility vs. Volunteer Labor

A lively debate on Twitter began between Dan Lorenc, CEO and co-founder of Chainguard, the software supply chain security company, the FFmpeg project, Google, and security researchers over security disclosures and the responsibilities of large tech companies in open-source software.

The core of the discussion revolves around how vulnerabilities should be reported, who is responsible for fixing them, and the challenges that arise when AI is used to uncover a flood of potentially meaningless security issues. But at heart, it’s about money.

An Obscure Bug Ignites the Controversy

This discussion has been heating up for some time. In mid-October, FFmpeg tweeted that “security issues are taken extremely seriously in FFmpeg, but fixes are written by volunteers.” This point cannot be emphasised enough. As FFmpeg tweeted later, “FFmpeg is written almost exclusively by volunteers.”

Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and listen to me … ”

The Growing Burden on Open Source Maintainers

The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,” which the FFmpeg developers did patch, is “an issue with decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.”

Wow.

FFmpeg added, “FFmpeg aims to play every video file ever made.” That’s all well and good, but is that a valuable use of an assembly programmer’s time? Oh, right, you may not know. FFmpeg’s heart is assembly language. As a former assembly language programmer, it is not, in any way, shape, or form, easy to work with.

As FFmpeg put it, this is “CVE slop.”

Many in the FFmpeg community argue, with reason, that it is unreasonable for a trillion-dollar corporation like Google, which heavily relies on FFmpeg in its products, to shift the workload of fixing vulnerabilities to unpaid volunteers. They believe Google should either provide patches with vulnerability reports or directly support the project’s maintenance.

Earlier, FFmpeg pointed out that it’s far from the only open source project to face such issues.

Specifically, the project team mentions Nick Wellnhofer, the former maintainer of libxml2, a widely used open source software library for parsing Extensible Markup Language (XML). Wellnhofer recently resigned from maintaining libxml2 because he had to “spend several hours each week dealing with security issues reported by third parties. Most of these issues aren’t critical, but it’s still a lot of work.

“In the long term, this is unsustainable for an unpaid volunteer like me. … In the long run, putting such demands on OSS maintainers without compensating them is detrimental. …  It’s even more unlikely with Google Project Zero, the best white-hat security researchers money can buy, breathing down the necks of volunteers.”

Google’s Controversial Security Disclosure Policy

What made this a hot issue was that back in July, Google Project Zero (GPZ) announced a trial of its new Reporting Transparency policy. With this policy change, GPZ announces that it has reported an issue on a specific project within a week of discovery, and the security standard 90-day disclosure clock then starts, regardless of whether a patch is available or not.

Many volunteer open source program maintainers and developers feel this is massively unfair to put them under such pressure when Google has billions to address the problem.

FFmpeg tweeted, “We take security very seriously, but at the same time, is it really fair that trillion-dollar corporations run AI to find security issues in people’s hobby code? Then expect volunteers to fix.”

True, Google does offer a Patch Rewards Program, but as a Twitter user using the handle Ignix The Salamander observed, “FFmpeg already mentioned the program is too limited for them, and they point out the three patches per month limit. Please don’t assume people complain just for the sake of complaining, there is a genuine conflict between corporate security & usage vs open source support IMHO.”

Lorenc argues back, in an e-mail to me, that “Creating and publishing software under an open source license is an act of contribution to the digital commons. Finding and publishing information about security issues in that software is also an act of contribution to the same commons.

“The position of the FFmpeg X account is that somehow disclosing vulnerabilities is a bad thing. Google provides more assistance to open source software projects than almost any other organization, and these debates are more likely to drive away potential sponsors than to attract them.”

Differing Perspectives on Vulnerability Disclosures

The fundamental problem remains that the FFmpeg team lacks the financial and developer resources to address a flood of AI-created CVEs.

On the other hand, security experts are certainly right in thinking that FFmpeg is a critical part of the Internet’s technology framework and that security issues do need to be made public responsibly and addressed. After all, hackers can use AI to find vulnerabilities in the same way Google does with its AI bug finder, Big Sleep, and Google wants to identify potential security holes ahead of them.

The reality is, however, that without more support from the trillion-dollar companies that profit from open source, many woefully underfunded, volunteer-driven critical open-source projects will no longer be maintained at all.

For example, Wellnhofer has said he will no longer maintain libxml2 in December. Libxml2 is a critical library in all web browsers, web servers, LibreOffice and numerous Linux packages. We don’t need any more arguments; we need real support for critical open source programs before we have another major security breach.