オープンソースと企業の社会的責任
今回の PHP の脆弱性問題は、まさにソフトウェア産業が長年抱えてきた構造的な問題を浮き彫りにしたと思います。
オープンソースを利用して利益を得る企業は多いのに、その基盤を安全に維持するための費用や人材は、利用規模に見合う形では支えられていない。
これは単に企業のモラルの問題というより、ソフトウェアの開発・流通・保守の仕組みに原因がある問題だと思います。
今回の PHP の件では、2026年10月21日に、認証なしでリモートコード実行につながり得る重大な脆弱性を修正するリリースが公開されました。PHP Foundation も、修正の遅れには開発・セキュリティ担当者の不足だけでなく、難しい修正方針を決めるプロセス上の問題もあったと説明しています。
つまり、脆弱性を見つける技術があっても、それを調査し、修正し、互換性を検証し、世界中の利用者に届けるための組織と資源がなければ、問題は解決しません。
企業はオープンソースを支えるべきか？
オープンソースは、ソースコードを公開し、誰もが利用・検証・改良できる仕組みです。しかし、ソースコードが公開されていることと、そのソフトウェアが十分に保守されていることは別の話です。
例えば、ある企業が PHP を使ってサービスを運営しているとします。
PHP そのものを開発しているわけではない。
PHP の脆弱性を検査する専門家を雇っているとは限らない。
PHP の修正や新バージョンへの対応を自社で行っているとも限らない。
それでも、PHP が動かなければ自社のサービスが止まる可能性がある。
企業は PHP の開発費を直接負担しなくても、その恩恵を受けられます。個々の企業にとっては合理的な選択ですが、多くの企業が同じ判断をすると、基盤を維持する人々に負担が集中します。
この問題は、経済学でいう「フリーライダー問題」に近いものです。オープンソースのセキュリティと資金不足については、Atlantic Council も 2024年の調査 で取り上げています。
ただし、すべての利用者に同じ負担を求めるべきだとは思いません。個人の趣味の開発者と、世界中で大規模なサービスを展開する企業とでは、利用から得られる利益も、負担できる資源も大きく異なるからです。
企業が支援する仕組みの存在
実は、企業による支援は理想論ではありません。すでにいくつかの取り組みが進んでいます。
PHP Foundation — 開発者を継続的に支える
PHP の開発・保守を支えるために設立された組織です。企業などから資金を集め、開発者の雇用やセキュリティ対応に必要な体制を整えています。
今回の問題でも、専任のセキュリティ人材を増やし、対応プロセスの改善を進めています。
OpenSSF — 業界横断でセキュリティを支援する
Linux Foundation 傘下の組織で、オープンソースのセキュリティ改善、開発者向けのツールやベストプラクティスの普及などに取り組んでいます。企業単独では負担しにくい対策を、業界全体で進めるための基盤になります。
Patch the Planet — 脆弱性の発見から修正まで協力する
今回の PHP の対応では、OpenAI や Wiz などの研究者・セキュリティ企業が調査や検証、対応調整を支援し、PHP の開発者が修正を進めました。
単に脆弱性を報告するだけでなく、修正の準備や影響を受ける組織への情報伝達まで協力する取り組みです。
これらの活動が示しているのは、オープンソースを支える方法が寄付だけではないということです。
開発者を雇用し、保守作業に時間を割けるようにする。
専門家によるコード監査や脆弱性診断を実施する。
テスト環境、CI、ファジングなどの検証基盤を提供する。
脆弱性の発見から修正、公開までの調整を支援する。
利用企業が自社システムを棚卸しし、修正版を適用できるようにする。
こうした活動を継続できるかどうかが重要です。
企業の支援を当たり前にするには
次の4つを組み合わせた仕組みを考えます。
① 利用規模に応じた資金負担
大規模なオープンソース利用企業が、利用している重要プロジェクトの維持費を継続的に負担する仕組みです。
例えば、次のようなイメージです。
これは制度設計の一案ですが、重要なのは、支援をその場限りの善意に依存させないことです。
特に、複数の企業が同じソフトウェアに依存している場合は、共同基金を設けて、特定の企業が支援をやめても開発が止まらないようにすることが合理的です。
② 自社のエンジニアを上流の保守に参加させる
資金だけでなく、技術者を提供する方法もあります。
例えば、PHP を大量に利用する企業なら、次のような活動が考えられます。
PHP 本体や関連ライブラリのコードレビューに参加する。
セキュリティテストやファジングを実施し、結果を上流に還元する。
修正パッチや回帰テストを作成する。
自社の運用で得られた知見を開発コミュニティと共有する。
企業にとっても、自社のエンジニアが基盤ソフトウェアを深く理解することは、障害対応能力の向上につながります。
ただし、貢献を自社製品に必要な機能の開発だけに限定せず、セキュリティや長期保守にも一定の時間を配分することが大切です。
③ 重要なソフトウェアを社会インフラとして扱う
PHP、Linux、OpenSSL、各種データベースなどは、単なる便利な道具ではありません。多くの企業や公共機関が共有する技術基盤です。
このようなソフトウェアについては、民間企業の自主的な支援だけでなく、公的な資金によるセキュリティ監査や保守支援も検討に値します。
もっとも、政府がすべてのオープンソースを管理する必要はありません。重要なのは、社会的な影響が大きいにもかかわらず、保守の担い手が不足しているプロジェクトを特定し、必要な支援を届けることです。
④ 支援の成果を見えるようにする
寄付金額だけでは、本当にセキュリティが改善したかどうかは分かりません。そこで、例えば次のような指標を公開します。
重要な脆弱性の報告から修正までに要した時間
セキュリティ監査やファジングの実施状況
修正に対応できる開発者の人数
重要なリリースに対するテストの充実度
利用企業への修正版の配布と適用状況
こうすれば、企業は支援の効果を評価できますし、資金をどこに投入すべきかも判断しやすくなります。
ただし、修正までの時間を短くすることだけを目標にすると、十分な検証を省略する誘因にもなり得ます。単一の指標で競わせるのではなく、品質や再発防止も含めて評価すべきです。
資金を出せば解決するわけではない
企業が資金を提供しても、特定の企業の要望が開発方針を左右するようになれば、プロジェクトの独立性が損なわれる可能性があります。また、資金を集める組織の運営費や配分方法も問題になります。
そのため、支援の仕組みには次の条件が必要だと思います。
中立性
資金提供企業が、脆弱性の公表や修正方針を不当に左右しない。継続性
単年度の寄付ではなく、複数年の予算や複数の支援者を確保する。透明性
資金の使途とセキュリティ改善の成果を公開する。責任分担
開発者だけでなく、資金提供企業、ソフトウェアの配布者、利用企業もそれぞれの役割を果たす。
そして忘れてはいけないのが、オープンソースの開発者に、無償で完璧なソフトウェアを提供する義務があるわけではないということです。
バグや脆弱性をゼロにすることは現実的ではありません。求めるべきなのは、脆弱性を発見しやすくし、適切に修正し、利用者が迅速に対処できる仕組みを維持することです。
まとめ
今回の問題を見て感じることは、オープンソースの利用と維持の間にある非対称性です。
ソフトウェアを利用する企業は、導入すればすぐに利益を得られます。
一方、保守やセキュリティ対策の成果は、問題が起きなければ目立ちません。企業の予算配分では、売上につながる新機能や目に見える製品開発が優先され、将来の事故を防ぐための基盤整備は後回しになりがちです。
しかし、社会全体で見れば、重大な脆弱性を未然に発見し、修正できる体制を維持することには大きな価値があります。
だからこそ、次の考え方が広がってほしいと思います。
オープンソースを利用する企業は、単なる利用者ではなく、そのソフトウェア基盤を維持する共同責任者でもあるということです。
すべての企業がソースコードを修正できる必要はありません。しかし、自社がどのオープンソースに依存しているかを把握し、その重要度に応じて資金、人材、技術、運用のいずれかで維持に貢献する。それを企業の IT ガバナンスの一部として定着させることは、十分に可能だと思います。
今回の PHP の問題は、脆弱性を発見することだけでなく、発見された問題を解決し続けるための社会的な仕組みが必要だということを示しています。
私は、このテーマは技術論にとどまらず、企業の社会的責任やデジタル社会の持続可能性という観点からも、考える価値があると思います。
