- FFmpegは世界中のメディア処理を支える中核的なオープンソースフレームワークであり、VLC・Chrome・YouTubeなど主要サービスで使われる不可欠な構成要素
- 最近、GoogleのAIベースのセキュリティスキャナーが1995年のゲームコーデックに関する些細なバグを発見したことで、大企業がボランティア開発者に過度な負担を強いているとの議論が拡大
- FFmpeg側は「プロジェクトはほぼ全面的にボランティアによって維持されている」とし、Googleは脆弱性報告をするだけでなくパッチ提供または資金支援を行うべきだと主張
- GoogleはProject Zeroの公開ポリシーとPatch Rewards Programを根拠に、透明性のあるセキュリティ貢献を強調したが、FFmpegコミュニティは報酬上限や現実的な支援不足を指摘
- 今回の論争は、AIが生成した大量のCVEとオープンソース保守の持続可能性という問題を浮き彫りにし、大手テック企業の責任を巡る議論へとつながっている
FFmpegとGoogleの対立の概要
- FFmpegは、音声・動画ファイルのトランスコード、再生、ストリーミングを支援するオープンソースのマルチメディアフレームワーク
- libavcodec、libavformatなどの中核ライブラリは、VLC、Kodi、Plex、Chrome、Firefox、YouTubeなどで利用されている
- しかし、他の主要オープンソースプロジェクトと同様に深刻な資金不足の状態にある
- X上で、FFmpeg、Google、Chainguard、セキュリティ研究者の間で、セキュリティ脆弱性の公開方法と責任の所在を巡る論争が発生
- AIが生成した大量の脆弱性報告は、実際の価値が低いことが多いという点が議論の中心
論争の発端: GoogleのAIが見つけた些細なバグ
- GoogleのAIエージェントが、FFmpegでLucasArts Smushコーデックのデコードに関するバグを発見
- この問題は、1995年のゲーム Rebel Assault 2 の最初の10〜20フレームにのみ影響する中程度の脆弱性
- FFmpeg開発者はこれを修正したが、「CVEの乱発(CVE slop)」と表現して、非効率な報告を批判
- FFmpegは「FFmpeg aims to play every video file ever made」とし、完全な互換性を目標にしている一方、コードの大半がアセンブリ言語で書かれており保守が難しいと述べた
オープンソース保守者の負担
- FFmpegコミュニティは、GoogleのようにFFmpegを利用する大企業が無償ボランティアに脆弱性修正を押し付けていると批判
- Googleは脆弱性を報告する際に、パッチ提供または資金支援も併せて行うべきだという立場
- 類似例として、libxml2の保守者Nick Wellnhoferが、繰り返される第三者からのセキュリティ報告を理由に保守中止を表明
- 彼は「報酬のないボランティアが毎週数時間をセキュリティ問題の処理に費やすのは持続不可能だ」と述べた
Google Project Zeroの公開ポリシー論争
- 2025年7月、Google Project Zero(GPZ) は『** Reporting Transparency**』ポリシーを導入
- 脆弱性発見後1週間以内に公開され、その後90日以内の修正期限が自動的に始まる
- パッチが準備できていなくても公開が進むため、ボランティア中心のプロジェクトに過度な圧力を与えるとの批判
- FFmpegは「AIが趣味のコードのセキュリティ問題を見つけ出し、ボランティアに修正を求めるのは公平なのか」と問いかけた
- GoogleのPatch Rewards Programは存在するものの、FFmpegは**「月3件の制限などにより実質的な助けにならない」**と指摘
相反する見方とオープンソースの持続可能性
- ChainguardのDan Lorencは、「セキュリティ脆弱性の公開もまたデジタル公共財への貢献だ」としてGoogleの役割を擁護
- 彼は「Googleはオープンソース支援に最も積極的な企業の一つであり、この種の論争はむしろ支援者を遠ざけかねない」と主張
- しかしFFmpeg側は、AIが生成した大量のCVEに対応する人員と資金が不足していると強調
- セキュリティ専門家は、FFmpegがインターネットインフラの中核構成要素である以上、脆弱性の公開は必要だと認めている
- 記事の結びでは、「大企業による実質的な支援なしには中核的オープンソースプロジェクトの維持は不可能」とし、libxml2の事例を挙げて持続可能な支援構造の必要性を強調
15件のコメント
まさか、WordPress財団とWP Engineの企業関係のように破綻することにはならないですよね？
https://daniel.haxx.se/blog/2024/…
の延長線上にある話に見えます。
上の記事は個人がバグバウンティ狙いで送る、完全に的外れなレポートでしたが、FFmpegの件は大企業が送る有効ではあるものの些末なレポートですね
Googleが指摘したからといって、必ず対応しなければならないのでしょうか？
脆弱性そのものが公開されてしまう状況なので、対応せざるを得ないように思います。
ああ…そういう観点があったんですね。教えてくださってありがとうございます！
脆弱性が公開されて、それを使って攻撃してくる可能性があるということですね、なるほど…。
公開されようがされまいが、困るなら自分で直せと言ってしまってもいいのかもしれませんが、そういう性格ではない人たちがメンテナーだからこそ、ここまで発展してきたのだと思います
ああ……おっしゃる通りのようです。
少し自分の視点だけで考えすぎていたようです。
ありがとうございます！
Hacker Newsの意見
記事で印象的だった部分があった。Amazon社内でFFmpeg関連の判断を止めるために、Mark Atwood が上司たちに「彼らはベンダーではなく、NDAもなく、私たちは彼らに影響力を行使できない」と説明しなければならなかったという話だ。
私は「問題だけを持ち込まず、解決策も持ってこい」という言葉には同意するが、Google にバグを見つける金があるなら、直すことにも金を使えるはずだと思う
そうすれば非公開パッチに依存せずに済み、最初に助けてもらったプロジェクトに恩返しもでき、倫理的にも正しい。
だが実際には、企業内部の コンプライアンスや手続き上の障壁 のせいで upstream が難しいのが問題だった
S&P500企業の社員がバグを報告するには一定額を寄付しなければならず、一定額以上を払わない限り一定期間内の返答は期待できない、という 風刺的なライセンス を想像してみた。
企業は不都合になるとソフトウェアをクローズドにしたりAGPLへ切り替えたりするのをためらわないのだから、今度は自分たちが直接代償を払う番だ
私はオープンソースの メンテナー として、大企業がセキュリティ問題を公開することで無償労働を強いているように見える、という感覚には共感する。
だが実際には、誰が報告したかに関係なく、セキュリティ問題は結局私が解決しなければならない課題だ。
プロジェクトがセキュリティを優先しないのも構わないが、その場合はそれに伴う評判リスクも受け入れるべきだ
商用企業に対して迅速な修正を求めるのは妥当だが、ボランティアベースのOSS に同じ要求をするのは現実的ではない
1995年のゲームの最初の10〜20フレームでしか発生しない問題らしく、これを「中程度の深刻度」に分類したのは大げさだと感じる。
メンテナーの時間を浪費させる事例に見える
深刻な問題なら誰が知らせてもよいし、些細または誤った報告なら無視すればよい。
結局どのバグを直すかはプロジェクト自身が判断すべきだ
私はFFmpegチームの立場を支持する。多くの企業はFOSSを マーケティング目的のイメージ洗浄 にしか使わず、実際には貢献しない。
昔なら単に海賊版を使っていたような人たちが、今ではライセンスのおかげで良心の呵責なく利用しているようなものだ
社内で使っていないコーデックまでテストしているのは純粋に公益目的だ。
もちろんGoogleにはFFmpegへもっと資金提供する余力があるが、今回のメンテナーに直接資金を渡すことには同意しない
自由に使える一方で、乱用の余地も大きい。
GPL 3 が行き過ぎだという批判もあるが、少なくとも搾取を防ごうという意図はあった
無料で時代を定義するソフトウェアを作る人たちと、それを利用して あらゆる価値を吸い上げる企業 がいる。
前者は愛で動き、後者は取引で動く
大企業には公開の脆弱性開示が必要だが、リソース不足のOSS にはリスクの方が大きいかもしれない
Googleが迅速な修正を望むなら パッチも一緒に提出 すれば皆に利益がある
特に LLMが発見できる程度の脆弱性 なら、いずれ悪用される可能性が高い。
公開のおかげで利用者は自衛でき、FFmpegがこれを修正することにしたのも自発的な選択だ。
セキュリティ研究そのものがオープンソースへの 高コストな貢献の形 でもある。
研究者に「貢献が足りない」と言うのは、むしろボランティアに無償労働を求めることになる
FOSSの透明性はむしろセキュリティ意識の向上に役立つ
現実のグレーゾーンを認めない
「メール1通で3つの製品ラインを止められるなら」、年間1万〜2万ドル程度の支援金 は保険料としても十分だと思う
GoogleとAmazonがそれぞれ5万ドルずつ支援するだけでもFFmpeg開発者は安定して働けるはずで、
とりわけYouTubeを運営するGoogleなら10万〜20万ドル程度は簡単に出せるだろう
Googleのセキュリティ責任者がFFmpegへの貢献内容をまとめた Twitterスレッド を共有する
1兆ドル企業が人員や資金に乏しいというのは説得力がない
Project Zero の目的が気になる。
単に脆弱性を見つける以上の理由があるのか知りたい
同時に セキュリティ人材の獲得と評判管理 にも有利だ。
ただ、そこまで余裕があるならパッチ作成にも投資すべきだと思う
問題の脆弱性は Use After Free で、GoogleのAIがこれを見つけた。
だがそれを直すのに3秒もかからないような話ではない。
金が有り余る企業がボランティアプロジェクトに スパム同然のバグレポート を投げつけるのは不快だ
CVEに分類するほどのものではなく、単なるバグレポートで十分だったはずだ
メモリリークを防ぐにはもっと複雑な修正が必要だ。
おそらくこのコーデックは デフォルト無効 のままが正しい方向だ
餌を与えたら、風呂敷まで差し出せと言っているようですね。
バグレポートも間違いなく重要な貢献ではあるはずですが……
自発的に地域の掃除をしている人がいるのに、その地域の土地をいちばん多く持っている有力者が、その掃除している人に「あそこの隅にタバコの吸い殻がありますよ」と言っているような感じだと思います。
私もこのたとえは的確だと思います。
適切なたとえです。
それって本当に大ごとなんでしょうか？ 読んでみると、かなり古典的な特定ゲームの最初の10〜20フレームでのみ有効な、中程度のセキュリティ脆弱性です。これが本当にFFmpeg側にとって重要な貢献だとお考えですか？ オープンソースコミュニティに対する最も重要な貢献は、安定した開発ができるよう支援することではないでしょうか。特に、その成果物をしっかり活用している企業であれば、まずそれが優先だと思いますが。
こういう人のせいで、XZにバックドアが仕込まれたんですよね
バグ報告そのものはS級なんですが、ケネディ大統領の時代にでも使っていたような古い動画フォーマットの重大な脆弱性に、期限内で対応できなかったとあちこち言いふらしているわけです。
食べられるものを渡すのではなく、食べなければならないものを渡しておいて、なぜ期限内に食べられないんだと言っているようなものです。
ffmpegは人手が限られているのに、GoogleがAIで、今ではもう使われてもいないフォーマットについて何十件ものバグ報告を浴びせ、期限内にすべて直せと圧力をかけるのは正しいのでしょうか?