ビルドを保護する

このドキュメントでは、ビルドを保護するためのベストプラクティスについて説明します。コードのビルドでは、次のようなさまざまなタイプのオペレーションを参照できます。

コードの最適化または難読化: たとえば、Google のオープンソースツールである Closure Compiler は、JavaScript の解析と分析、役に立たないコードの削除、残りのコードの修正と最小化を行います。また、コードによくある JavaScript の問題がないかを確認します。
コードを中間コードにコンパイル: たとえば、Java コードを Java クラスファイル（.class）にコンパイルしたり、C++ コードをオブジェクトファイル（.obj）にコンパイルしたりできます。
コードをコンパイルしてリンクし、ライブラリまたは実行可能ファイルを作成: たとえば、C++ コードを共有ライブラリ（.so）または Windows 実行可能ファイル（.exe）にコンパイルします。
配布可能形式またはデプロイ可能な形式にコードをパッケージ化: たとえば、Java クラスファイルから Java WAR（.war）ファイルを作成する、Docker イメージを作成する、Python 組み込みのディストリビューション（.whl）を作成するなどがあります。

使用するプログラミング言語とデプロイ先の環境によっては、ビルドでこれらのオペレーションの組み合わせが異なる場合があります。たとえば、ビルドによって Python コードがビルド済みディストリビューションにパッケージ化し、Artifact Registry や PyPI などのアーティファクトストアにアップロードすることで、Cloud Functions でこれを依存関係として使用できます。また、Python コードをコンテナ化し、コンテナイメージを Cloud Run または Google Kubernetes Engine にデプロイすることもできます。

このドキュメントのプラクティスでは、コードのコンパイルではなく、ランタイム環境へのパッケージ化またはデプロイ用のコードの構築に焦点を当てます。

自動ビルドを使用する

自動ビルドまたはスクリプトビルドは、ビルドスクリプトまたはビルド構成内のすべてのビルドステップ（ソースコードを取得するステップとコードをビルドするステップを含む）を定義します。手動で実行するコマンドは、ビルドを実行するコマンドのみです。

たとえば、ビルドスクリプトは次のようになります。

Cloud Build cloudbuild.yaml。
make ツールで実行する makefile。
.github/workflows/ ディレクトリに格納された YAML 形式の GitHub Actions ワークフローファイル。

自動ビルドでは、ビルドステップで整合性が保たれます。ただし、一貫性のある信頼できる環境でビルドを実行することも重要です。

ローカルビルドはデバッグに役立ちますが、ローカルビルドからソフトウェアをリリースすると、ビルドプロセスに多くのセキュリティ上の問題、不整合、非効率性が生じる場合があります。

ローカルビルドを許可すると、攻撃者が悪意のある方法でビルドプロセスを変更できるようになります。
デベロッパーのローカル環境やデベロッパープラクティスの不整合により、ビルドの再現やビルドの問題の診断が困難になります。

手動ビルドでは、コンピューティング、ストレージ、ネットワークなど、より多くのインフラストラクチャリソースを活用することで、プロセスが非効率的になります。SLSA フレームワークの要件において、自動ビルドは SLSA レベル 1 の要件であり、ビルドの開発環境ではなくビルドサービスを使用することが SLSA レベル 2 の要件です。

Cloud Build は、Google Cloud 上のマネージドビルドサービスです。ビルド構成ファイルを使用して、Cloud Build にビルドステップを提供します。依存関係をフェッチして、単体テスト、静的分析、結合テストを実行し、Docker、Gradle、Maven、Go、Pythos などのビルドツールでアーティファクトを作成するようにビルドを構成できます。Cloud Build は、Artifact Registry、Google Cloud Deploy などの Google Cloud の他の CI/CD サービスに加え、GKE および Cloud Run などのランタイム環境と完全に統合されています。また、GitHub や Bitbucket などの主要なソースコード管理システムとの統合することもできます。

ビルドの来歴を生成する

ビルドの来歴は、ビルドに関する検証可能なデータの集まりです。

来歴のメタデータには、ビルドされたイメージのダイジェスト、入力ソースの場所、ビルドツールチェーン、ビルドステップ、ビルド時間などの詳細情報が含まれます。

ビルドの来歴を生成すると、次のことができます。

信頼できるソースの場所から信頼できるビルドシステムによってビルドされたアーティファクトが作成されたことを検証します。
信頼できないソースの場所またはビルドシステムから挿入されたコードを特定します。

アラートとポリシーメカニズムを使用して、ビルドの来歴データをプロアクティブに使用できます。たとえば、確認済みのソースからビルドされたコードのデプロイのみを許可するポリシーを作成できます。

SLSA レベル 1 の場合、ビルドされたアーティファクトの使用者がビルドの場所にアクセスできる必要があります。SLSA レベル 2 の場合、ビルドの来歴データも次のいずれかである必要があります。

ビルドサービスによって生成されるか、ビルドサービスから直接読み取り可能。
信頼性と整合性に関して使用者が検証可能。これは、ビルドの来歴データを作成するサービスによって生成されたデジタル署名を使用して行う必要があります。

SLSA レベル 3 の場合、来歴のコンテンツには以下を含める必要があります。

ビルド定義のエントリポイント。
ユーザーが制御するすべてのビルドパラメータ。

Cloud Build は、SLSA レベル 3 の保証を提供するコンテナイメージのビルドの来歴を生成します。詳細については、ビルドの来歴の表示をご覧ください。

エフェメラルビルド環境を使用する

エフェメラル環境は、1 回のビルド呼び出しで持続することを目的とした一時的な環境です。ビルド後、環境がワイプまたは削除されます。エフェメラルビルドは、コンテナと VM などのエフェメラル環境でビルドサービスとビルドステップが実行されるようにします。既存のビルド環境を再利用するのではなく、ビルドサービスはビルドごとに新しい環境をプロビジョニングし、ビルドプロセスが完了すると破棄します。

エフェメラル環境では、ビルドプロセスを妨げる可能性のある以前のビルドからの残余ファイルや環境設定がないため、クリーンビルドが保証されます。非エフェメラル環境は、攻撃者が悪意のあるファイルやコンテンツを注入する機会を提供します。エフェメラル環境では、メンテナンスのオーバーヘッドを削減し、ビルド環境の不整合も削減します。

Cloud Build は、ビルドごとに新しい仮想マシン環境を設定し、ビルド後に破棄します。

ビルドサービスへのアクセスを制限する

最小権限のセキュリティ原則に従って、ビルドサービスとビルドリソースに必要な最小限の権限を付与します。また、ビルドを実行し、ビルドの代わりに他のサービスとやり取りするには、人間以外の ID を使用する必要があります。

Cloud Build を使用する場合:

組織のメンバーに必要最小限の権限を付与します。
Cloud Build の代理として動作するサービスアカウントの権限をカスタマイズして、使用に必要な権限のみが付与されるようにします。デフォルトの Cloud Build サービスアカウントの権限を編集するか、代わりにカスタムサービスアカウントの使用を検討してください。
Cloud Build の許可された統合組織ポリシーを使用して、ビルドトリガーの呼び出しを許可する外部サービスを制御します。
VPC Service Controls を使用して、Cloud Build をサービス境界に配置します。境界は、境界内の Google Cloud サービス間の自由な通信を許可しますが、指定したルールに基づいて境界間の通信を制限します。境界は、データの引き出しのリスクも軽減します。

Cloud Build は、プライベートプールで実行するビルドの VPC Service Controls のみをサポートします。

認証情報を保護する

多くの場合、ビルドには、バージョン管理、アーティファクトストア、デプロイ環境など、他のシステムへの接続が含まれます。ビルドで使用する認証情報を保護すると、ソフトウェアサプライチェーンへのシステムへの不正アクセスやデータの引き出しを防ぐことができます。

ハードコードされた認証情報を、バージョン管理またはビルド構成に直接保存しないでください。代わりに、安全なキーストアに認証情報を保存してください。

Google Cloud では、Secret Manager が API キー、パスワード、その他の機密データを安全に保存します。Secret Manager に保存されているシークレットを使用するように Cloud Build を構成できます。

依存関係を管理する

アプリケーションの整合性は、開発したコードと使用する依存関係の両方の整合性に依存します。依存関係の公開場所、アーティファクトリポジトリへの読み取り / 書き込みアクセス権、ランタイム環境にデプロイするビルドアーティファクトのソースのポリシーについても考慮する必要があります。

依存関係の管理について詳しくは、依存関係の管理をご覧ください。

Cloud Build では、クラウドビルダーを使用してコマンドを実行します。ビルダーは、一般的な言語とツールがインストールされているコンテナイメージです。Docker Hub などの公開レジストリ、Cloud Build が提供するビルダー、コミュニティ提供のビルダー、作成したカスタムビルダーなどの公開コンテナイメージを使用できます。また、Google Cloud ビルドパックなどのビルドパックをビルダーとして使用することもできます。

Cloud Build ビルドで使用するビルダーを確認し、それを提供するユーザーを見つけて、ソフトウェアのサプライチェーンでそれらを信頼するかどうかを決定します。ビルダー内のコードをより詳細に管理するため、パブリックソースからビルダーを使用する代わりにカスタムビルダーを作成できます。

ビルドに変更を加える機会を減らす

ビルドに影響を与える可能性があるその他の要因は、次のとおりです。

同時に実行され、互いに影響を与えるビルド、または永続し、後続のビルドに影響を与えるビルド。
ビルドエントリポイントと最上位のソースの場所以外のユーザーパラメータを受け入れるビルド。
変更可能な範囲または依存関係を含む依存関係を指定するビルド（latest タグ付きのイメージなど）。これらのアプローチは、ビルドで不適切または望ましくない依存関係のバージョンが使用されるリスクをもたらします。

以下に、こうしたリスクを軽減する手法を示します。

各ビルドをエフェメラル環境で実行します。
ユーザーがビルドスクリプトで定義された変数に影響を与えないように、追加のパラメータを使用してビルドを実行しないようにします。
ビルドサービスとビルドリソースへのアクセスを制限します。
将来のアーティファクトの異なるバージョンを指すタグなどの識別子ではなく、不変のバージョンの依存関係を参照します。依存関係の詳細については、依存関係の管理をご覧ください。

コンテナ構築のベストプラクティスに従う

次のような信頼性と攻撃に対する脆弱性が低いコンテナイメージを構築する方法については、コンテナ構築のベストプラクティスをご覧ください。

単一のアプリケーションのパッケージ化
プロセスの処理
Docker ビルドキャッシュの最適化
不要なツールを削除し、画像をできるだけ小さくする
Artifact Analysis による脆弱性のスキャン。Artifact Registry に格納されているイメージをスキャンするか、保存する前にローカルでスキャンできます。
タグ付けのベストプラクティス
公開イメージを使用するためのセキュリティの考慮事項

ソフトウェアデリバリーシールド

Software Delivery Shield は、フルマネージドのエンドツーエンドのソフトウェアサプライチェーンセキュリティソリューションです。デベロッパー、DevOps、セキュリティチームがソフトウェアサプライチェーンのセキュリティ体制を強化するために使用できる Google Cloud サービスに、包括的でモジュール式の一連の機能とツールを提供します。これは、Google Cloud コンソールの Cloud Build UI で構築されたアプリケーションのセキュリティ分析情報を表示します。以下に例を示します。

ソフトウェアサプライチェーンのセキュリティの成熟度を識別する SLSA レベル。
ビルドアーティファクトの部品構成表（SBOM）と、Vulnerability Exploitability eXchange（VEX）ステートメント。
ビルドの来歴。ビルドに関する検証可能なメタデータのコレクションです。これには、ビルドされたイメージのダイジェスト、入力ソースの場所、ビルドツールチェーン、ビルドステップ、ビルド時間などの詳細情報が含まれます。

構築されたアプリケーションのセキュリティ分析情報を確認する手順については、アプリケーションの構築とセキュリティ分析情報の表示をご覧ください。