{"meta":{"title":"ビルド システムをセキュリティで保護するためのベスト プラクティス","intro":"サプライ チェーンの終端を保護する方法 (成果物の構築と配布に使用するシステム) に関するガイダンス。","product":"セキュリティとコードの品質","breadcrumbs":[{"href":"/ja/code-security","title":"セキュリティとコードの品質"},{"href":"/ja/code-security/tutorials","title":"Tutorials"},{"href":"/ja/code-security/tutorials/implement-supply-chain-best-practices","title":"サプライ チェーンのベスト プラクティスを実装する"},{"href":"/ja/code-security/tutorials/implement-supply-chain-best-practices/securing-builds","title":"ビルドをセキュリティで保護する"}],"documentType":"article"},"body":"# ビルド システムをセキュリティで保護するためのベスト プラクティス\n\nサプライ チェーンの終端を保護する方法 (成果物の構築と配布に使用するシステム) に関するガイダンス。\n\n## このガイドについて\n\nこのガイドでは、ビルド システムのセキュリティを向上させるために加えられる最も影響が大きい変更について説明します。 各セクションで、セキュリティを向上させるためにプロセスに対して行うことができる変更の概要を示します。 変更は影響が大きい順に示されます。\n\n## リスクとは\n\nソフトウェア サプライ チェーンに対する攻撃の一部は、ビルド システムを直接対象とします。 攻撃者がビルド プロセスを変更できる場合は、個人アカウントやコードを侵害することなく、システムを悪用するおそれがあります。 ビルド システムだけでなく、個人のアカウントやコードも忘れずに保護することが重要です。\n\n## ビルド システムのセキュリティによる保護\n\nビルド システムに必要なセキュリティ機能がいくつかあります。\n\n1. ビルドの手順は明確で繰り返すことができる必要があります。\n\n2. ビルド プロセス中に何が実行されていたかを正確に把握する必要があります。\n\n3. 各ビルドは新しい環境で開始する必要があるため、侵害されたビルドは今後のビルドに影響を与えることはありません。\n\nGitHub Actions は、これらの機能を満たすのに役立ちます。 ビルド手順は、コードと共にリポジトリに格納されます。 ご自分でホストする Windows、Mac、Linux、ランナーなど、ビルドを実行する環境を選びます。 各ビルドは新しいランナー イメージから始まり、ビルド環境に攻撃が持続することは困難になります。\n\nセキュリティ上の利点に加えて、 GitHub Actions では、頻繁かつ高速なビルドのために、手動、定期的、またはリポジトリ内の git イベントでビルドをトリガーできます。\n\nGitHub Actionsは大きなトピックですが、[GitHub Actionsについて](/ja/actions/get-started/understand-github-actions)、[GitHub Actions　のワークフロー構文](/ja/actions/reference/workflows-and-actions/workflow-syntax#choosing-github-hosted-runners)、および[ワークフローをトリガーする](/ja/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow)が入門に適しています。\n\n## ビルドのアーティファクト構成証明を生成する\n\n構成証明を使用することで、ビルドするソフトウェアに対して検証不可能な証明と整合性の保証を作成できます。 さらに、ソフトウェアを使用するユーザーは、ソフトウェアがビルドされた場所と方法の確認ができます。\n\nソフトウェアを使用してアーティファクトの証明を生成すると、ビルドの来歴を立証し、次の情報を含む暗号署名付きの主張が作成されます。\n\n* 成果物に関連付けられているワークフローへのリンク\n* 成果物のリポジトリ、組織、環境、コミット SHA、トリガーとなったイベント\n* 証明の確立に使用する OIDC トークンからのその他の情報。 詳しくは、「[OpenID Connect](/ja/actions/concepts/security/openid-connect)」をご覧ください。\n\n関連付けられたソフトウェア部品表（SBOM）を含むアーティファクトのアテステーションを生成することもできます。 ビルドを、その中で使用されるオープンソースの依存関係の一覧に関連付けることで、透明性は提供され、コンシューマーがデータ保護標準に準拠できるようになります。\n\nアーティファクト構成署名には、ビルド アーティファクトへの署名、ソース コードへのリンク、ビルド手順が含まれます。 アーティファクト構成証明を使用してビルドに署名する場合、独自の署名キー マテリアルを管理する必要はありません。\nGitHub は、Microsoft が運用する署名機関でこれを処理します。\n\n詳しくは、「[アーティファクトの構成証明を使用してビルドの出所を確立する](/ja/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations)」をご覧ください。\n\n## ビルドに署名する\n\nビルド プロセスがセキュリティで保護されたら、誰かがビルド プロセスの最終的な結果を改ざんできないようにする必要があります。 これを行う優れた方法は、ビルドに署名することです。 ソフトウェアをパブリックに配布する場合、多くの場合、公開/秘密の暗号化キー ペアで行われます。 秘密キーを使用してビルドに署名し、公開キーを公開して、ソフトウェアのユーザーがビルドの署名を使用する前に確認できるようにします。 ビルドのバイトが変更された場合、署名は検証されません。\n\nビルドに正確に署名する方法は、記述しているコードの種類とユーザーによって異なります。 多くの場合、秘密キーを安全に格納する方法を知ることは困難です。 ここでの基本的なオプションの 1 つは、暗号化されたシークレット GitHub Actions 使用することですが、それらの GitHub Actions ワークフローにアクセスできるユーザーを制限するように注意する必要があります。\n公開インターネット (Microsoft Azure、HashiCorp Vault など) 経由でアクセスできる別のシステムに秘密キーが格納されている場合、より高度なオプションは OpenID Connect で認証するため、システム間でシークレットを共有する必要はありません。 秘密キーにプライベート ネットワークからのみアクセスできる場合は、 GitHub Actionsにセルフホステッド ランナーを使用することもできます。\n\n詳細については、「 [GitHub Actions でのシークレットの使用](/ja/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets)、 [OpenID Connect](/ja/actions/concepts/security/openid-connect)、 、 [セルフホステッド ランナー](/ja/actions/concepts/runners/self-hosted-runners)」を参照してください。\n\n## 変更不可リリースを使用する\n\nビルド システムで他のプロジェクトのリリース アセットを使用する場合、または独自の作業用のリリースを作成する場合は、それらのリリースを変更不可にして、つまり発行後に変更できないようにして、セキュリティ リスクを軽減する必要があります。 変更不可リリースは、サプライ チェーン攻撃や偶発的な破壊的変更を防ぐのに役立ちます。 詳しくは、「[変更不可リリース](/ja/code-security/concepts/supply-chain-security/immutable-releases)」をご覧ください。\n\n## GitHub Actions のセキュリティを強化する\n\nGitHub Actionsをさらにセキュリティで保護するには、さらに多くの手順を実行できます。 特に、サードパーティのワークフローを評価する場合は注意が必要です。また、ワークフローに変更を加えることができるユーザーを制限するために `CODEOWNERS` を使用することを検討してください。\n\n詳細については、「[セキュリティで保護された使用に関するリファレンス](/ja/actions/reference/security/secure-use#writing-workflows)」および「[セキュリティで保護された使用に関するリファレンス](/ja/actions/reference/security/secure-use)」を参照してください。\n\n## 次のステップ\n\n* [エンドツーエンドのサプライ チェーンのセキュリティ保護](/ja/code-security/tutorials/implement-supply-chain-best-practices/end-to-end-supply-chain-overview)\n\n* [アカウントをセキュリティで保護するためのベスト プラクティス](/ja/code-security/tutorials/implement-supply-chain-best-practices/securing-accounts)\n\n* [サプライ チェーンのコードをセキュリティで保護するためのベスト プラクティス](/ja/code-security/tutorials/implement-supply-chain-best-practices/securing-code)"}