ソフトウェア サプライ チェーンの脅威

ソフトウェア サプライ チェーンに対する攻撃ベクトルは、誰かが意図的に、または誤ってソフトウェアを侵害できる可能性のあるさまざまな方法です。

脆弱なソフトウェアのリスクには、認証情報や機密データの漏洩、データの破損、マルウェアのインストール、アプリケーションの停止などがあります。これらの問題により、時間、費用、顧客の信頼を失うことになります。

脅威のエントリ ポイントはソフトウェアのライフサイクル全体に及び、組織の内外から発生する可能性があります。

ソフトウェア サプライ チェーン攻撃のエントリ ポイント

図の凡例には、次の 2 つの脅威セットが含まれています。

Google Cloud は、両方の脅威を軽減するためのベスト プラクティスを組み込んだ、モジュール式の機能とツールのセットを提供します。

このドキュメントのサブセクションでは、ソース、ビルド、デプロイ、依存関係のコンテキストで脅威について説明します。

ソースの脅威

これらの脅威は、ソースコードの完全性に影響します。

  • 1: 安全でないコードを作成する。安全なコーディング手法が不足していると、意図せずに脆弱性を含むコードを記述してしまう可能性があります。安全でないデベロッパー ワークステーションは、悪意のあるコードや安全でないコードを導入する可能性もあります。緩和策には次のようなものがあります。

    • デベロッパー ワークステーションのポリシーを設定します。Cloud Workstations は、要件に合わせてカスタマイズできるフルマネージドの事前構成済みワークステーションを提供します。
    • コードのローカル スキャン。Cloud Code のソース保護(非公開プレビュー)は、依存関係の脆弱性やライセンス情報など、リアルタイムのセキュリティ フィードバックを提供します。オンデマンド スキャン API を使用して、デベロッパーはコンテナ イメージの OS と言語パッケージの脆弱性をスキャンすることもできます。
    • コードのセキュリティを高める方法に関する教育。
  • A: ソース リポジトリに不正なコードを提出する。これには、悪意のあるコードだけでなく、クロスサイト スクリプティングなどの攻撃に意図せず脆弱性を引き起こすコードも含まれます。 緩和策には次のようなものがあります。

    • ソースコードの変更に対して人間による審査を要求する。
    • IDE やソース管理システムと統合されたコード スキャンツールと linting ツールを使用する。
  • B: ソース管理システムを不正使用する。ソース管理システムやビルド パイプライン内のその他のシステムへのアクセスを制限し、多要素認証を使用することで、このリスクを軽減できます。

ソースの完全性を評価する際は、ソフトウェアのビルドとデプロイに使用するサポート スクリプトと構成も確認します。これらのファイルに脆弱性がある場合のリスクを軽減するため、ソース コントロール システムとコードレビュー プロセスに含めます。

ソースの保護について詳しくは、ソースの保護をご覧ください。

ビルドの脅威

こうした脅威は、ソフトウェアの構築時やパッケージ化時にソフトウェアを危険にさらすか、ソフトウェアのコンシューマを騙して不正なバージョンを使用させます。

  • C: 信頼できるソース管理システム以外のソースを使用したビルド。このリスクを軽減する緩和策には、次のようなものがあります。
    • Cloud Build などのビルドサービスを使用して来歴情報を生成し、ビルドが信頼できるソースを使用していることを検証できます。
    • CI/CD インフラストラクチャをネットワーク境界内に配置して、ビルドからのデータ流出を防ぐ。 Google Cloud サービスの場合は、VPC Service Controls を使用します。
    • 必要なオープンソース依存関係の信頼できるコピーを Artifact Registry などのプライベート アーティファクト ストアに格納して使用します。
  • D: ビルドシステムを不正使用する。このリスクを軽減する緩和策には、次のようなものがあります。
    • 最小権限の原則に従い、ビルド システムへの直接アクセスを必要とするユーザーに制限します。 Google Cloud では、適切な事前定義ロールを付与するか、カスタムロールを作成できます。
    • Cloud Build などのマネージド ビルドサービスを使用します。 Cloud Build は、ビルドごとに VM 環境を設定し、ビルド後に破棄することで、エフェメラル ビルドを実行します。
    • CI/CD インフラストラクチャをネットワーク境界内に配置して、ビルドからのデータ流出を防ぎます。 Google Cloud サービスの場合は、VPC Service Controls を使用します。
  • F: 正式なプロセス以外でビルドされたソフトウェアをパッケージ化して公開する。ビルドの来歴を生成して署名するビルドシステムを使用すると、信頼できるビルドシステムによってソフトウェアがビルドされたことを検証できます。
  • G: 内部または外部ユーザーのためにソフトウェアを保存するリポジトリを不正使用する。このリスクを軽減する緩和策には、次のようなものがあります。
    • 必要なオープンソース依存関係の信頼できるコピーを Artifact Registry などのプライベート アーティファクト ストアに格納して使用します。
    • ビルドとソースの来歴を検証します。
    • 人間以外の専用のアカウントとリポジトリ管理者に、アップロード権限を制限します。 Google Cloudでは、サービス アカウントはサービスとアプリケーションの代理として機能します。

デプロイとランタイムの脅威

  • H: バージョン範囲または特定のビルド バージョンに永続的に関連付けられていないタグを指定して依存関係を解決すると、次のような問題が発生する可能性があります。

    • ビルドが使用する依存関係は、同じビルドの今後の実行で使用される依存関係とは異なる可能性があるため、ビルドは再現できません。
    • 依存関係が、不正使用されたバージョンや、ソフトウェアを破損させる変更を含むバージョンに解決される可能性があります。不正な行為者は、この不確実性を利用して、使用するバージョンではなく行為者のパッケージのバージョンをビルドに選択させることができます。依存関係に関するベスト プラクティスをいくつか実施することで、依存関係の混乱のリスクを軽減できます。
  • 2: デプロイ プロセスを不正使用する。継続的デプロイ プロセスを使用している場合、そのプロセスが侵害されると、ユーザーに提供するソフトウェアに不要な変更が生じる可能性があります。デプロイ サービスへのアクセスを制限し、本番前環境で変更をテストして、リスクを軽減できます。Cloud Deploy は、環境間の継続的デリバリー プロセスと昇格の管理に役立ちます。

  • 3: 侵害された、または準拠されていないソフトウェアをデプロイする。デプロイ ポリシーを適用することで、このリスクを軽減できます。Binary Authorization を使用して、コンテナ イメージがポリシー基準に準拠していることを検証し、信頼できないソースからのコンテナ イメージのデプロイをブロックできます。

  • 4: 実行中のソフトウェアの脆弱性と構成ミス。

    • 新しい脆弱性は定期的に発見されます。つまり、新しい検出結果によって、本番環境のアプリケーションのセキュリティ リスクレベルが変化する可能性があります。
    • root ユーザーとして実行したり、コンテナの実行時に権限昇格を許可したりするなど、一部の構成では不正アクセスのリスクが高まります。

    GKE セキュリティ対策ダッシュボードには、実行中のワークロードの脆弱性構成の問題に関する情報が表示されます。

    Cloud Run では、デプロイしたコンテナ イメージの既知の脆弱性など、デプロイしたリビジョンに関するセキュリティ分析情報も確認できます。

ソースの保護については、ビルドの保護をご覧ください。また、デプロイの保護については、デプロイの保護をご覧ください。

依存関係の脅威

依存関係には、ビルド内の直接的な依存関係と、直接的な依存関係のダウンストリームにある依存関係の再帰ツリーであるすべての推移的な依存関係が含まれます。

図では、E はビルドで不正な依存関係を使用していることを示します。不適切な依存関係には、次のようなものが含まれます。

  • アプリが依存するソフトウェア(内部で開発したコンポーネント、商用サードパーティ ソフトウェア、オープンソース ソフトウェアなど)。
  • 他の攻撃ベクトルに起因する脆弱性。例:
    • 攻撃者がソース管理システムにアクセスし、プロジェクトで使用されている依存関係のバージョンを変更します。
    • ビルドに、組織内の別のチームが開発したコンポーネントが含まれている。ローカルの開発環境から直接コンポーネントをビルドして公開し、テストとデバッグのためにのみローカルで使用するライブラリに誤って脆弱性が入れられます。
  • 公開リポジトリからオープンソースの依存関係を意図的に削除する。この削除によって、パブリック リポジトリから直接依存関係を取得すると、消費するパイプラインが壊れる可能性があります。

リスクを軽減する方法については、依存関係のベスト プラクティスをご覧ください。

脅威の軽減

サプライ チェーンの全体的な整合性の強度は、最も脆弱な部分と同程度です。攻撃ベクトルを無視すると、サプライ チェーンのその部分で攻撃のリスクが高まります。

同時に、すべてを一度に変更する必要はありません。ソフトウェア サプライ チェーンのセキュリティには、スイス チーズモデルとしてよく知られた累積アクション エフェクトが適用されます。実装する軽減策ごとにリスクが軽減され、サプライ チェーン全体で軽減策を組み合わせると、さまざまな種類の攻撃に対する保護が強化されます。

  • 組織が脅威を検出、対処、修正する能力を評価するのに役立つフレームワークとツールを使用して、セキュリティ体制を評価します。
  • ソフトウェア サプライ チェーンを保護するベスト プラクティスについて学習し、それらのベスト プラクティスをサポートするように設計された Google Cloud プロダクトについて学習します。
  • Google Cloud セキュリティ機能を開発、ビルド、デプロイのプロセスに組み込んで、ソフトウェア サプライ チェーンのセキュリティ体制を改善します。優先順位と既存のインフラストラクチャに基づいて、サービスを段階的に実装できます。

次のステップ