ソフトウェア サプライ チェーンに対する攻撃ベクトルは、誰かが意図的に、または誤ってソフトウェアを侵害できる可能性のあるさまざまな方法です。
脆弱なソフトウェアのリスクには、認証情報や機密データの漏洩、データの破損、マルウェアのインストール、アプリケーションの停止などがあります。このような問題は、時間、費用、顧客の信頼を失う結果につながります。
脅威の侵入ポイントはソフトウェアのライフサイクル全体にまたがり、組織の内外から発生する可能性があります。
図の凡例には、次の 2 つの脅威セットが含まれています。
- 文字 A から H は、ソフトウェア アーティファクトのサプライ チェーン レベル（SLSA）フレームワーク内で脅威脅威として記述される、サプライチェーン内の攻撃ベクトルを示します。
- 番号 1～4 は、SLSA フレームワークで直接記述されていない追加の攻撃ベクトルを示します。
Google Cloud には、両方の脅威を軽減するためのベスト プラクティスが組み込まれた、モジュラー式の一連の機能とツールが用意されています。
このドキュメントのサブセクションでは、ソース、ビルド、デプロイ、依存関係のコンテキストで脅威について説明します。
ソースの脅威
これらの脅威はソースコードの完全性に影響します。
1: 安全でないコードを作成する。安全なコーディング手法がないと、意図せず脆弱性が含まれるコードが作成される可能性があります。安全でないデベロッパー ワークステーションによって、悪意のあるコードや安全でないコードが導入される可能性もあります。緩和策には次のようなものがあります。
- デベロッパー ワークステーションのポリシーの設定。Cloud Workstations は、要件に合わせてカスタマイズできる、フルマネージドの事前構成済みワークステーションを提供します。
- コードのローカル スキャン。Cloud Code のソース保護（非公開プレビュー）は、依存関係の脆弱性やライセンス情報など、リアルタイムのセキュリティ フィードバックを提供します。オンデマンド スキャン API を使用して、デベロッパーはコンテナ イメージの OS と言語パッケージの脆弱性をスキャンすることもできます。
- コードのセキュリティを高める方法に関する教育。
A: ソース リポジトリに不正なコードを提出する。これには、悪意のあるコードだけでなく、クロスサイト スクリプティングなどの攻撃に意図せず脆弱性を引き起こすコードも含まれます。 緩和策には次のようなものがあります。
- ソースコードの変更に対して人間による審査を要求する。
- IDE とソース管理システムと統合されたコードスキャン ツールとリンティング ツールを使用する。
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 のセキュリティ機能を開発、ビルド、デプロイのプロセスに組み込み、ソフトウェア サプライ チェーンのセキュリティ対策を強化します。優先順位と既存のインフラストラクチャに基づいて、サービスを段階的に実装できます。
次のステップ
- セキュリティ体制を評価する。
- ソフトウェア サプライ チェーンを保護するベスト プラクティスについて学習する。