ビルドを保護する

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

コードの最適化または難読化: たとえば、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 Run 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 タグ付きのイメージを使用）。このようなアプローチは、ビルドで不正なバージョンや望ましくないバージョンの依存関係が使用されるリスクが生じます。

次の事項は、これらのリスクを軽減するのに役立ちます。

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

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

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

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

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