オープンソースのサイバーセキュリティは時限爆弾

3月、ソフトウェアのバグがウェブの広範囲に影響を及ぼす恐れがあった。無数のソフトウェア製品やオペレーティングシステムに組み込まれているオープンソースの圧縮ツール「XZ utils」にバックドアが埋め込まれていたことが発覚した。

バックドアは、ソフトウェアへの秘密のエントリ ポイントであり、必要なコードを持つ人物が、そのソフトウェアを実行しているマシンを乗っ取り、管理者としてコマンドを発行することを可能にします。バックドアが広く配布されていた場合、数百万人の人々に潜在的な災害が発生していた可能性があります。

幸運なことに、悪意のあるアップデートが広く流通する前に、Microsoft のソフトウェア エンジニアがコードの不規則性に気付き、報告しました。その後、プロジェクトは責任者によって引き継がれ、修正されました。

惨事はかろうじて回避されたものの、この事件は、オープンソース開発モデルに長年存在し、簡単には解決できない問題が現在も続いていることを浮き彫りにしました。XZ 事件は、オープンソースのバグが Web の広範囲に影響を及ぼす恐れがあった初めての事例ではありません。これが最後になることはまずないでしょう。オープンソース ソフトウェアがもたらす厄介なサイバー セキュリティのジレンマを理解するには、その複雑で、まったく直感的ではないエコシステムを詳しく調べる必要があります。ここでは、初心者向けに、その方法をご案内します。

ウェブはFOSSで動く

現在、コードベースの大半はオープンソース コードに依存しています。すべてのソフトウェア「スタック」の70 ～ 90 パーセントがオープンソース コードで構成されていると推定されています。おそらく、携帯電話のアプリの大半はオープンソース コードで設計されており、Android を使用している世界の 25 億人のうちの 1 人であれば、デバイスのオペレーティング システムは、世界最大のオープンソース プロジェクトであるLinux カーネルから生まれたソフトウェアの修正バージョンです。

ソフトウェアの「サプライ チェーン」、つまり私たちが好む Web 製品やサービスを支えるデジタルの足場について話すとき、そのコードの多くはオープンソース コンポーネントで作られています。オープンソースは広く普及しているため、観察者はオープンソースをインターネットの「重要なインフラストラクチャ」と呼んでいます。これは、不可欠であると同時に非常に強力な、変幻自在な物質です。

しかし、オープンソース ソフトウェアは重要であるにもかかわらず、テクノロジー業界以外のほとんどの人には広く理解されていないテーマです。ほとんどの人は、オープンソース ソフトウェアについて聞いたこともありません。

オープンソースを使用する理由

初心者向けに簡単に説明すると、次のような感じになります。「クローズド」またはプロプライエタリなソフトウェアとは異なり、フリーおよびオープンソース ソフトウェア (FOSS) は公開検査可能であり、誰でも使用または変更できます。その使用はさまざまなライセンス契約によって決定され、非常にユニークなことに、コンポーネントは多くの場合、ボランティアによって保守されています。ボランティアは、ソフトウェアを最新の状態に保ち、良好な動作状態に保つために自由時間を費やす無給の開発者です。

オープンソース プロジェクトは、ほとんどどんな形でも開始できます。多くの場合、単に何か新しいものを作りたいと考えているデジタル技術者のための小規模なプロジェクトです。最終的に、一部のプロジェクトが人気を博し、民間企業がそれらを商用コードベースに組み込み始めます。多くの場合、企業の開発チームが新しいアプリケーションの作成を決定すると、数百行または数千行のコードで構成される、既存の小規模なソフトウェア コンポーネントを大量に使用してアプリケーションを構築します。今日では、これらのコンポーネントのほとんどはオープンソース コミュニティから提供されています。

商用ソフトウェアとオープンソース エコシステムの間のこの奇妙な関係がどのように機能するかを想像するのは、少し難しいかもしれません。幸いなことに、数年前にウェブコミック アーティストの Randall Munroe が、この直感に反する動きを視覚化するのに役立つ、今ではよく知られているミームを作成しました。

企業が開発ニーズを満たすためにオープンソースを採用する理由は数多くあります。無料であるという事実に加え、FOSS ではソフトウェアを効率的かつ迅速に作成できます。プログラマーがアプリケーションのコードの基本構成要素について心配する必要がなければ、ソフトウェアのより市場性の高い要素に集中できるようになります。シリコンバレーのような競争の激しい環境では、市場投入までの時間が短いことが重要な利点であり、オープンソースは DevOps にとって必須の要素です。

しかし、スピードと俊敏性には脆弱性が伴います。FOSS が現代のソフトウェアの普遍的な要素であるならば、大量のソフトウェアを危険にさらすエコシステム構造上の問題もあります。これらの問題はすぐに非常に厄介なものになり、悲惨な結果を招くこともよくあります。

地獄の虫

XZ の事件は惨事には終わりませんでしたが、簡単にそうなる可能性もありました。Web ユーザーがそれほど幸運ではなかった例の 1 つは、悪名高い「log4shell」事件です。3 年前の 2021 年 11 月、当時人気のあったオープンソース プログラム log4j にコードの脆弱性が発見されました。log4jのようなロギング ライブラリプログラムはアプリに定期的に統合されており、プログラマーはそれらを使用してプログラムの内部プロセスを記録および評価します。オープンソース組織Apacheによって管理されている log4jは、バグが発見された当時は広く使用されており、世界中の何百万ものアプリケーションに組み込まれていました。

残念ながら、log4j のバグ (「log4shell」と名付けられました) はかなり悪質でし た。XZ バグと同様に、リモート コード実行が関係していました。つまり、ハッカーは影響を受けたプログラムに独自の「任意の」コードを簡単に挿入でき、そのプログラムを実行しているマシンを乗っ取ることができるのです。log4j は人気があったため、バグの影響範囲は広大でした。数十億ドル規模の大企業が影響を受けました。何億台ものデバイスが脆弱でした。欠陥が明らかになった数日後、専門家は、脆弱性が時限爆弾であり、サイバー犯罪者がすでにそれを悪用しようとしていると推定しました。

このバグの発見は、アメリカの企業を大パニックに陥れ、連邦政府の最高レベルを震え上がらせた。世界最大の企業のいくつかが危険にさらされ 、国家安全保障の問題となった。バグ発見から数週間後、ジョー・バイデン大統領のサイバーセキュリティ顧問を務めるアン・ニューバーガーは、ホワイトハウスでオープンソースセキュリティに関するサミットを開催し、マイクロソフト、Meta、グーグル、アマゾン、IBMなどの大企業の幹部や、Apache、Linux Foundation、Linuxのオープンソースセキュリティ財団（OSSF）などの有力なオープンソース組織の幹部を招集した。この会議では 、この恐ろしい脆弱性をどう修正するかよりも、このようなことが二度と起こらないようにする方法を考えることに重点が置かれた。

会議後間もなく、当時のOSSFゼネラルマネージャーであるブライアン・ベーレンドルフ氏を含むLinux Foundationの最高幹部らは、FOSSエコシステム全体のセキュリティを強化するためのいわゆる「動員計画」の策定を開始した。一方、連邦政府は、テクノロジー業界をさらに規制するための独自の戦略を策定し始めた。最も注目すべきは、昨年発表されたバイデン大統領のサイバーセキュリティ計画で 、非常に破壊的な新しいバグの出現を防ぐため、いくつかの新しい安全策を優先することを目指していることである。

しかし、XZ の脆弱性を取り巻く危険性が示すように、FOSS は依然として、最高レベルでは、インターネットに壊滅的なシステム全体にわたる影響を及ぼす可能性のあるバグに対して脆弱な環境です。ただし、FOSS のリスクを理解するのは簡単ではありません。世界中のソフトウェアの多くを生み出す独自のエコシステムへの回り道が必要です。

クローズドソースはより安全であることを意味するわけではない

先に進む前に、1 つだけ明確にしておくと役立つでしょう。ソフトウェア プログラムが「クローズド ソース」またはプロプライエタリであるからといって、より安全であるとは限りません。実際、セキュリティの専門家や FOSS 支持者は、その逆であると主張しています。この問題については後でもう一度取り上げますが、とりあえず、Microsoft という小さな会社に注目してもらいます。この会社は、クローズド ソースの大手企業であるにもかかわらず、その製品ベースが何度もハッキングされ、時には悲惨な結果をもたらしています。製品をクローズドにしている多くの会社に同様の実績があり、オープン ソース ソフトウェアとは異なり、会社以外の誰もコードにアクセスできないため、セキュリティの問題は秘密にされることがよくあります。

メンテナー

オープンソース ソフトウェアのセキュリティ リスクについて話す場合は、まずコードの背後にいる人々について話す必要があります。オープンソース エコシステムでは、これらの人々は「メンテナー」と呼ばれ、当然ながらソフトウェアの品質維持を担当しています。

メンテナーの役割を説明するのは少し複雑です。メンテナーは、現実世界で道路や橋を建設する建設作業員によく似ているかもしれません。あるいは、それらを設計するエンジニア、あるいはその両方です。簡単に言うと、メンテナーは特定のオープンソース プロジェクトの管理者 (多くの場合は作成者) ですが、多くの場合、コードを改善したいソフトウェア ユーザーである「貢献者」と協力して作業します。

メンテナーはオープンソース プロジェクトを公開リポジトリでホストします。最も人気のあるのは Github です。これらのリポジトリには、最終的にはメンテナーによって制御されるインタラクティブなメカニズムが含まれています。たとえば、貢献者がプロジェクトに何かを追加したい場合、追加したい新しいコードを含む「プル リクエスト」を GitHub に送信することがあります。次に、メンテナーは「マージ」を承認する役割を担います。これにより、貢献者の変更が反映されてプロジェクトが更新されます。この共同作業プロセスを通じて、オープンソース プロジェクトは継続的に成長し、変化していきます。

こうした生きた反復的なプロジェクトのマスター コントローラーとして、メンテナーの仕事には、ユーザーや貢献者との継続的なやり取りから、コード コミットの承認、ソフトウェア内部のすべてが実際にどのように動作するかを示す「ドキュメント」ガイドの作成まで、膨大な作業が必要になることがよくあります。しかし、そのすべての作業に対して、メンテナーの多くは特に高い報酬を受け取っていません。ほとんどはまったく報酬を受け取っていません。オープン ソースは無料であるはずです。覚えていますか? FOSS の世界では、コードが有効に活用されているという知識以外に、ハードワークが報われることはほとんどありません。

メンテナーの苦境は特異なものであり、オープンソースの複雑な歴史、そしてそのコードを使用する企業との必ずしも単純ではない関係と深く結びついています。

FOSS のフラッシュ歴史

当初、オープンソースは企業主義やお金とはあまり関係がなかったことを考慮すると役に立ちます。実際は、その逆でした。

FOSS は、1980 年代の理想主義的なハッカー運動から生まれた「フリー ソフトウェア」運動です。事実上、この運動はリチャード ストールマンから始まりました。ストールマンは、ジェリー ガルシアに少し似ていて、大胆なサイバネティック理想主義を長年支持してきた風変わりなコンピュータ サイエンティストです。1983 年、MIT 人工知能研究所で働いていたストールマンは、フリー ソフトウェアのリポジトリであるGNUを設立しました。このコレクションの背後にあるアイデアは、ユーザー コントロールでした。ストールマンは、民間企業がソフトウェアを壁で囲まれた庭の背後に隠すことができるという考えに難色を示しました。ソフトウェア ユーザーは、使用するプログラムをコントロールする機能、つまり、プログラムがどのように動作するかを確認できるだけでなく、必要に応じて変更または修正できる機能が必要だと感じました。そのため、ストールマンは「フリー」ソフトウェアというアイデアを提唱し、「フリー」とは「言論の自由のようなものであって、無料のビールのようなものではない」という意味であると有名なコメントを残しています。つまり、ストールマンは開発者が報酬を得ることに反対しているわけではありませんが、開発者のコ​​ードは将来の改善のためにオープンですべての人に見えるようにすべきだと考えています。

1991年、当時21歳だったフィンランドのコンピュータープログラミング学生、リーナス・トーバルズが、オープンソースの歴史に新たな偉大なイノベーションをもたらしました。伝えられるところによると、退屈しのぎにトーバルズは新しいオペレーティングシステムを作成し、自分の名前にちなんで「Linux」と名付けました。重要なことに、トーバルズはLinux「カーネル」を作成しました。これは、コンピューターのハードウェアとデジタルプロセス間のインターフェースを管理する、オペレーティングシステムの重要なコンポーネントです。当時は明らかではありませんでしたが、Linuxはその後、世界最大かつ最も人気のあるオープンソースプロジェクトになりました。今日、トーバルズが作成したカーネルを使用するLinuxディストリビューション（または「ディストロ」）は数百あります。

1998 年、フリーソフトウェア コミュニティ内の小規模だが影響力のあるグループが、この運動の理想主義的なルーツから脱却し、ソフトウェアを主流にしようと決意した。カリフォルニア州マウンテン ビューでサミットが開催され、参加者はフリーソフトウェアを「企業が急いで購入する」ものに「再ブランド化」する方法について議論しようとした、と会議出席者の 1 人であり、有名なプログラマーの Eric Raymond氏は書いている。「オープン ソース」は「マーケティング用語」として売り込まれ、アメリカの技術界の巨人たちの想像力をかき立て、「フリー」という漠然とした共産主義に近い用語から彼らを遠ざける目的で作られた、と Raymond 氏は説明する。ビジネスマンがストールマンのヒッピーっぽい考えを忘れ、より実用的な響きの用語を受け入れることを期待した。

結局、彼らはストールマンの考えを信じている。当時はドットコム バブルで、シリコンバレーは活況を呈し、民間企業は利益を上げる新たな方法を渇望していた。多くの企業にとって、無償の労働力の共有プールとイノベーションの産業モデルを提供するオープンソースは、良いアイデアに思えた。こうして、「オープンソース」運動は「フリー」運動から大きく分裂し、企業が推進する独自の組織となり、やがてソフトウェア業界内でますます大きな位置を占めるようになった。Linux は普及し、トーバルズは有名になり、ストールマンはこれまでやってきたことをほぼ続け、デジタルの自由を主張し、企業ソフトウェア大手をけなした。今日、世界は「オープンソース」で動いているが、ストールマンは依然としてこの用語をきっぱりと拒否している。彼は依然として「フリー」ソフトウェアという用語を好んでいる。

コード・フォー・ナッシング

オープンソース ソフトウェアは企業にとってありふれたリソースになっていますが、その重要な素材の作成と維持に責任を持つ開発者は、必ずしも金銭面やその他の面で、当然受けるべきサポートを受けられるわけではありません。実際、多くの企業は、コードを手に入れて放り出すことに満足し、プロジェクトやその作成者に還元することなく、基本的に無料の成果物を搾取しています。

ここ数年、Tidelift 社は何百人ものオープンソース メンテナーへのインタビューに基づく調査結果を発表してきました。毎年の調査では、メンテナーは過重労働で、過小評価され、燃え尽きているというほぼ同じ結果が出ています。調査結果によると、オープンソース メンテナーの半数以上は仕事に対してまったく報酬を受けていません。2020 年の Linux Foundation による貢献者への調査でも同様に、回答者の半数以上 (約 51.65%) が報酬を受けていないと回答しています。

XZ 事件の原因は、メンテナーの燃え尽き症候群だとされています。実際、ソフトウェア プロジェクトの元のメンテナーは、プロジェクトが「遅れている」と感じており、最終的に「Jia Tan」というユーザーに責任を譲りました。このユーザーが、ソフトウェア コンポーネントにバックドアを導入した人物となりました。

民間部門に FOSS エコシステムのサポートを強化するよう求める声は長い間ありましたが、その声はほとんどの場合、無視されてきました。近年、大手テクノロジー企業がオープンソース エコシステムの特定の分野に資金を投入しているのは事実ですが、多くの場合、それは企業にとって有利な分野に限られています。

FOSS コーダーの大多数にとって、プロジェクトの維持にはまだほとんど報酬がないかまったくなく、楽しい趣味や本業というよりは報われない仕事である場合が多い。コードによるクリエイター経済を考えてみよう。Reddit では、開発者が FOSS の資金調達をブートストラップする方法について議論するスレッドが次々と見つかる。資金不足の開発者にお金を分け与えることで知られるオープンソースのクラウドファンディング プラットフォームである Liberapay に頼ることを提案する人もいる。Patreon が良い選択肢だと考える人もいる。少なくとも 1 人は、暗号通貨の助成金を使用してFOSS プロジェクトを後援するWeb3 スタートアップである Gitcoin に連絡するよう人々に勧めている。多くの開発者は、Github プロジェクト ページに Stripe、PayPal、Buy Me a Coffee などへのリンクを含む寄付ポータルを組み込んでいる。ほとんどのクリエイティブな取り組みと同様に、お金を乞うことが結局はお金を稼ぐ最も確実な方法である。

ハートブリード

非常に人気のあるソフトウェアを OnlyFans タイプの貢献によって維持することで、セキュリティ上の問題が発生する可能性があることは、おそらく想像できるでしょう。調査によると、商用アプリの大半には、更新されなくなったか、メンテナーによって放棄されたオープンソース コンポーネントが含まれています。

Heartbleed の話を知れば、分散化された、時には不安定な労働力プールを頼りに企業のデジタル インフラストラクチャを構築することの危険性がすぐにわかります。

2014年に発見されたHeartbleedバグは 、当時ウェブ上の安全な通信プログラムの多くを支えていたオープンソースの暗号化プロトコルであるOpenSSLの重大な脆弱性でした。Google、Facebook、Netflix、Yahooなどの大企業がこの脆弱性を利用しており、 VPNからインスタントメッセージングやメールプラットフォームまで、さまざまなアプリケーションやサービスも利用していました。当然のことながら、攻撃者が脆弱なサーバーを騙してユーザー名やパスワードなどの機密データを引き渡すことを可能にするこのバグの発見は、インターネットの大半でパニックを引き起こしました。

「誰もが使っていたものが、実際にはまったく報酬を受け取っていない数人の人々によってサポートされていたことがわかった」と、暗号の専門家でソフトウェア エンジニアのジョン カラス氏は、当時起こった混乱を振り返りながら語った。カラス氏は OpenSSL チームで働いていなかったが、そのチームに所属していた人々を知っており、当時は同様のプロジェクトに取り組んでいた。

Callas がほのめかしているように、OpenSSL の問題は必然的に保守担当者に帰結するようです。実際、多数の大手優良企業のプライバシーとセキュリティ サービスの保護を担当する OpenSSL は、実際には 11 人からなる小規模なチームによって保守されており、その中には4 人の「コア」チームと 1 人のフルタイム従業員しか含まれていないことが判明しました。

「これは本当に問題です」と、オープンソースのメンテナンス問題についてカラス氏は語った。カラス氏は、インターネットで広く使用されている PGP 暗号化のオープン スタンダードであるOpenPGPの主要設計者の 1 人として、この問題についてある程度の経験がある。「基本的に [デジタル] インフラストラクチャであるソフトウェア パッケージが、どのようにサポートされ、メンテナンスされるかを把握することは、大きな問題です。」

Heartbleed は、それまでのオープンソース セキュリティの運用パラダイムに実際に問題があることを明らかにしました。長年、FOSS の世界は、オープンソース ソフトウェアは商用ソフトウェアよりも安全だという教義に導かれてきました。その理由は、FOSS の透明性、つまり Web 全体にコードが公開されていることで、欠陥の可視性が向上し、その結果、欠陥を修正する機会が増えるというものです。これは、「より多くの目」の議論として知られています。つまり、商用ソフトウェアにはバグを監視する開発チームが 1 つしかないのに対し、オープンソースにはインターネット全体があるという考え方です。

この議論には洗練された論理がありますが、欠点もあります。「より多くの目」という議論は、FOSS プロジェクトが必要なものをすべて手に入れられる理想的な世界では有効です。もちろん、現実の世界では、オープン ソースのセキュリティは、それを維持するために割り当てられたリソースと人員によって決まります。多くの場合、FOSS プロジェクトには必要な目よりも少ない目しかなく、それ以上ではありません。あるいは、サイバー犯罪者のような間違った目がプロジェクトを監視している可能性もあります。

一定数の FOSS プロジェクトが信じられないほど安全であることは否定できません。Linux カーネルは、2005 年以来、約 14,000 人の貢献者によって精査されてきたと言われています。Linux Foundation は約 150 人の従業員を雇用しており、昨年の収益は推定 2 億 6,260 万ドルで、その大部分は企業および個人の貢献によるものです。多くの点で、そのサポートと透明性のおかげで、傍観者は XZ 脆弱性の明らかな生みの親である Jia Tan を捕まえることができました。しかし、Linux をオープンソース セキュリティの模範として使用することの問題は明らかです。ほとんどのオープンソース プロジェクトは Linux ではなく、Linux レベルのサポートも受けていません。

バックスタバーのナイフコレクション

Heartbleed が発生したとき、それはソフトウェア コミュニティにとって「警鐘」と見なされました。この事件は、米国企業の関心を初めてオープンソースを取り巻くセキュリティ問題に根本的に向けさせました。また、Linux Foundation は、追加サポートを必要とする極めて重要なオープンソース プロジェクトを特定するCore Infrastructure Initiativeの設立を余儀なくされました (2021 年 10 月に OSSF に置き換えられました)。

しかし、Heartbleed がデジタル炭鉱のカナリアだったとしても、結局は誰もが注目した問題ではありませんでした。実際、2014 年以降、FOSS が Web のより大きく不可欠な部分になったため、脅威の状況はますます複雑になっています。今日、問題は時折発生する壊滅的なバグに限定されません。実際、それよりもはるかに複雑です。

現代社会では、商用ソフトウェアはどこにでもあります。私たちの生活はかつてないほどデジタル化され、相互につながり、掃除機からエクササイズ器具、歯ブラシまで、所有するほぼすべてのものにアプリが付属しています。その結果、これらすべてのアプリを実行しているソフトウェアが侵害される機会が大幅に拡大しました。今日、いわゆるソフトウェア「サプライチェーン攻撃」は比較的一般的です。このような攻撃は、特に脆弱なソフトウェアコンポーネントを狙い、サイバー犯罪者が1つの弱い部分を悪用して、製品またはシステム全体を乗っ取ったり破壊したりすることがあります。多くの場合、サプライチェーンへの最初のアクセスを可能にするコンポーネントはFOSSです。サプライチェーン内のオープンソースコンポーネントをハッキングする方法は非常に多く、2020年の注目すべき記事では、脆弱性のカタログが「裏切り者のナイフコレクション」というニックネームで呼ばれていました。

この複雑な脅威の状況をよく知っている人物の 1 人が Dan Lorenc です。FOSS のバックグラウンドを持つ熟練したセキュリティ専門家である Lorenc は、Google で 10 年近く働き、Google Cloud のサイバーセキュリティ部門で少なくとも 3 年間働いていました。Lorenc は現在、サプライ チェーン セキュリティ ビジネス Chainguard を所有しており、Google 在籍中に発生したのと同じ問題の多くに対処しています。

「オープンソースは、主にその開発の分散化という性質のために、いくつかの特有の課題に直面していると思います。必ずしもコードを書くすべての人を信頼できるわけではありません」とロレンク氏は言う。「インターネット上の誰もがオープンソース コードに貢献できますが、インターネット上のすべての人が良い人であるとは限りません。」

はい、残念ながら、XZ の件は、FOSS のメンテナーや貢献者がプロジェクトに悪意のあるソフトウェアを持ち込んだ初めての事例ではありません。2020 年のレポートによると、FOSS のバグのほとんどは単なるコーディング エラーですが、約 17% (約 5 分の 1) は悪意を持って持ち込まれたバグ、つまり研究者が「バグドア」と呼んでいるものでした。この悪名高い例の 1 つは、2018 年に発生したものです。event -stream と呼ばれる人気のオープン ソース プログラムの開発者がプロ​​ジェクトのメンテナンスに疲れ、別の開発者 (「Right9ctrl」という匿名の Web ユーザー) に制御を譲ることに決めたときです。唯一の問題は、「Right9ctrl」がサイバー犯罪者であることが判明し、その後ソフトウェアに悪意のある更新を導入したことです。この更新により、犯罪者は特定のブランドの暗号通貨ウォレットをハッキングして資金を盗むことができました。約 800 万回ダウンロードされた悪意のあるコードは、約 2 か月間気付かれずにいました。

FOSS 開発者が自らのプロジェクトを妨害する傾向も増加傾向にあります。2021 年 10 月、人気のある npm ライブラリ セットのメンテナーである Marak Squires という人物が、一連の奇妙なアップデートで不可解にもライブラリを破壊しました 。アップデートにより、ソフトウェアは支離滅裂な意味不明な文字列を吐き出し、ソフトウェアを実行していたプロジェクトを事実上台無しにしました。このデジタル自己犠牲行為により、コーディング ライブラリに依存して成功していた「数千」のソフトウェア プロジェクトが破壊されたと推定されています。

また、Lorenc 氏は、世の中には「log4js」のような重要なプロジェクトが間違いなく多くあると述べています。これは、当然受けるべき注目やメンテナンスを受けていないプロジェクトです。実際、この種の状況は「常に」発生していると同氏は言います。

企業ユーザーの面前でこのようなプロジェクトが失敗に終わった場合、その責任はしばしばメンテナーに押し付けられる。人々は「彼らはプロとして仕事をしていない、あるいは十分な時間を費やしていない」とほのめかす、とロレンク氏は言う。「しかし、実際にはこれは複雑な問題です。彼ら（メンテナー）は何かを無料で公開し、人々はその上に巨大な重要な生産インフラを構築し始め、後でバグが見つかったときに文句を言うのです。」

在庫確認

では、どうすればいいのでしょうか? 本質的に、高度に分散化され、匿名性に悩まされ、包括的な権威による干渉に対して構造的に抵抗力のあるテクノロジー空間をどのように規制すればよいのでしょうか?

その疑問は、多くの人々を夜も眠れないほど悩ませてきました。log4j の失態以来、私は Linux のセキュリティ子会社である OpenSSF の幹部と何度か連絡を取り、「モビライゼーション プラン」の進捗状況について話し合ってきました。ご存知のとおり、このプランは、log4shell のバグが発見された後、FOSS 環境の新しい安全策を作成するためにまとめられました。最初に提案されたとき、このプランには多くの可動部分があり、どれが優先されるのかは明確ではありませんでした。2022 年に、私は OpenSSF のマネージング ディレクターである Brian Behlendorf と話をしました。彼は、モビライゼーション プランには、実行の準備が整った提案が少なくとも 2 つあり、それを「ショベル レディ」と呼んでいると私に話しました。最も有望な解決策の 1 つは、最も明白なものです。つまり、企業に使用するコードのインベントリを強制することです。

奇妙に聞こえるかもしれませんが、多くの企業はそうしていません。OSSF は、企業は「導入したソフトウェア資産のインベントリを持っておらず、取得したソフトウェア内のコンポーネントに関するデータも持っていないことが多い」と述べています。あまり魅力的ではありませんよね? 建設会社が超高層ビルを建てているのに、基礎が何でできているかをまったく知らないようなものです。あなたはそのような建物に住んだり働いたりしたいですか?

動員計画では、業界では「ソフトウェア部品表」または SBOM として知られるサードパーティのコード監査の広範な導入を求めています。このようなツールは、アルゴリズムによって収集された特定のソフトウェアのインベントリを提供します。SBOM は、ユーザーに自分のプログラム内に何が含まれているかを伝えることで、ソフトウェア プロバイダーが個々のコンポーネントがセキュリティ リスクの影響を受けていないかどうかを確認できるようにします。

「食品のパッケージ側面にある原材料リストと考えるのが一番です」と、SBOM サービスを提供する数社のうちの 1 社、セキュリティ会社 Synopsys で働く Tim Mackey 氏は言う。「ソフトウェア部品表は、そこに何が含まれていて、どこから来たのかを伝えるためのものです。」

SBOM は何年も前から存在していますが、主に法的リスクを排除するために使用されてきました。FOSS の使用はさまざまなライセンス契約の複雑さに基づいているため、企業はコードベースのコンテンツを特定し、訴訟を回避するために どの法的契約に従う必要があるかを判断するために SBOM を使用することがよくあります。しかし、現在では、まったく異なる種類のリスクを軽減するために採用されるようになっています。

2021年5月、バイデン政権は、連邦政府と協力するすべてのソフトウェア請負業者にSBOMの使用を義務付けるなどの大統領令を発令した。マッキー氏は、この命令が発令されて以来、同業界の関心が爆発的に高まっていると述べた。「ビジネスが信じられないほど成長しました」と同氏は語った。「素晴らしい成長です。」

しかし、SBOM が正しい方向への一歩だとしても、究極的には FOSS がもたらすより大きなセキュリティ問題に対する構造的な解決策にはなりません。実際、コードに存在するリスクを軽減する効果はまったくありません。「実際のところ、SBOM は正確な資産インベントリのようなものにすぎません」と、元 Google 開発者の Dan Lorenc 氏は述べ、大半の企業がまだこれを導入していないのは「おかしい」と指摘しました。「SBOM はバグを修正しませんし、バグを防止しませんし、攻撃者が何かを改ざんするのを阻止しません。適切なベースラインを提供するだけです。」

オープンソース コミュニティの長年の会員であるコリー ドクトロウ氏は、現在、企業が安全なソフトウェアを開発するインセンティブがないと語る。サプライ チェーン攻撃が発生すると、オープンソースのメンテナーが非難されるが、実際に悪いのはコードを使用している企業だ。「企業には自社のソフトウェアが優れていること、メンテナーがサポートされていると感じられるよう徹底する義務がないだけでなく、企業とその顧客に欠陥について警告するために列をなすボランティアは、企業がその企業のイメージを傷つけていると感じれば、黙らされる可能性がある」。実際、ドクトロウ氏は、自社製品のバグを暴こうとするセキュリティ研究者をテクノロジー企業が訴えることは珍しくないと語る。

企業がまったく対策を講じていないため、ソフトウェア セキュリティの大変な作業の多くは、個々のメンテナーや Linux Foundation などのオープン ソース組織に委ねられています。これらの組織は、FOSS がもたらすセキュリティ問題に対する新しいソリューションを考案するために懸命に取り組んできたことは評価に値します。OpenSSF は、SBOM の採用を奨励するだけでなく、過去数年間にわたって他のセキュリティ イニシアチブも数多く推進してきました。これらのプログラムには、GUAC (コード作成者がコード内の問題のあるコンポーネントを探すことができる無料のソフトウェア追跡メカニズム) や、開発者のソフトウェアの有効性を検証するための暗号署名であるSigstoreなどの無料のセキュリティ アプリケーションの開発が含まれます。

これらの取り組みが有望に思えるなら、サプライチェーン攻撃の増加、メンテナーの継続的な疲弊、そしてオープンソース環境のセキュリティ態勢は log4j の時代からあまり変わっていないという一般的な認識を背景に、これらの取り組みが行われていることに注意することが重要です。システム全体のオーバーホール以外にインターネットのセキュリティを確保する方法はないと主張する人もいます。暗号化プロトコル Matrix の共同創設者である Matthew Hodgson 氏は最近、FOSS は公的資金によるサービスであるべきであり、米国の実際の物理的インフラストラクチャと同様に、連邦政府から継続的に資金とサポートを受けるべきであると主張しました。

もちろん、このような劇的な変化が実際に起こる可能性はわずかで、オープンソース エコシステムを維持する人々にはシシュフォスの苦役が課せられることになる。昨年の夏以降、ブライアン ベーレンドルフは Linux Foundation 内の別の役職に異動し、セキュリティのバトンを元 Google Cloud エンジニアのオムカール アラサラトナムに託した。アラサラトナムは現在、OpenSSF のゼネラル マネージャーを務めている。アラサラトナムは自分の仕事を「インターネットのセキュリティ保護」と表現し、それが「信じられないほど難しい」仕事だと認めている。もっと適切な表現は「不可能」かもしれない。それでも、特効薬はないが、懸案事項を考えると希望を持たざるを得ないと認めている。「これを正しく実行できれば、80 億人の人々を助けることができます」と彼は言う。