このページは Cloud Translation API によって翻訳されました。

ビルドを保護する

このドキュメントでは、ビルドを保護するためのベストプラクティスについて説明します。建築基準法では、次のようなさまざまな種類の操作が参照されます。

コードの最適化または難読化: たとえば、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 の保証を提供するコンテナイメージのビルドの来歴を生成します。詳細については、ビルドの来歴の表示をご覧ください。

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

エフェメラル環境は、単一のビルド呼び出しで存続することを目的とした一時的な環境です。ビルド後、環境がワイプまたは削除されます。エフェメラルビルドでは、ビルドサービスとビルドステップがコンテナや 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 タグを持つイメージを使用するなど）。これらのアプローチでは、ビルドで不正なバージョンまたは望ましくないバージョンの依存関係が使用されるリスクが生じます。

以下の方法は、これらのリスクを軽減するのに役立ちます。

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

ソフトウェアサプライチェーンのセキュリティ

Google Cloud には、ソフトウェアサプライチェーンのセキュリティ体制を強化するために使用できる一連のモジュラー機能とツールが用意されています。Cloud Build によってビルドされたアプリケーションのセキュリティ分析情報を表示します。モニタリング対象には以下が含まれます。

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

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