今回の問題で注目されているのが、ディストリビューションがOpenSSHに適用しているsystemd連携パッチだ。これはsshdの起動をsystemdに通知するためのもので、必然的にlibsystemdへの依存が生じる。libsystemdはライブラリの性質上、liblzmaにリンクしていることが多い。

つまり、OpenSSH自体はliblzmaに依存していなくても、systemdとの連携パッチを適用したがゆえにプロセス空間内に脆弱なliblzmaが読み込まれてしまう。これが攻撃の成功率を高めた一因と見られている。OpenSSHではパッチに頼らずsystemd連携機能を実装することが検討されている。

systemd連携パッチの適用はメジャーディストリビューションで広く行われており、脆弱性の影響はかなり広範囲に及ぶ。一方、組み込み機器などでは独自のinitシステムを使うことも多く、そういったケースでの影響は限定的と予想される。

セキュリティ体制の課題も浮き彫りに、根本的な対策が急務

xz-utilsのメンテナーLasse Collinは今回の事態を受けてJia Tanの権限を剥奪し、GitHubのリポジトリやウェブサイトの管理を取り戻した。だが、コードがコミュニティの目に晒されているオープンソースプロジェクトでこのような不正が長期間見過ごされていたことは大きな衝撃となっている。

オープンソースソフトウェアの安全性を高めるには、開発プロセスの透明性向上とレビューの強化が欠かせない。特に配布物の完全性検証は重要で、ソースコードと配布物の内容に差異がないことを確認する仕組みの整備が急がれる。またコミッターの監査体制も見直しが必要だろう。

ユーザー側でもバックドアの検知を難しくしている要因がある。それがビルドフラグだ。xz-utilsのようなライブラリは、ディストリビューションごとに細かくビルドオプションをカスタマイズすることが多いため、再現ビルドによる検証が難しくなっている面がある。

trends編集部「K」の一言

xz-utilsのバックドア問題は「サプライチェーン攻撃」の新たな形と言えるだろう。これまでにも、ソフトウェアの開発や配布の過程で悪意のあるコードが混入される事例は数多く報告されてきた。オープンソースプロジェクトはその透明性ゆえに安全と見なされがちだが、人的な脆弱性は避けられない。

国家的なサイバー攻撃の脅威が高まる中、ソフトウェアのサプライチェーンを狙った攻撃はますます巧妙化している。セキュリティ意識の高い企業や組織でも、気づかないうちに不正なコードを取り込んでしまうリスクは十分にある。公開されたソースコードをそのまま信用するのではなく、常に監査の目を光らせておく必要がある。

オープンソースコミュニティでは、開発者に対する厳格な身元確認と権限管理、配布物の完全性検証、脆弱性対応プロセスの確立など、ガバナンス面での取り組み強化が求められている。個々のプロジェクトの努力だけでは限界があるため、LinuxファウンデーションやApache Foundationのような団体がリードし、ベストプラクティスを確立していくことが期待されることを期待したい。

一方でユーザー企業には、サプライチェーンリスクへの意識改革と体制整備が欠かせない。自社で開発していないソフトウェアの安全性を過信せず、予め想定したリスクシナリオに基づいて対策を講じておくことが肝要だ。OSSコンポーネントの管理は特に重要で、脆弱性データベースと連携した自動追跡・アラート機構などの導入が有効だろう。

xz-utilsの一件は、ソフトウェアのサプライチェーンセキュリティが喫緊の課題であることを改めて突きつけた。業界を挙げた知見の共有と対策の強化が急務と言えるだろう。これを機に、オープンソースプロジェクトとユーザー企業がそれぞれの立場から安全性向上に努め、サイバー空間の信頼を高めていくことを期待したい。