|
オープンソースコンポーネントは、ソフトウェア開発においてますます重要になっています。継続的インテグレーション／デプロイメント、DevOps、定期的なソフトウェアアップデートなど、オープンソースは多くの開発者に大きな助けをもたらしてきました。 チップ設計自動化ベンダーのSynopsysは昨年発表したレポートで、2021年にはコードベースの97%にオープンソースコンポーネントが含まれていたことを発見した。調査対象となった17の業界のうち、4つの業界（コンピューターハードウェアとチップ、サイバーセキュリティ、エネルギーとクリーンテクノロジー、モノのインターネット）では、監査されたオープンソースコードベースが100%であったが、その他の垂直業界では「オープンソースコンテンツ」の最低値は93%であった。 明らかに、オープンソースの成功は、効率性の向上、コストの節約、開発者の生産性の向上において実証されています。 「オープンソースはどこにでもある」とシノプシスのシニアテクニカルライター、フレッド・バルス氏はブログ記事に書いた。 しかし同時に、アプリケーション開発におけるオープンソース ソフトウェア パッケージの人気の高まりにより、ソフトウェア サプライ チェーンを利用してバックドアを拡散しようとする悪意のあるハッカー グループにとって、前例のない機会が生まれています。 開発分野におけるオープンソースソフトウェアパッケージの普及は、企業がその内容を明確に理解していないケースが多いことを意味します。多くの仲介業者を経由するため、レビューの複雑さは飛躍的に増大し、ソフトウェアサプライチェーンの真の姿はますます不透明になっています。VMwareが昨年発表したレポートによると、脆弱性の修正とそれに伴うセキュリティリスクをコミュニティが担っていることを考えると、オープンソースソフトウェアのセキュリティに対する人々の警戒心は非常に高まっています。 アプリケーション開発におけるオープンソースソフトウェアのセキュリティ確保を専門とするEndor Labsの共同創業者兼CEO、ヴァルン・バドワール氏は、オープンソースソフトウェアを「重要なインフラのバックボーン」と呼んでいます。しかし、バドワール氏は、多くの開発者や企業幹部が、自社のアプリケーションがオープンソースソフトウェアに徹底的に侵入されていることに気づいていないと付け加えています。 Badhwar 氏は、すべてのセキュリティ脆弱性を見ると、その最大 95% が「依存関係」、つまり開発者が積極的に選択したものではなく、オープンソース ソフトウェア パッケージによって間接的に導入されたものから生じていると指摘しています。 「これは大きな隠れた危険ですが、人々はそれを見落としがちです。」 脅威の本質が徐々に明らかにオープンソースソフトウェアパッケージへの依存は、今に始まったことではありません。ソフトウェアサプライチェーン管理プロバイダーであるSonatypeの共同創業者兼CTOであるブライアン・フォックス氏によると、この慣行は開発者の間で少なくとも10年前から存在していたそうです。 フォックス氏はインタビューで、開発者はソースコードのコンポーネントを組み立て、そこにビジネスロジックを追加することが多いと述べています。このように、オープンソースはソフトウェアの成果の基盤となります。 近年の最も顕著な傾向は、開発者がオープンソースコンポーネントを大規模に利用するようになったことに加え、IT 運用に関する人々の一般的な理解も高まったことです。 攻撃者もその展開の詳細を把握しています。ここ5年ほどで、業界全体に影響を及ぼす大きな変化がありました。それは、サプライチェーンを狙ったマルウェア攻撃の増加です。 真の転機は、2020年のSolarWindsへの攻撃でした。ロシアと関連のある悪意のあるハッカーが同社のソフトウェアシステムに侵入し、悪意のあるコードを埋め込んだのです。アップデート中に、ユーザーは知らず知らずのうちに悪意のあるコードをダウンロードし、被害に遭いました。その後も、Kaseya、そして注目を集めたLog4jを標的とした同様の攻撃が続きました。 Log4j事件から始まるフォックス氏は、このJavaベースのログツールは、多数のオープンソースコンポーネントを統合することに伴うリスクを直接的に示していると考えています。さらに、この種の慣行はソフトウェア開発において非常に一般的です。 Log4jはソフトウェア内のシンプルなコンポーネントです。その応用範囲は極めて広く、ほぼすべてのJavaアプリケーションに存在しているとみなされ、そのカバー率は約99.99%です。そのため、攻撃者がこのような影響の大きい標的に焦点を絞るのは当然のことです。攻撃者がLog4jを悪用する方法を見つければ、インターネット上で大混乱を引き起こす可能性があります。これは、1990年代の状況とは全く異なります。当時は、各Webアプリケーションが独自のカスタムコードを使用していたため、攻撃者は侵入方法を見つけるために様々なWebアプリケーションを一つ一つ調査する必要がありました。 つまり、企業は「開発業務の90%を、面識も信頼もない人々にアウトソーシングしているのです。恐ろしい話に聞こえるかもしれませんが、これが過去10年間の現実です。私たちは、それが本当に何を意味するのかを理解し始めたばかりです。」 Log4jは、ソフトウェアサプライチェーンにおけるもう一つの問題、つまりソフトウェアのオープンソースコードへの依存度をどのように判断するかという問題を浮き彫りにしています。さらに、パッチがリリースされているにもかかわらず、Log4jのダウンロードの29%が依然としてパッチ未適用バージョンであると推定されています。 Sonatypeの分析によると、企業顧客は主に脆弱なコンポーネントバージョンを使用しています。パッチ適用版は存在するものの、企業がその全てを採用することは稀です。Fox氏は、この問題を解決するにはセキュリティ意識向上教育が必要だと述べています。「問題の96%は、人々が『汚れたもの』を使い続けていることに起因しています。多くの場合、クリーンなバージョンを選択する意識が欠如しているのです。」 コードリポジトリに非難の矛先が向けられているオープンソースソフトウェアの普及がもたらすもう一つの大きな脅威は、ハッカーがGitHub、Python Package Index（PYPI）、NPMなどのコードリポジトリにマルウェアを注入し始めていることです。悪意のあるハッカーは、依存関係の混乱という霧を悪用し、様々な人気ソフトウェアの悪意あるバージョンを開発し、開発者にそれを自身のソフトウェアに組み込むよう仕向けています。 たとえば、正しいソフトウェアでダッシュがアンダースコアに置き換えられると、不注意な開発者が間違ったコンポーネントを選択してしまう可能性があります。 フォックス氏は、「ここでの課題は、開発者が間違ったバージョンのコンポーネントをダウンロードし始めた時点で、攻撃が既に始まっているということです。これは、ダウンロードがブラウザを通じて能動的に行われていた過去とは異なります。現在では、ダウンロードプロセスはツール内に隠され、背後で行われるため、マルウェアの拡散につながる可能性があります」と考えています。 こうしたタイプの攻撃はそれほど洗練されていません。悪意のあるコンポーネントの中には、正規のコンポーネントに偽装することすらしないものもあります。コンパイルもテストも行わず、ただペイロードをリリースするだけです。これほど単純かつ粗雑な手口なのに、いまだに多くの被害者が騙されています。 防衛側が集まっています。オープンソースソフトウェアにはセキュリティリスクが内在するものの、その利点は否定できない。フォックス氏は、オープンソースソフトウェアは商用ソフトウェアよりも透明性と透明性が高いと強調する。彼はLog4jのインシデントを例に挙げ、貢献チームが数日以内に修正プログラムをリリースしたことを指摘する。これは商用組織ではほとんど達成できないことだ。 サイバーセキュリティ プロバイダーの Vulcan Cyber のシニア テクニカル エンジニアである Mike Parkin 氏もこれに同意し、オープン ソース モデルのオープン性は諸刃の剣であると考えています。つまり、サイバー脅威を軽減するのに役立ちますが、潜在的な攻撃の閾値を下げる可能性もあるということです。 パーキン氏はインタビューの中で、「歴史的な観点から見ると、開発者はまだ相対的に有利であるはずだ」と指摘した。 SolarWindsの事件は、ソフトウェアサプライチェーンのセキュリティ問題にも深刻な注目を集めました。バイデン大統領による2021年のサイバーセキュリティに関する大統領令に基づき、ホワイトハウスは2022年9月、連邦政府機関に対し、サードパーティ製ソフトウェアの使用時にNISTガイドラインに従うことを正式に義務付けました。これには、ソフトウェア開発者によるセキュリティの証明とソフトウェアマテリアルリスト（SBOM）の提出が含まれます。 ソフトウェア開発者は、ソフトウェアサプライチェーン全体のセキュリティ強化に向けて、幅広い取り組みを進めています。具体的な対策としては、ソフトウェアサプライチェーンの攻撃事例を公開すること、Vulnerability Availability Exchanges（VEX）などのツールを公開すること、そして様々なサイバーセキュリティベンダーが開発した関連製品を活用することなどが挙げられます。 しかし、それだけでは十分ではありません。Sonatypeのフォックス氏は、ソフトウェア開発者に欠陥のあるソフトウェアコンポーネントのリコールを義務付けるなど、更なる対策を求めています。その前提条件は、ソフトウェア部品表（BOM）の普及です。フォックス氏はこれを自動車業界に例えています。メーカーは、責任を明確に定義するために、購入者に部品リストを提供するだけで済みます。欠陥が単一の部品にあることが確認された場合、車両全体をリコールする必要はありません。 ソフトウェアにも同様のリコールメカニズムを導入する必要があります。これにより、開発者はどのコンポーネントが使用されているか、それらのコンポーネントがどこから来たか、そしてアプリケーションが正常な動作のためにどのオープンソースソフトウェアのバージョンに依存しているかを把握できます。この方法によってのみ、セキュリティの脆弱性を発見し、管理することができます。これはセキュリティ開発の正しい方向性です。 フォックス氏はまた、すべての関係者がオープンソースソフトウェアパッケージの維持管理に注力することを期待している。各国政府は既にこの点に関して一定の措置を講じており、EUのサイバーレジリエンス法もソフトウェアリコールを規定しているが、文言は明確ではない。この点において、米国は世界の最前線に立つ可能性が高い。 彼はまた、コンポーネント レベルのファイアウォールというアイデアについても言及しました。これは、ネットワーク トラフィックを検査して悪意のあるデータ パケットを事前にブロックするファイアウォールと本質的には似ていますが、コンポーネント レベルで悪意のあるコードがソフトウェアに損害を与えるのを防ぐという点が異なります。 ソフトウェアの内部構造を理解しなければ、マルウェアが含まれているかどうかを見抜くことは不可能です。これは脆弱性を意味するだけでなく、受動的な『切り身の魚』のような状況でもあります。一度触れられれば、悪意のあるハッカーは即座に被害を引き起こす可能性があります。そして残念なことに、ほとんどの人はこの問題を真剣に考えていません。 Sonatypeのソリューションは、プラットフォームにNexusファイアウォールを組み込み、クレジットカード詐欺対策から派生した技術を活用して悪意のあるコードをブロックします。このファイアウォールは正常な動作状態を把握し、AIと機械学習を用いて異常なアクティビティを検出します。2022年には、このファイアウォールは10万8,000件を超える悪意のある攻撃試行を検知しました。 「多くの組織はこの問題に気づいていません。しかし、それが現実です。悪意のあるハッカーは依然としてこの問題を逃れ、何の罰も受けずに活動しています。」 さらに、ファイアウォール機能もソフトウェア部品表に統合する必要があります。 そうです。ソフトウェアの各コンポーネントがどこに配置されているかを把握する必要があります。そうすれば、次にLog4jのインシデントが発生したときに、何千ものアプリケーションを一時的に分割することなく、すぐに修正を行うことができます。しかし、ソフトウェアの構造を理解することは最初のステップに過ぎません。悪意のある攻撃を境界から完全に排除するための保護システムを確立する必要があります。 |
