セキュリティ & アイデンティティ

オープンソースソフトウェアの既知の信頼できるサプライヤーを選択する方法

2024年4月9日

Google Cloud Japan Team

※この投稿は米国時間 2024 年 3 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

デベロッパーによるソフトウェアツール、アプリ、サービスの構築を支援するために、オープンソースソフトウェアはテクノロジー業界全体で使用されています。オープンソースソフトウェアを構築に利用しているデベロッパーは、他者によるオープンソースの成果物から大きな恩恵を受けられますが、同時に、ソフトウェアサプライチェーンへの攻撃から保護するために適切なデューデリジェンスを実施する必要もあります。

Citi と Google の両社は、オープンソースソフトウェアのサプライチェーンのリスク管理にいっそう注力するなか、特にオープンソースコンポーネントの調達先である信頼できる既知のサプライヤーを選ぶ際に、リスク軽減全体により厳格に対応するよう努めています。

オープンソースへの主な攻撃ベクトル

https://storage.googleapis.com/gweb-cloudblog-publish/images/Key_open_source_attack_vectors.max-2200x2200.png

上の図には、オープンソースへの主な攻撃ベクトルが示されています。ソフトウェアサプライチェーンへの一般的なセキュリティ攻撃は、主に 5 つのタイプに分類できます。

コードの脆弱性を利用した実行時の攻撃
リポジトリ、ツール、プロセスに対する攻撃
パイプラインを通過する際のアーティファクトの整合性に対する攻撃
顧客アプリケーションが利用する主なオープンソースの依存関係に対する攻撃
オープンソースパッケージの継承された推移的依存関係のチェーン全体に対する攻撃

このような攻撃が近年増加するにつれて、アプリケーションセキュリティ専門家の作業は増大し、困難になってきています。オープンソースコンポーネントは、動作するために他のオープンソースコンポーネントの機能を含み、その機能に依存することが少なくありません。オープンソースコンポーネントの依存関係には、直接依存関係と推移的依存関係の 2 種類があります。

一般的に、相互作用は次のようになります。アプリケーションが、直接依存関係に対して最初の呼び出しを行います。直接依存関係が機能するために外部コンポーネントが必要な場合、その外部コンポーネントがアプリケーションの推移的依存関係と呼ばれます。

このような依存関係は修復が非常に困難です。その理由は、デベロッパーが依存関係にすぐにアクセスできないためです。依存関係のコードベースはメンテナンス担当者に委ねられており、結果としてアプリケーションはその担当者の作業に左右されることになります。こういった推移的依存関係のうち一つの修正が担当者によってリリースされた場合、修正がサプライチェーンを遡って直接依存関係に影響を与えるまでには、かなりの時間がかかる可能性があります。

よって、脆弱性の管理は推移的依存関係のチェーン全体にまで拡張する必要があります。その理由は、ここで脆弱性の 95% が検出されるためです。ソフトウェア開発ライフサイクル（SDLC）ツールの定期的なアップグレードとパッチ適用のプロセスを維持することは今や不可欠になっています。また、リポジトリとプロセスの両方のセキュリティをアップグレードし、それぞれのアクティブなセキュリティテストを行うことも必須です。

改ざん履歴がないことを示す来歴と署名により、パイプライン全体でアーティファクトの整合性を維持する信頼性を高めることができます。また、すべての外部コンポーネントについて推移的依存関係のチェーン全体をマッピングして理解すること、信頼できる既知のプロバイダからのみこれらのコンポーネントを調達することが必須条件となります。

CISA などの政府機関による最近のガイダンスでは、信頼できるソースからの導入に先立ってオープンソースソフトウェアを適切に選択しテストすることの重要性が裏付けられています。一部の組織はビルドされたソフトウェアアーティファクトをパブリックパッケージリポジトリから直接読み込みますが、セキュリティリスクを避ける傾向の強い組織では、厳選されたオープンソースソフトウェアプロバイダを利用した、より厳格なセキュリティ管理が求められます。

このような組織は、自社でソースからビルドしたオープンソースソフトウェアのみを利用しようとすることもありますが、大抵の場合は費用がかかりすぎてしまいます。では、厳選されたサードパーティの使用を選択した場合、その重要な権限を委任する前にどのようなことを確認する必要があるのでしょうか。

厳選された OSS ベンダーを評価するには、主に 3 つの基準があります。

1. 高いレベルのセキュリティ成熟度

信頼できるサプライヤーは、高いレベルのセキュリティ成熟度を証明する必要があります。一般的に焦点があてられるのは、特にサプライヤーのセキュリティ対策を調査することです。組織内の脆弱性管理に関する文化と、迅速にパッチを適用して最新の状態に保つ能力について詳細を確認します。また、あらゆるインシデントに迅速に対処できる十分なトレーニングを受けたチームと、組織のセキュリティポスチャーを継続的に検証する定期的なペネトレーションテストのチームも必要です。

信頼できるサプライヤーは、自社の基盤インフラストラクチャのセキュリティを証明できる必要があります。サプライヤーが次の条件を満たしていることをご確認ください。

自社の外部依存関係の最新インベントリが用意されている。
すべての取り込みポイントに関する知識があり、それらを管理できる。
1 つの本番環境ビルドサービスを活用して、1 つの論理コントロールポイントを維持できる。
インフラストラクチャを管理するための次のようなベストプラクティスの基準を満たしている。

適切に設計された職掌分散と IAM コントロール
ゼロトラストネットワーク設計を保護する組み込みの組織ポリシーとガードレール
関連する証拠を伴う定期的な自動パッチ適用
検出、ロギング、モニタリングシステムを使った補完的で継続的な脅威の検出による、これらのポスチャー管理のサポート
「すべてをコード化」して、再現可能かつ検証可能な密閉型のビルドで運用していればベター

2. 高いレベルの内部 SDLC セキュリティ

信頼できるサプライヤーの SDLC のセキュリティレベルは非常に高くなければなりません。SDLC のコントロールプレーンと、最終プロダクトを構築するためにソースコードを操作するコンポーネントのセキュリティについては特にそうです。各システムには厳重なセキュリティ保護と精査が行われ、ソフトウェアの変更があった場合は、必ずレビューと監査を経て、次の段階やデプロイに進む前に複数の関係者による承認が必要となるように徹底されなくてはなりません。さらに、強固な認証および認可ポリシーを適用することで、信頼性の高い個人のみがベンダーインフラストラクチャを構築、変更できるようにする必要があります。

SDLC セキュリティは、組織へのソースコードマテリアルの取り込みにおける最初の段階や、システム自体のコントロールプレーン内で使用されるコードや機能にも適用される必要があります。

3. 効果的なインサイダー脅威プログラム

信頼できるサプライヤーは価値の高いターゲットであるため、攻撃ベクトルとしてインサイダー脅威が存在する可能性があります。それゆえ、厳選されたベンダーには、積極的かつ効果的なインサイダー脅威プログラムが求められます。また、こうした担当者の審査アプローチを拡張して、すべてのスタッフ拠点が承認された地域内にあり、アウトソーシングされないようにする必要があります。

信頼するが検証はする

信頼できるサプライヤーが、裏付けとなる証拠と分析情報を提供することも重要です。この証拠には次のものが含まれます。

サードパーティの認証または独自の自主監査に基づく、インフラストラクチャのセキュリティとプロセスに関する検証可能な証明書。
SLSA や SSDF などの標準フレームワークに照らした、SDLC のセキュリティポスチャーおよびプロセスに関する検証可能な証明書。
提供されるパッケージおよび付随する関連メタデータに対する暗号署名（ソースと配布の整合性を検証するため）。

パッケージに関する問題の実際の関連性とセキュリティリスクは、

単独でのパッケージ固有の重要性、パッケージが使用されるコンテキスト、パッケージがデプロイされる環境条件、外部の代替コントロール、環境内リスクの増減の組み合わせによって決まります。以下の図は、アプリケーションと基盤インフラストラクチャの間における脆弱性および脅威の相互関係と相互作用を示しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/End_to_end_risk_diagram.max-2200x2200.png

4. 提供される各パッケージに付随する高度なセキュリティとリスクのメタデータ。これにより、コードやアーティファクトに固有のコンポーネントリスクに加え、そのリスクが特定のアプリケーションや環境のコンテキストでどのように変化する可能性があるかについて理解を深め、分析情報を強化できます。主なメタデータには次のものが含まれる場合があります。

SCA の分析情報を含んだ標準 SBOM - 脆弱性、ライセンス情報、完全にマッピングされた推移的依存関係、関連する脆弱性とライセンスに関するリスク。
推移的依存関係から継承された脆弱性が、提供される主要パッケージにどのような影響を与えるかを示す VEX ステートメント。
パッケージやユースケース、組織に固有の関連する脅威インテリジェンス。

このような詳細なデータを提示できることにより、サプライヤーが高度なセキュリティを達成しており、提供されるコンポーネントが信頼性の高い確実な構成要素であって、安心して利用できるものであることが裏付けられます。

オープンソースコンポーネントの利点の管理とバランスの向上

オープンソースコンポーネントを活用することは、開発速度、品質、イノベーションと実行の加速にとって欠かせません。これらの推奨事項と要件を適用すると、オープンソースコンポーネントを使用することの利点と、SDLC にターゲットとなる弱点が生じうることのリスクを適切に管理して両者のバランスを取ることが可能となり、最終的にはリスクと脅威を低減できます。

Java および Python エコシステム向けの Google Cloud の Assured Open Source Software（Assured OSS）サービスは、Google が保護して使用しているのと同じ OSS パッケージを独自のデベロッパーワークフローに組み込むことで、オープンソースソフトウェアを使用する組織に対して、Google がオープンソースの依存関係に適用するセキュリティとエクスペリエンスを活用する機会を提供します。

ぜひ Assured Open Source Software の詳細を確認し、セルフサービスオンボーディングフォームに記入して、Assured OSS を有効にしてみてください。また、Metadata API を使用すれば、利用可能な Python および Java パッケージをリストし、使用する Assured OSS パッケージの判断にご活用いただけます。