XZ Utils バックドア騒動：ソフトウェア・セキュリティの問題点が浮き彫りに

XZ Utils Scare Exposes Hard Truths About Software Security

2024/04/11 DarkReading ‐‐‐ ほぼ全ての主要 Linux ディストリビューションに搭載されている、データ圧縮ユーティリティである XZ Utils に、バックドアが注入されていたことが、最近になって判明した。このインシデントから痛感させられるのは、OSS コンポーネントを利用する組織は、ソフトウェアの安全性を確保する責任を、最終的に負う必要があるということだ。

XZ Utils は、１人のメンテナが管理しており、他の何千もの OSS プロジェクトと同様に、ボランティアにより運営されている。このようなプロジェクトには、セキュリティ問題を処理するためのリソースが、ほとんど無いことが多い。したがって、それらに依存するユーザー組織は、自己責任でソフトウェアを使用することになる。つまり、セキュリティ・チームと開発チームには、社内で開発されたコードと同じレベルで、OSS のリスクを管理を実施する必要があると、セキュリティ専門家たちは指摘している。

Endor Labs の Founding Product Manager である Jamie Scott は、「すべてのサプライチェーン・リスクを、ユーザー組織が効果的に防止できる可能性は低い。しかし、サプライチェーン攻撃の成功率を下げる戦略をとることは絶対に可能である」と述べている。

彼は、「オープンソースと、アウトソーシングは、異なるものである。ボランティアのメンテナにより、OSS が管理されているということを、我々は認識する必要がある。つまり、OSS は我々の保有物であり、その責任は我々にあるということだ」と付け加えている。

善意に依存しているがリソース不足を認識していない

OSS のセキュリティに対する懸念は、決して目新しいものではない。しかし、Log4Shell の脆弱性や XZ Utils バックドア (CVE-2024-3094) などの問題が明らかにしたのは、コード内のコンポーネントに対して、ユーザー組織が極めて脆弱であるという事実である。そして、多くの場合において、そのコードは善意で作られたものであるが、リソースが絶望的に不足している OSS プロジェクトから提供されており、最低限のメンテナンスだけが行われているという状況にある。

XZ Utils の場合は、基本的にメンテナが１人で運営しているプロジェクトである。そして、プロジェクトのメンテナから、別の個人が徐々に信頼を得たことで、３年近くにわたって、このユーティリティにバックドアを忍び込ませることに成功した。

このバックドアは、2024年3月下旬に Microsoft の開発者 Debian が、インストールに関連する奇妙な動作を調査したことで発見された。もし、この時に発見されていなければ、このバックドアは、世界中の何百万台ものデバイスに入り込み、大企業や政府機関に対しても影響を及ぼしていたかもしれない。このバックドアが入り込んだのが、Debian／Fedora／Kali／open SUSE／Arch Linux などの、unstable 版／beta 版にのみ存在する XZ Utils のバージョンだったことで、影響は最小限に食い止められた。

このような OSS コードは、今後においても、きわめて高い確率で危険にさらされるだろう。Tidelift の共同設立者／CEO である Donald Fischer は、「組織にとって最も恐ろしいのは、彼らが利用しているアプリケーションが、XZ Utils のような OSS プロジェクトに依存して構築されていることだ。XZ Utils も、典型的な企業組織が毎日使用している、何万ものパッケージのうちの１つである」と述べている。

これらの組織の大半は、ソフトウェア・サプライチェーンにおける、OSS のパートでのセキュリティとレジリエンスについて、リスクを評価するたけの十分な可視性を持っていないと、彼は指摘する。

最近の Harvard Business School における調査では、OSS に対する需要サイドの価値は、$8.8T という驚くべき金額に達すると推定されている。そして、このエコシステムの中核を担っているメンテナーたちの多くは個人で活動していると、Fischer は指摘する。

Tidelift が 2023年に実施した調査によると、OSS プロジェクトの 44％ において、メンテナは１人だとされる。また 60％ の回答者は、あくまで趣味の一環であるため無報酬であり、プロジェクトのメンテナを辞めようと考えたことがあると答えている。Fischer によると、自分たちの努力はストレスが多く、孤独であり、金銭的にも報われないと、数多くのメンテナーたちが述べているという。

Fischer は、「XZ Utils のハッキングは、組織が依存する OSS サプライチェーンの健全性と回復力に対する、投資不足のリスクを浮き彫りにした。最も信頼されている OSS パッケージの大半は、自らを無報酬の趣味人と称するボランティアによりメンテナンスされていることを、企業組織は知っておく必要がある。これらのメンテナーは、企業のサプライヤーではないが、企業のように働き、提供することを、期待されている」とコメントしている。

推移的な依存関係の危険性

2022年の Endor による調査では、OSS の脆弱性の 95％は、依存関係の推移的な性質にあるという。つまり、プライマリの OSSパッケージが依存する可能性のある、セカンダリの OSS パッケージやライブラリに、脆弱性が存在することが分かっている。多くの場合において、これらのセカンダリ・パッケージは、開発者が自分で選択したものではなく、開発プロジェクトで用いられる OSS パッケージにより、自動的に採用されたものである。

Endor の Jamie Scott は、「たとえば、１つの Maven パッケージを信頼したとすると、さらに 14 個の依存パッケージを、暗黙のうちに信頼したことになる。この平均値は、NPM のようなソフトウェア・エコシステムでは拡大し、１つの信頼するソフトウェア・コンポーネントに対して、77個のソフトウェア・コンポーネントをインポートすることになる」と指摘する。

OSS のリスクを軽減する１つの方法は、このような依存関係に注意を払い、選択するプロジェクトを厳選することだと、彼は述べている。

Endor の CTO／共同設立者である Dimitri Stiliadis は、「特に、１人〜２人のチームが運営する、小規模で１回限りのパッケージの依存関係について、ユーザー組織は注意する必要がある。さらに、組織にとって見極める必要があるのは、環境内の依存関係について、適切なセキュリティ管理がなされているのか、あるいは、一個人が全てのコードをコミットしているのかという点だ。加えて、誰も知らないバイナリ・ファイルがリポジトリにあるのか、あるいは、誰かがプロジェクトを積極的に保守しているのかなども知る必要がある」と指摘している。

Scott は、「ソフトウェア・インベントリの維持などの、基本的かつ成熟した管理が、ソフトウェア・リスクが発見された時点で、問題を迅速に特定し、スコープを設定し、対応するための、最も価値の高いプログラムの１つであることに変わりはない」と提言している。

ソフトウェア構成分析ツール／脆弱性スキャナや、EDR／XDRシステム、SBOM なども、脆弱で危険な OSS コンポーネントを、ユーザー組織が迅速に特定する際に役立つ。

脅威を認識する

Tidelift の Fischer は、「平均的なソフトウェア製品において、その構成要素の約 70％ が、ほとんど無報酬のボランティアにより開発された、OSS に依存してきたという歴史がある。このリスクを軽減するためには、まず、この事実を C-suite や取締役会レベルで共有することが必要だ」と指摘する。

金融サービス業界／FDA／NIST における、新たな規制やガイドラインが、これからの数年間における、ソフトウェアの開発方法を形作るだろう。彼は、「ここでの勝者は、オープンソース関連のリスクを管理するために、リアクティブな戦略からプロアクティブな戦略へと迅速に適応していくだろう」とコメントしている。

さらに彼は、「組織のセキュリティ・チームとエンジニアリング・チームに対して、新しい OSS コンポーネントが、どのような形で自社の環境に入ってくるのかを、特定するよう勧めている。また、これらのコンポーネントを監視する役割を定義し、組織のリスク選好度に合わないコンポーネントを、積極的に削除することも必要だ」と述べている。

XZ Utils バックドア・インシデントを契機として、あらためて OSS の全体像を認識しようと呼びかける、とても良い記事だと思います。この全体像には、開発者側と利用者側の２つの側面があり、また、すべてのソフトウェアにおける、OSS への依存度という視点もあります。Log4j の脆弱性から、約３年が経ちましたが、なにが改善できているのでしょうか？