ほぼすべての主要な Linux ディストリビューションに存在する XZ Utils データ圧縮ユーティリティのバックドアが最近発見されたことは、オープンソース コンポーネントを使用する組織がソフトウェアのセキュリティを確保する最終的な責任を負っていることをはっきりと思い出させます。
XZ Utils は、他の何千ものオープンソース プロジェクトと同様、ボランティアによって運営されており、その場合は 1 人のメンテナーが管理しています。このようなプロジェクトには、セキュリティ問題に対処するためのリソースがほとんど、あるいはまったくないことが多く、組織は自らのリスクでソフトウェアを使用することになります。つまり、セキュリティチームと開発チームは、社内で開発したコードの場合と同じ方法でオープンソースのリスクを管理する対策を実装する必要がある、とセキュリティ専門家は言う。
「組織がサプライ チェーンのリスクにさらされることを効果的に防止できる可能性は低いですが、サプライ チェーン攻撃が成功する可能性を減らす戦略に集中することは間違いなく可能です」と、Endor Labs の創設プロダクト マネージャー、ジェイミー スコット氏は述べています。
オープンソースはアウトソーシングと同じではありません。「オープンソースのソフトウェア保守者はボランティアです。業界レベルでは、それらをそのように扱う必要があります。私たちはソフトウェアを所有しています。私たちは再利用するソフトウェアに対して責任を負います。」
善意はあるがリソースが不足している
オープンソース ソフトウェアのセキュリティに関する懸念 決して新しいものではありません。しかし、多くの場合、次のような発見が必要です。 Log4Shellの脆弱性 と XZ Utils のバックドア 組織がコード内のコンポーネントに対していかに脆弱であるかをはっきりと理解できます。そして多くの場合、そのコードは、善意はあるもののリソースが絶望的に不足しており、最小限のメンテナンスしか行われていないオープンソース プロジェクトから来ています。
たとえば、XZ Utils は基本的に 1 人のプロジェクトです。別の個人が成功しました ユーティリティにバックドアを忍び込ませる プロジェクトの管理者から徐々に十分な信頼を得ることによって、ほぼ 3 年をかけて開発を進めました。 Microsoft の開発者が Debian インストールに関連する奇妙な動作を調査していた 3 月下旬に偶然発見していなかったら、このバックドアは大企業や政府機関のものも含め、世界中の数百万台のデバイスに感染していた可能性があります。結局のところ、バックドアは、Debian、Fedora、Kali、オープン SUSE、および Arch Linux の不安定版およびベータ版にのみ存在する XZ Utils のバージョンに影響を及ぼしたため、影響は最小限でした。
次にこのようなオープンソース コードの侵害が発生すると、さらに悪化する可能性があります。 「企業組織にとって最も恐ろしいのは、自社のアプリケーションが XZ Utils のようなオープンソース ソフトウェア プロジェクトの上に構築されていることです」と、Tidelift の共同創設者兼 CEO の Donald Fischer 氏は言います。 「XZ Utils は、一般的な企業組織で毎日使用されている数万のパッケージの 1 つです」と彼は言います。
これらの組織のほとんどは、ソフトウェア サプライ チェーンのこの部分のセキュリティと回復力を十分に把握してリスクを評価することができていない、と同氏は指摘します。
最近の ハーバード大学大学院経営学研究科 調査によると、オープンソース ソフトウェアの需要側の価値は驚くべき 8.8 兆 44 億ドルと推定されています。フィッシャー氏によると、整備士はこのエコシステムの中核であり、その多くは単独で飛行しているという。 Tidelift が昨年実施した調査によると、オープンソース プロジェクトのメンテナーの XNUMX% が、自分自身をプロジェクトの唯一のメンテナーであると述べています。 XNUMX% が自分自身を無給の趣味人だと認識しており、同じ割合がプロジェクト管理者としての役割を辞めたか、辞めることを検討していると回答しました。フィッシャー氏によると、多くのメンテナは自分たちの取り組みをストレスが多く、孤独で、経済的にもやりがいのない仕事だと評していたという。
「XZ utilsのハッキングは、企業組織が依存するオープンソース ソフトウェア サプライ チェーンの健全性と回復力への投資が過少であることのリスクを浮き彫りにしました」とフィッシャー氏は言う。 「企業組織は、最も信頼されているオープンソース パッケージの大部分が、無報酬の愛好家であると自称するボランティアによって維持されているということを認識する必要があります。これらのメンテナーは企業のサプライヤーではありませんが、彼らと同じように働き、提供することが期待されています。」
危険: 推移的な依存関係
A エンドアが実施した研究 2022 年には、オープンソースの脆弱性の 95% が、いわゆる推移的な依存関係、つまり、主要なオープンソース パッケージが依存する可能性のある二次的なオープン ソース パッケージやライブラリに存在することが判明しました。多くの場合、これらは開発者が自分で直接選択するのではなく、開発プロジェクトのオープン ソース パッケージによって自動的に採用されるパッケージです。
「たとえば、14 つの Maven パッケージを信頼すると、結果として暗黙的に信頼する依存関係が平均して 77 個追加されます」と Scott 氏は言います。 「NPM などの特定のソフトウェア エコシステムでは、この数字はさらに大きくなります。NPM では、信頼できるソフトウェア コンポーネントごとに平均 XNUMX 個の他のソフトウェア コンポーネントをインポートします。」
オープンソースのリスクを軽減し始めるための 1 つの方法は、これらの依存関係に注意を払い、どのプロジェクトを選択するかを慎重になることだと彼は言います。
組織は依存関係を精査する必要があり、特に 1 人または 2 人のチームが担当する小規模な 1 回限りのパッケージについては、次のように付け加えています。 Endor の CTO 兼共同創設者である Dimitri Stiliadis 氏。彼らは、環境内の依存関係に適切なセキュリティ制御があるかどうか、または 1 人の個人がすべてのコードをコミットしているかどうかを判断する必要があります。リポジトリに誰も知らないバイナリ ファイルがあるかどうか。あるいは、誰かが積極的にプロジェクトを保守しているとしてもだ、とスティリアディス氏は言う。
「対応効率の向上に注力してください。成熟したソフトウェア インベントリの維持などの基本的な管理は、ソフトウェア リスクを迅速に特定し、特定した後に対応するために導入できる最も価値のあるプログラムの 1 つです。」と Scott 氏は言います。アドバイスします。
ソフトウェア構成分析ツール、脆弱性スキャナー、EDR/XDR システム、SBOM もすべて、組織が脆弱で侵害されたオープンソース コンポーネントを迅速に特定するのに役立ちます。
脅威を認識する
「エクスポージャーの軽減は、平均的なソフトウェア製品の構成要素の約 70% が、歴史的にほとんど無報酬の貢献者によって作成されたオープンソース ソフトウェアであるということを経営幹部、さらには取締役会レベルで共通の理解と認識から始まります」と Tidelift の Fischer 氏は言います。
金融サービス業界、FDA、NIST の新しい規制とガイドラインは、今後数年間のソフトウェア開発方法を形作ることになるため、組織は今すぐそれらに備える必要があります。 「ここでの勝者は、オープンソース関連のリスクを管理するために、事後対応的な戦略から積極的な戦略にすぐに適応するでしょう」と彼は言います。
フィッシャー氏は、組織がセキュリティ チームとエンジニアリング チームに、新しいオープンソース コンポーネントがどのように環境に導入されるかを特定してもらうよう推奨しています。また、これらのコンポーネントを監視する役割を定義し、企業のリスク選好に合わないコンポーネントを積極的に削除する必要があります。 「ここ数年、最終段階の問題に対応することは、ビジネスに対するリスクの規模に対処する非効果的な方法になっています。 米国政府が信号を送っている その時代は終わりに近づいています」と彼は言います。
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
- プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
- プラトンESG。 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
- プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
- 情報源： https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security
