{"meta":{"title":"アーティファクトの構成証明を使用してビルドの出所を確立する","intro":"アーティファクト構成証明を使用すると、ソフトウェアが構築された場所と方法を確立し、構築のサプライ チェーンのセキュリティを強化できます。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/actions","title":"GitHub Actions"},{"href":"/ja/actions/how-tos","title":"方法"},{"href":"/ja/actions/how-tos/secure-your-work","title":"作業をセキュリティで保護する"},{"href":"/ja/actions/how-tos/secure-your-work/use-artifact-attestations","title":"アーティファクト検証証明の使用"},{"href":"/ja/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations","title":"成果物の証明を使用する"}],"documentType":"article"},"body":"# アーティファクトの構成証明を使用してビルドの出所を確立する\n\nアーティファクト構成証明を使用すると、ソフトウェアが構築された場所と方法を確立し、構築のサプライ チェーンのセキュリティを強化できます。\n\n## 前提条件\n\n成果物の構成証明の生成を始める前に、それがどのようなもので、どのようなときに使うべきかを理解しておく必要があります。 「[アーティファクト証明書](/ja/actions/concepts/security/artifact-attestations)」を参照してください。\n\n## ビルドのアーティファクトの証明書を生成する\n\nGitHub Actionsを使用して、バイナリやコンテナー イメージなどの成果物のビルドの実績を確立する成果物構成証明を生成できます。\n\nアーティファクトの証明書を生成するためには、次の手順を行う必要があります。\n\n* ワークフローで適切なアクセス許可が構成されていることを確認します。\n* [\n  `attest`アクション](https://github.com/actions/attest)を使用するステップをワークフローに含めます。\n\n更新されたワークフローを実行すると、アーティファクトが構築され、構築証明を確立するアーティファクトの構成証明が生成されます。 構成証明は、リポジトリ の\\*\\* \\[アクション]\\*\\* タブで表示できます。詳細については、リポジトリ[`attest`](https://github.com/actions/attest)を 参照してください。\n\n### バイナリのビルド由来情報の生成\n\n1. 証明するバイナリを構築するワークフローで、次のアクセス許可を追加します。\n\n   ```yaml\n   permissions:\n     id-token: write\n     contents: read\n     attestations: write\n   ```\n\n2. バイナリが構築された手順の後に、次の手順を追加します。\n\n   ```yaml\n   - name: Generate artifact attestation\n     uses: actions/attest@v4\n     with:\n       subject-path: 'PATH/TO/ARTIFACT'\n   ```\n\n`subject-path` パラメーターの値は、証明したいバイナリへのパスに設定する必要があります。\n\n### コンテナーイメージのビルドプロベナンスを生成する\n\n1. 検証を行うコンテナのイメージを構築するワークフローで、次のアクセス許可を追加します。\n\n   ```yaml\n   permissions:\n     id-token: write\n     contents: read\n     attestations: write\n     packages: write\n   ```\n\n2. イメージが構築された手順の後に、次の手順を追加します。\n\n   ```yaml\n   - name: Generate artifact attestation\n     uses: actions/attest@v4\n     with:\n       subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}\n       subject-digest: 'sha256:fedcba0...'\n       push-to-registry: true\n   ```\n\n   パラメーターの `subject-name` 値には、完全修飾イメージ名を指定する必要があります。 たとえば、`ghcr.io/user/app` または `acme.azurecr.io/user/app` です。 イメージ名の一部としてタグを含めることはしないでください。\n\n   パラメーターの`subject-digest`の値は、アテステーションの対象のSHA256ダイジェストに基づいて`sha256:HEX_DIGEST`形式で設定する必要があります。 ワークフローで使用 `docker/build-push-action` する場合は、そのステップの [`digest`](https://github.com/docker/build-push-action?tab=readme-ov-file#outputs) 出力を 使用して値を指定できます。 出力の使用の詳細については、「[GitHub Actions　のワークフロー構文](/ja/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idoutputs)」を参照してください。\n\n## ソフトウェア部品表 (SBOM) のための証明書の生成\n\nワークフロー アーティファクトの署名付き SBOM 構成証明を生成できます。\n\nSBOM の構成証明を生成するには、次の手順を実行する必要があります。\n\n* ワークフローで適切なアクセス許可が構成されていることを確認します。\n* アーティファクトの SBOM を作成します。 詳細については、`anchore-sbom-action`の[](https://github.com/marketplace/actions/anchore-sbom-action)を参照してください。\n* ワークフローに[`attest`アクション](https://github.com/actions/attest)と`sbom-path`入力を使用するステップを含めます。\n\n更新されたワークフローを実行すると、アーティファクトが構築され、SBOM 構成証明が生成されます。 構成証明は、リポジトリ の\\*\\* \\[アクション]\\*\\* タブで表示できます。詳細については、リポジトリ[`attest`](https://github.com/actions/attest)を 参照してください。\n\n### バイナリの SBOM 構成証明の生成\n\n1. 証明するバイナリを構築するワークフローで、次のアクセス許可を追加します。\n\n   ```yaml\n   permissions:\n     id-token: write\n     contents: read\n     attestations: write\n   ```\n\n2. バイナリが構築された手順の後に、次の手順を追加します。\n\n   ```yaml\n   - name: Generate SBOM attestation\n     uses: actions/attest@v4\n     with:\n       subject-path: 'PATH/TO/ARTIFACT'\n       sbom-path: 'PATH/TO/SBOM'\n   ```\n\n   パラメーターの`subject-path`値は、SBOM が記述するバイナリのパスに設定する必要があります。 パラメーターの`sbom-path`値は、生成した SBOM ファイルのパスに設定する必要があります。\n\n### コンテナイメージの SBOM 証明書の生成\n\n1. 検証を行うコンテナのイメージを構築するワークフローで、次のアクセス許可を追加します。\n\n   ```yaml\n   permissions:\n     id-token: write\n     contents: read\n     attestations: write\n     packages: write\n   ```\n\n2. イメージが構築された手順の後に、次の手順を追加します。\n\n   ```yaml\n   - name: Generate SBOM attestation\n     uses: actions/attest@v4\n     with:\n       subject-name: ${{ env.REGISTRY }}/PATH/TO/IMAGE\n       subject-digest: 'sha256:fedcba0...'\n       sbom-path: 'sbom.json'\n       push-to-registry: true\n   ```\n\n   パラメーターの `subject-name` 値には、完全修飾イメージ名を指定する必要があります。 たとえば、`ghcr.io/user/app` または `acme.azurecr.io/user/app` です。 イメージ名の一部としてタグを含めることはしないでください。\n\n   パラメーターの`subject-digest`の値は、アテステーションの対象のSHA256ダイジェストに基づいて`sha256:HEX_DIGEST`形式で設定する必要があります。 ワークフローで使用 `docker/build-push-action` する場合は、そのステップの [`digest`](https://github.com/docker/build-push-action?tab=readme-ov-file#outputs) 出力を 使用して値を指定できます。 出力の使用の詳細については、「[GitHub Actions　のワークフロー構文](/ja/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idoutputs)」を参照してください。\n\n   パラメーターの `sbom-path` 値は、構成証明する JSON 形式の SBOM ファイルへのパスに設定する必要があります。\n\n## linked artifacts page へのアーティファクトのアップロード\n\n認証済みアセットを組織のlinked artifacts pageにアップロードすることをお勧めします。 このページには、成果物のビルド履歴、デプロイ レコード、およびストレージの詳細が表示されます。 このデータを使用して、セキュリティ アラートに優先順位を付けたり、脆弱な成果物を所有するチーム、ソース コード、ビルド実行にすばやく接続したりすることができます。 詳しくは、「[リンクされた成果物について](/ja/code-security/concepts/supply-chain-security/linked-artifacts)」をご覧ください。\n\n[attest](https://github.com/actions/attest) アクションは、次の両方の場合、linked artifacts page にストレージ レコードを自動的に作成します。\n\n* `push-to-registry` オプションは次の値に設定されます。`true`\n* アクションを含むワークフローには、 `artifact-metadata: write` アクセス許可があります\n\nワークフロー例については、「[ストレージとデプロイのデータをアップロードしてlinked artifacts page](/ja/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/upload-linked-artifacts#generating-an-attestation)」を参照してください。\n\n## GitHub CLI を使用したアーティファクトの構成証明の検証\n\nバイナリとコンテナー イメージの成果物構成証明を検証し、 GitHub CLIを使用して SBOM 構成証明を検証できます。 詳細については、`attestation`マニュアルの「[](https://cli.github.com/manual/gh_attestation)」セクションを参照してください。\n\n> \\[!NOTE] これらのコマンドは、オンライン環境であることを前提としています。 オフライン環境またはエアギャップ環境の場合は、「[オフラインでのアテステーションの確認](/ja/actions/how-tos/secure-your-work/use-artifact-attestations/verify-attestations-offline)」を参照してください。\n\n### バイナリのアーティファクト証明書を検証する\n\n**バイナリ**の成果物構成証明を確認するには、次の GitHub CLI コマンドを使用します。\n\n```bash copy\ngh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME\n```\n\n### コンテナー イメージのアーティファクト証明を検証する\n\n**コンテナー イメージ**のアーティファクト構成証明を確認するには、バイナリへのパスではなく、`oci://`プレフィックスが付いたイメージの FQDN を指定する必要があります。 次の GitHub CLI コマンドを使用できます。\n\n```bash copy\ndocker login ghcr.io\n\ngh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test -R ORGANIZATION_NAME/REPOSITORY_NAME\n```\n\n### SBOMの証明書を検証する\n\nSBOM 証明書を検証するには、既定以外の述語を参照するために `--predicate-type` のフラグを指定する必要があります。 詳細については、<c1> リポジトリの「検証済み述語」を参照してください。\n\nたとえば、現在、[`attest` アクション](https://github.com/actions/attest)は SPDX または CycloneDX SBOM 述語のいずれかをサポートしています。 SPDX 形式で SBOM 構成証明を確認するには、次の GitHub CLI コマンドを使用できます。\n\n```bash copy\ngh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY \\\n  -R ORGANIZATION_NAME/REPOSITORY_NAME \\\n  --predicate-type https://spdx.dev/Document/v2.3\n```\n\n構成証明の詳細情報を表示するには、`--format json` フラグを参照してください。 SBOM 証明を検証する時に特に役立ちます。\n\n```bash copy\ngh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY \\\n  -R ORGANIZATION_NAME/REPOSITORY_NAME \\\n  --predicate-type https://spdx.dev/Document/v2.3 \\\n  --format json \\\n  --jq '.[].verificationResult.statement.predicate'\n```\n\n## 次のステップ\n\n構成証明の関連性と管理性を維持するため、不要になった構成証明は削除する必要があります。 「[成果物（テクノロジー）証明のライフサイクルの管理](/ja/actions/how-tos/secure-your-work/use-artifact-attestations/manage-attestations)」を参照してください。\n\nまた、コンシューマーがリリースの整合性と配信元を検証できるように、リリース構成証明を生成することもできます。 詳しくは、「[変更不可リリース](/ja/code-security/concepts/supply-chain-security/immutable-releases)」をご覧ください。"}