2023年のオープンソースのセキュリティと運用上のリスクトップ10

2023年のオープンソースのセキュリティと運用上のリスクトップ10
オープンソースのセキュリティを表すボックス内のコード。
画像: klss777/Adobe Stock

オープンソースソフトウェアのセキュリティとメンテナンスを促進するソフトウェア企業 Endor Labs は、2023 年のオープンソースソフトウェアにおけるセキュリティと運用上のリスクのトップ 10 を特定するレポートを発表しました。

Endor Labs の Station 9 チームによって作成されたこのレポートには、Adobe、HashiCorp、Discord、Palo Alto Networks など著名な企業の 20 名を超える業界最高情報セキュリティ責任者による寄稿が掲載されています。

Endor Labs によると、オープンソース ソフトウェアへの過度の依存により、Common Vulnerabilities and Exposures として記録されたいくつかの既知の脆弱性が記録されています。これらの脆弱性は見落とされることが多く、修正されなければ攻撃者に悪用される可能性があります。

「オープンソースソフトウェアはアプリケーション開発者にとって金鉱ですが、同様に効果的なセキュリティ機能が必要です」と、Endor Labsの主任セキュリティ研究者であるヘンリック・プレート氏は述べています。「新しいアプリケーションのコードの80%以上が既存のリポジトリから提供される環境では、深刻なリスクが伴うことは明らかです。」

2023年のオープンソースの主なリスク

以下に、2023 年のオープンソースのリスクトップ 10 に関する Endor Labs のレポートの主要なポイントを示します。

1. 既知の脆弱性

報告書では、オープンソースコンポーネントのバージョンに、開発者が誤って導入した脆弱なコードが含まれている可能性があることが明らかになりました。この脆弱性は下流のソフトウェア内で悪用され、システムとそのデータの機密性、整合性、または可用性が損なわれる可能性があります。

2. 合法的なパッケージの侵害

Endorのレポートによると、攻撃者は既存のプロジェクトやディストリビューションインフラの正当なリソースを標的にし、コンポーネントに悪意のあるコードを挿入する可能性があります。例えば、正当なプロジェクトメンテナーのアカウントを乗っ取ったり、パッケージリポジトリの脆弱性を悪用したりすることができます。この種の攻撃は、悪意のあるコードが正当なパッケージの一部として配布され、検出が困難になる可能性があるため、危険です。

3. 名前の混同攻撃

攻撃者は、正規のオープンソースコンポーネントやシステムコンポーネントに似た名前のコンポーネントを作成できます。Endor Labsのレポートによると、これは以下の方法で実行可能です。

  • タイポスクワッティング:攻撃者は、元のコンポーネントの名前のスペルを間違えた名前を作成します。
  • ブランドジャッキング:攻撃者は信頼できる著者を提案します。
  • コンボスクワッティング:攻撃者は、さまざまな言語やエコシステムで共通する命名パターンを悪用します。

これらの攻撃は、ユーザーを騙して、正当であると信じ込ませ、悪意のあるコンポーネントをダウンロードさせて使用させるために使用される可能性があります。

4. メンテナンスされていないソフトウェア

Endor Labsのレポートによると、メンテナンスされていないソフトウェアは運用上の問題となります。コンポーネントまたはコンポーネントのバージョンが積極的に開発されなくなった場合、元のオープンソースプロジェクトから機能上および非機能上のバグに対するパッチが迅速に提供されない、あるいは全く提供されない可能性があります。その結果、ソフトウェアは既知の脆弱性を狙う攻撃者による悪用に対して脆弱な状態になる可能性があります。

5. 古いソフトウェア

利便性のため、更新されたバージョンが存在するにもかかわらず、一部の開発者は古いバージョンのコードベースを使用しています。その結果、プロジェクトは重要なバグ修正やセキュリティパッチを見逃し、悪用される危険性が高まります。

6. 追跡されていない依存関係

プロジェクト開発者は、いくつかの理由により、コンポーネントへの依存関係に気付かない場合があります。

  • これは、上流コンポーネントのソフトウェア部品表の一部ではありません。
  • ソフトウェア構成分析ツールが実行されないか、検出されません。
  • 依存関係はパッケージ マネージャーを使用して確立されないため、追跡されていない依存関係の脆弱性が気付かれない可能性があり、セキュリティ上の問題が発生する可能性があります。

7. ライセンスおよび規制リスク

コンポーネントまたはプロジェクトにはライセンスがなかったり、意図された用途と互換性がなかったり、要件が満たされていないか満たされないライセンスが存在している場合があります。

さらに、法的要件や規制要件に違反すると、特定の業界や市場に対応する能力が制限されたり阻害されたりする可能性があります。

8. 未熟なソフトウェア

オープンソースプロジェクトは、標準的なバージョン管理スキームの使用、回帰テストスイートの導入、レビューガイドラインやドキュメントの整備といった開発のベストプラクティスに従っていない場合があります。その結果、オープンソースコンポーネントが信頼性や安全性に欠け、悪用される危険性が高まります。

未熟なコンポーネントやプロジェクトに依存すると、重大な運用リスクが生じる可能性があります。例えば、それに依存するソフトウェアが意図したとおりに動作せず、実行時の信頼性に問題が生じる可能性があります。

9. 承認されていない変更(変更可能)

異なるタイミングでダウンロードされた際に同一であることが保証されないコンポーネントを使用する場合、重大なセキュリティリスクが生じます。これは、Codecov Bash Uploaderなどの攻撃によって実証されています。これらの攻撃では、ダウンロードされたスクリプトが事前に整合性を検証することなくbashに直接パイプされます。可変コンポーネントの使用は、ソフトウェアビルドの安定性と再現性にも脅威をもたらします。

10. 依存関係の不足/過剰

Endorのレポートは、コンポーネントへの依存度が高すぎる/低すぎることが運用上のリスクになり得ると指摘しています。例えば、数行のコードしか含まれていないような小さなコンポーネントは、より大きなコンポーネントと同じリスクにさらされる可能性があります。これらのリスクには、アカウント乗っ取り、悪意のあるプルリクエスト、継続的インテグレーションおよび継続的開発パイプラインの脆弱性などが含まれます。

一方、巨大なコンポーネントには、標準的なユースケースには必要のない機能が多数蓄積されている可能性があります。これらの機能はコンポーネントの攻撃対象領域を拡大し、未使用の依存関係を導入してコンポーネントの肥大化を招く可能性があります。

オープンソースのリスクを軽減するための手順

ここでは、ソフトウェア開発者と IT 管理者がこれらのオープンソースのリスクを軽減する方法に関する Endor Labs からのヒントを紹介します。

定期的にコードをスキャンして、侵害されたパッケージを見つける

侵害されたパッケージの防止は、万能の解決策がないため、複雑な問題です。組織は、OpenSSFセキュアサプライチェーン消費フレームワーク(S2C2F)などの新しい標準やフレームワークを参照することができます。

特定のセキュリティ ニーズとリスク許容度に基づいて、要件に最適な安全対策を選択し、優先順位を付けることができます。

プロジェクトが開発のベストプラクティスに従っているかどうかを確認する

プロジェクトの品質と最新性を評価するには、ドキュメントとリリースノートの完全性と適時性を確認してください。テストカバレッジや、リグレッションを検出できるCI/CDパイプラインの存在を示すバッジを探してください。

さらに、アクティブなメンテナーとコントリビューターの数、新しいリリースの頻度、オープンおよびクローズされたイシューとプルリクエストの数を確認することで、プロジェクトを評価できます。また、プロジェクトのメンテナンスやサポート戦略に関する情報(長期サポートバージョンの有無や日付など)を確認することも重要です。

依存関係を最新の状態に保ち、使用する前にコードの特性を確認してください。

コードのセキュリティを確保するには、コードとプロジェクトの特性の両方を確認することが重要です。確認すべきコード特性の例としては、インストール前後のフックやエンコードされたペイロードなどが挙げられます。プロジェクト特性としては、ソースコードリポジトリ、メンテナーアカウント、リリース頻度、下流ユーザーの数などを検討してください。

依存関係を最新の状態に保つ方法の一つは、更新提案を含むマージリクエストやプルリクエストを生成するツールを使用することです。また、依存関係の更新と定期的なバックログ項目を優先することも重要です。

ソフトウェア構成分析ツールの評価と比較

セキュリティ チームは、Maven や npm などのパッケージ管理ツールを使用して宣言された依存関係などの粗い粒度レベルと、パッケージ マネージャーを使用せずに「帯域外」で含まれる単一ファイルなどの成果物などの細かい粒度レベルの両方で、SCA ツールが正確な部品表を作成できることを確認する必要があります。

オープンソースライセンス条項に準拠したコンポーネントを使用する

ITリーダーは、ソフトウェア開発者がライセンスのないオープンソースコンポーネントを使用しないように徹底する必要があります。これは法的リスクにつながる可能性があるためです。コンプライアンスを確保し、潜在的な法的問題を回避するためには、ソフトウェア開発で使用するコンポーネントの適切なライセンスを特定することが重要です。

考慮すべき要素には、コンポーネントのリンク方法、展開モデル、意図する配布スキームなどがあります。適切なライセンスを特定したら、それらのオープンソースライセンスに記載されている要件を遵守してください。

次に読む: 2023年の主要なサイバーセキュリティ脅威(TechRepublic)

Tagged: