{"meta":{"title":"アーティファクト証明書","intro":"アーティファクトの証明書の使用とセキュリティ上の利点について理解します。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/ja/enterprise-cloud@latest/actions/concepts","title":"概念"},{"href":"/ja/enterprise-cloud@latest/actions/concepts/security","title":"セキュリティ"},{"href":"/ja/enterprise-cloud@latest/actions/concepts/security/artifact-attestations","title":"アーティファクト証明書"}],"documentType":"article"},"body":"# アーティファクト証明書\n\nアーティファクトの証明書の使用とセキュリティ上の利点について理解します。\n\n## 概要\n\n構成証明を使用することで、ビルドするソフトウェアに対して検証不可能な証明と整合性の保証を作成できます。 さらに、ソフトウェアを使用するユーザーは、ソフトウェアがビルドされた場所と方法の確認ができます。\n\nソフトウェアを使用してアーティファクトの証明を生成すると、ビルドの来歴を立証し、次の情報を含む暗号署名付きの主張が作成されます。\n\n* 成果物に関連付けられているワークフローへのリンク\n* 成果物のリポジトリ、組織、環境、コミット SHA、トリガーとなったイベント\n* 証明の確立に使用する OIDC トークンからのその他の情報。 詳しくは、「[OpenID Connect](/ja/enterprise-cloud@latest/actions/concepts/security/openid-connect)」をご覧ください。\n\n関連付けられたソフトウェア部品表（SBOM）を含むアーティファクトのアテステーションを生成することもできます。 ビルドを、その中で使用されるオープンソースの依存関係の一覧に関連付けることで、透明性は提供され、コンシューマーがデータ保護標準に準拠できるようになります。\n\n## アーティファクト証明の SLSA レベル\n\nSLSA フレームワークは、サプライ チェーンのセキュリティを評価に使用される業界標準です。 レベルごとに編成されています。 各レベルは、ソフトウェア サプライ チェーンのセキュリティと信頼性の程度を表します。 アーティファクトの証明そのものが、SLSA v1.0 ビルドレベル 2 を提供します。\n\nこれにより、アーティファクトとその構築命令間のリンクが提供されますが、既知の検査済みの構築命令を使用して構築を要求することで、この手順をさらに進めることができます。 これを実現するのに良い方法は、組織全体の多くのリポジトリが共有する再利用可能なワークフローで構築を実行することです。 再利用可能なワークフローは、SLSA v1.0 構築レベル 3 を満たすために、構築プロセスと呼び出し元のワークフローの間で分離を提供できます。 詳しくは、「[成果物の構成証明と再利用可能なワークフローを使用して SLSA v1 ビルド レベル 3 を実現する](/ja/enterprise-cloud@latest/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating)」をご覧ください。\n\nSLSA レベルの詳細については、「[SLSA セキュリティ レベル](https://slsa.dev/spec/v1.0/levels)」を参照してください。\n\n## GitHub がアーティファクトのアテステーションを生成する方法\n\n成果物の構成証明を生成するために、GitHubは Sigstore を使用します。これは、構成証明を介してソフトウェア成果物の署名と検証を行う包括的なソリューションを提供するオープンソース プロジェクトです。\n\n**アーティファクト構成証明を生成するパブリック リポジトリ** では、[Sigstore Public Good Instance](https://openssf.org/blog/2023/10/03/running-sigstore-as-a-managed-service-a-tour-of-sigstores-public-good-instance/) が使用されます。 生成された Sigstore バンドルのコピーは、GitHubと共に格納され、インターネット上でパブリックに読み取り可能な不変の透過性ログにも書き込まれます。\n\nアーティファクト構成証明を生成する **Private リポジトリ**は、GitHubの Sigstore インスタンスを使用します。 GitHub の Sigstore インスタンスは Sigstore Public Good Instance と同じコードベースを使用しますが、透過性ログはなく、 GitHub Actionsとのフェデレーションのみを行います。\n\n## アテステーションを生成するタイミング\n\n構成証明を生成するだけではセキュリティ上の利点はありません。利点を実現するには、構成証明を検証する必要があります。 署名の対象と頻度について検討する方法に関するガイドラインを次に示します。\n\n以下に署名する必要があります。\n\n* ユーザーが `gh attestation verify ...` を実行することを期待しているリリース対象のソフトウェア。\n* ユーザーが実行するバイナリ、ユーザーがダウンロードするパッケージ、または詳細な内容のハッシュを含むマニフェスト。\n\n以下に**署名しないでください**。\n\n* 自動テスト用の頻繁な構築。\n* ソース コード、ドキュメント ファイル、埋め込みイメージなどの個々のファイル。\n\n## アーティファクト証明書の検証\n\n成果物アテステーションを公開するソフトウェアを利用している場合は、GitHub CLI を使用してそれらのアテステーションを検証できます。 構成証明ではソフトウェアの構築場所と方法に関する情報が提供されるため、その情報を使用して、サプライ チェーンのセキュリティを昇格させるセキュリティ ポリシーを作成して適用できます。\n\n> \\[!WARNING] アーティファクトの証明書は、アーティファクトが安全である保証\\_ではない\\_ことを忘れないことが重要です。 代わりに、アーティファクト構成証明はお客様を、ソース コードやそれらを生成したビルド手順にリンクします。 ポリシーの条件を定義し、コンテンツを評価してそのポリシーを評価して、ソフトウェアを使用する際に情報に基づいたリスクを判断するのは、ユーザーの責任です。\n\n## 次のステップ\n\nビルドの成果物構成証明の生成と検証を始めるには、「[アーティファクトの構成証明を使用してビルドの出所を確立する](/ja/enterprise-cloud@latest/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations)」をご覧ください。"}