{"meta":{"title":"セキュリティで保護された使用に関するリファレンス","intro":"ワークフローの作成と GitHub Actions 機能の使用に関するセキュリティ プラクティス。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/actions","title":"GitHub Actions"},{"href":"/ja/actions/reference","title":"リファレンス"},{"href":"/ja/actions/reference/security","title":"セキュリティ"},{"href":"/ja/actions/reference/security/secure-use","title":"セキュリティで保護された使用"}],"documentType":"article"},"body":"# セキュリティで保護された使用に関するリファレンス\n\nワークフローの作成と GitHub Actions 機能の使用に関するセキュリティ プラクティス。\n\nワークフローを作成し、GitHub Actions のセキュリティ機能を使う場合のセキュリティのベスト プラクティスについて説明します。\n\n## ワークフローの書き込み\n\n### 機密情報にはシークレットを使用する\n\nシークレットの値を変換する方法は複数あるため、この自動リダクトは保証されません。 シークレットに関連するリスクを最小限に抑えるために、次のベスト プラクティスに従ってください。\n\n* **最小限の特権の原則**\n  * リポジトリへの書き込みアクセス権限を持つすべてのユーザーは、リポジトリに構成されているすべてのシークレットへの読み取りアクセス権を持っています。 そのため、ワークフロー内で使われる認証情報が持つ特権は必要最小限のものにする必要があります。\n  * Actions は、`GITHUB_TOKEN` コンテキストからアクセスすることで `github.token` を使用できます。 詳しくは、「[コンテキスト リファレンス](/ja/actions/learn-github-actions/contexts#github-context)」をご覧ください。 したがって、`GITHUB_TOKEN` に最低限必要な権限が付与されていることを確認する必要があります。 リポジトリの内容の読み取りアクセスのみを行うように `GITHUB_TOKEN` の既定のアクセス許可を設定することを、セキュリティの点からお勧めします。 その後、必要に応じて、ワークフローファイル内の個々のジョブの権限を増やすことができます。 詳しくは、「[ワークフローでの認証に GITHUB\\_TOKEN を使用する](/ja/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token)」をご覧ください。\n* **機密データをマスクする**\n  * 機密データは、ワークフロー ファイルにプレーンテキストとして格納**しないでください**。\n    `::add-mask::VALUE` を使って、GitHub シークレットではないすべての機密情報をマスクします。 これにより、値がシークレットとして扱われ、ログから編集されます。 データのマスキングの詳細については、「[GitHub Actions のワークフロー コマンド](/ja/actions/using-workflows/workflow-commands-for-github-actions#masking-a-value-in-a-log)」を参照してください。\n* **外部から参照可能な状態になっているシークレットを削除してローテーションする**\n  * シークレットの編集は、ワークフロー ランナーによって実行されます。 つまり、シークレットはジョブ内で使用され、実行者によりアクセス可能である場合のみ編集されます。 未変換のシークレットがワークフロー実行ログに送信される場合は、ログを削除してシークレットをローテーションする必要があります。 ログの削除の詳細については、「[ワークフロー実行ログの使用](/ja/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#deleting-logs)」を参照してください。\n* **構造化データをシークレットとして使わない**\n  * 構造化データは、ログ内のシークレットの編集失敗の原因となる可能性があります。これは、編集が特定のシークレット値の完全一致を見つけることに大きく依存しているためです。 たとえば、JSON、XML、または YAML（または同様）の Blob を使用してシークレット値をカプセル化しないでください。シークレットが適切に編集される可能性が大幅に低下するためです。 代わりに、機密値ごとに個別のシークレットを作成します。\n* **ワークフロー内で使われるすべてのシークレットを登録する**\n  * シークレットを使ってワークフロー内で別の機密値を生成する場合は、その生成された値を正式に[シークレットとして登録](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)して、ログに表示されることがある場合は編集された状態になるようにする必要があります。 たとえば、秘密鍵を使用して署名済み JWT を生成し、Web API にアクセスする場合は、その JWT をシークレットとして登録してください。そうしない場合、ログ出力に入力されても編集されません。\n  * シークレットの登録は、あらゆる種類の変換/エンコーディングにも適用されます。 シークレットが何らかの方法で変換された場合（Base64 や URL エンコードなど）、新しい値もシークレットとして登録してください。\n* **シークレットの処理方法を監査する**\n  * シークレットの使用方法を監査し、シークレットが想定どおりに処理されていることを確認します。 これを行うには、ワークフローを実行しているリポジトリのソースコードを確認し、ワークフローで使用されているアクションを確認します。 たとえば、意図しないホストに送信されていないか、またはログ出力に明示的に出力されていないかを確認します。\n  * 有効/無効な入力をテストした後、ワークフローの実行ログを表示し、シークレットが正しく編集されているか、表示されていないかを確認します。 呼び出しているコマンドまたはツールがどのようにしてエラーを `STDOUT` や `STDERR` に送信するかは必ずしも明らかではなく、シークレットが後でエラー ログに記録される可能性があります。 そのため、有効な入力と無効な入力をテストした後、ワークフローログを手動で確認することをお勧めします。 機密データが意図せず含まれている可能性があるワークフロー ログをクリーンアップする方法については、「[ワークフロー実行ログの使用](/ja/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#deleting-logs)」を参照してください。\n* **登録されたシークレットの監査とローテーションを行う**\n  * 登録されたシークレットを定期的に確認して、現在も必要であることを確認します。 不要になったものは削除してください。\n  * シークレットを定期的にローテーションして、不正使用されたシークレットが有効である期間を短縮します。\n* **シークレットへのアクセスのレビューを必須にすることを検討する**\n  * 必須のレビュー担当者を使って環境のシークレットを保護できます。 レビュー担当者によって許可されるまで、ワークフローのジョブは環境のシークレットにアクセスできません。 環境へのシークレットの格納や環境のレビューの要求の詳細については、「[GitHub Actions でのシークレットの使用](/ja/actions/security-guides/using-secrets-in-github-actions)」と「[デプロイメント用の環境管理](/ja/actions/deployment/targeting-different-environments/managing-environments-for-deployment)」を参照してください。\n\n### スクリプト インジェクション攻撃を軽減するための優れたプラクティス\n\nワークフローにおけるスクリプト インジェクションのリスクを軽減するための推奨されるアプローチ:\n\n#### インライン スクリプトの代わりにアクションを使う\n\n推奨されるアプローチは、コンテキストの値を引数として処理するアクションを作成することです。 このアプローチは、コンテキストの値はシェル スクリプトの生成には使われず、代わりに引数としてアクションに渡されるため、インジェクション攻撃に対して脆弱ではありません。\n\n```yaml\nuses: fakeaction/checktitle@v3\nwith:\n  title: ${{ github.event.pull_request.title }}\n```\n\n#### 中間環境変数を使用する\n\nインライン スクリプトの場合、信頼されない入力を処理するための推奨される方法は、式の値を中間環境変数に設定することです。 次の例では、Bash を使って `github.event.pull_request.title` の値を環境変数として処理しています。\n\n```yaml\n      - name: Check PR title\n        env:\n          TITLE: ${{ github.event.pull_request.title }}\n        run: |\n          if [[ \"$TITLE\" =~ ^octocat ]]; then\n          echo \"PR title starts with 'octocat'\"\n          exit 0\n          else\n          echo \"PR title did not start with 'octocat'\"\n          exit 1\n          fi\n```\n\nこの例では、スクリプトの挿入の試行が失敗し、ログの行で次のように示されています。\n\n```shell\n   env:\n     TITLE: a\"; ls $GITHUB_WORKSPACE\"\nPR title did not start with 'octocat'\n```\n\nこの方法では、`${{ github.event.pull_request.title }}` 式の値はメモリに格納されて変数として使われ、スクリプト生成プロセスとはやり取りされません。 さらに、二重引用符シェル変数を使って[単語分割](https://github.com/koalaman/shellcheck/wiki/SC2086)を回避することを検討します。ただし、これはシェル スクリプトの記述に関する[多くの一般的な推奨事項の 1 つ](https://mywiki.wooledge.org/BashPitfalls)であり、GitHub Actions に固有ではありません。\n\n#### code scanning のワークフロー テンプレートの使用\n\nCode scanning を使うと、運用環境に到達する前にセキュリティの脆弱性を見つけることができます。 GitHub には、code scanning 用のワークフロー テンプレートが用意されています。 最初から作るのではなく、これらの推奨されるワークフローを使って、code scanning ワークフローを作成できます。 GitHub のワークフロー、CodeQL 分析ワークフローには、CodeQL が使われています。 また、サード パーティ製のワークフロー テンプレートも利用できます。\n\n詳細については、「[コード スキャンについて](/ja/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning)」および「[コード スキャンの詳細設定を構成する](/ja/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning#configuring-code-scanning-using-third-party-actions)」を参照してください。\n\n#### トークンのアクセス許可を制限する\n\n公開されたトークンのリスクを軽減するには、割り当てられるアクセス許可を制限することを検討します。 詳しくは、「[ワークフローでの認証に GITHUB\\_TOKEN を使用する](/ja/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token)」をご覧ください。\n\n## サードパーティアクションを使用する\n\nワークフロー内の個々のジョブは、他のジョブと相互作用（および侵害）する場合があります。 たとえば、後のジョブで使用される環境変数をクエリするジョブ、後のジョブが処理する共有ディレクトリにファイルを書き込むジョブ、あるいはもっと直接的にDocker ソケットとやり取りして他の実行中のコンテナを検査してコマンドを実行するジョブなどです。\n\nつまり、ワークフロー内の 1 つのアクションが侵害されると、その侵害されたアクションがリポジトリで構成されているすべてのシークレットにアクセスでき、`GITHUB_TOKEN` を使ってリポジトリに書き込むことができる場合があるため、非常に大きな問題になる可能性があります。 したがって、GitHub のサードパーティリポジトリからアクションを調達することには大きなリスクがあります。 攻撃者が行う可能性があるステップの一部については、「[セキュリティで保護された使用に関するリファレンス](/ja/actions/security-guides/security-hardening-for-github-actions#potential-impact-of-a-compromised-runner)」を参照してください。\n\n次のような適切な方法に従うことで、このリスクを軽減することができます。\n\n* **アクションを完全な長さのコミット SHA にピン止めする**\n\n  現在、アクションを不変のリリースとして使う唯一の方法は、アクションを完全なコミット SHA にピン留めすることです。 特定の SHA にピン止めすると、有効な Git オブジェクトペイロードに対して SHA-1 衝突を生成する必要があるため、悪意のある人がアクションのリポジトリにバックドアを追加するリスクを軽減できます。 SHA を選択するときは、アクションのリポジトリからであり、リポジトリ フォークではないことを確認してください。\n\n  ワークフローで完全なコミット SHA を使う例については、「[ワークフローで事前に作成されたビルディング ブロックを使用する](/ja/actions/how-tos/write-workflows/choose-what-workflows-do/find-and-customize-actions#using-shas)」を参照してください。\n\n  GitHub は、アクションを完全なコミット SHA にピン留めすることを要求するポリシーを、リポジトリとオーガニゼーションレベルで提供しています。\n\n  * リポジトリ レベルでポリシーを構成するには、「[リポジトリのGitHub Actions設定の管理](/ja/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#managing-github-actions-permissions-for-your-repository)」を参照してください。\n  * Organization レベルでポリシーを構成するには、「[組織のGitHub Actionsの無効化または制限](/ja/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization)」を参照してください。\n\n* **アクションのソース コードを監査する**\n\n  アクションが想定どおりにリポジトリとシークレットのコンテンツを処理していることを確認します。 たとえば、シークレットが意図しないホストに送信されていないか、または誤ってログに記録されていないかを確認します。\n\n* **作成者を信頼できる場合に限り、アクションをタグにピン止めする**\n\n  コミット SHA に対するピン止めが最も安全なオプションですが、タグを指定する方が便利で広く使用されています。 タグを指定する場合は、アクションの作成者が信頼できることを確認してください。 GitHub Marketplace の「Verified creator」バッジは便利な判断材料で、 GitHub で身元が確認されたチームによって作成されたアクションであることを示しています。 作者が信頼できる場合でも、このアプローチにはリスクがあることに注意してください。悪意のある人がアクションを保存しているリポジトリにアクセスすると、タグが移動または削除される可能性があります。\n\n### サード パーティのワークフローを再利用する\n\nサード パーティのアクションの使用に関して上で説明したものと同じ原則が、サード パーティのワークフローの使用にも適用されます。 上と同じ適切なプラクティスに従うことで、ワークフローの再利用に関連するリスクを軽減できます。 詳しくは、「[ワークフローを再利用する](/ja/actions/using-workflows/reusing-workflows)」をご覧ください。\n\n## GitHub のセキュリティ機能\n\nGitHubには、コードのセキュリティを強化する多くの機能が用意されています。 GitHubのビルトイン機能を使用し、ワークフローが依存するアクションの理解、実行するアクションの脆弱性に関する通知を受け取れるようにし、ワークフロー内のアクションを最新の状態に保つプロセスを自動化できます。 アクションを公開して維持した場合、GitHubを使用して脆弱性とその修正方法についてコミュニティとコミュニケーションが取れます。 GitHubが提供するセキュリティ機能の詳細については、「[GitHubセキュリティ機能](/ja/code-security/getting-started/github-security-features#about-githubs-security-features)」を参照してください。\n\n###\n\n```\n          `CODEOWNERS` を使用して変更を監視する\n\n          `CODEOWNERS` 機能を使って、ワークフロー ファイルの変更方法を制御できます。 たとえば、すべてのワークフロー ファイルが `.github/workflows` に格納されている場合、このディレクトリをコード所有者リストに追加すると、これらのファイルへの変更案には、まず指定されたレビュー担当者による承認が必要になります。\n```\n\n詳しくは、「[コードオーナーについて](/ja/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)」をご覧ください。\n\n### OpenID Connect を使用してクラウド リソースにアクセスする\n\nGitHub Actions ワークフローが OpenID Connect (OIDC) をサポートするクラウド プロバイダーのリソースにアクセスする必要がある場合、そのクラウド プロバイダーで直接認証されるようにワークフローを構成できます。 これにより、有効期間の長いシークレットとしてこれらの資格情報の格納を停止し、その他のセキュリティ上の利点を提供できます。 詳しくは、「[OpenID Connect](/ja/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)」をご覧ください。\n\n> \\[!NOTE]\n> OIDC のカスタム要求のサポートは、AWS では使用できません。\n\n### Dependabot version updates を使用してアクションを最新の状態に維持する\n\nリポジトリで使用されるアクションおよび再利用可能なワークフローのリファレンスを常に最新の状態に保つため、Dependabotを使用できます。 多くの場合、アクションはバグ修正および新しい機能で更新され、自動化プロセスの速度、安全性、信頼性が向上しています。 Dependabotは、依存関係の保守を自動的に実行するため、作業量が軽減されます。 詳細については、「[Dependabot でアクションを最新に保つ](/ja/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot)」および「[Dependabot のセキュリティ アップデート](/ja/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)」を参照してください。\n\n### GitHub Actions による pull request の作成または承認を回避する\n\nGitHub Actions ワークフローでの pull request の作成または承認を許可するか禁止するかを選択できます。 ワークフローまたは他のオートメーションが pull request を作成または承認できるようにすると、pull request のマージが適切な監視なしで行われる場合、セキュリティ リスクが発生する可能性があります。\n\nこの設定を構成する方法の詳細については、「[Organization の GitHub Actions の無効化または制限](/ja/github/setting-up-and-managing-organizations-and-teams/disabling-or-limiting-github-actions-for-your-organization#preventing-github-actions-from-creating-or-approving-pull-requests)」、「[リポジトリのGitHub Actions設定の管理](/ja/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests)」を参照してください。\n\n### code scanning を使用してワークフローをセキュリティで保護する\n\nCode scanning は、GitHub Actions ワークフローで使われる一般的な脆弱なパターンを自動的に検出し、改善を提案します。\ncode scanning を有効にする方法の詳細については、「[コード スキャンの既定セットアップの構成](/ja/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning)」を参照してください。\n\n### OpenSSF Scorecards を使ってワークフローの依存関係をセキュリティで保護する\n\n```\n          [Scorecards](https://github.com/ossf/scorecard) は、リスクの高いサプライ チェーン プラクティスにフラグを設定する自動セキュリティ ツールです。 \n          [Scorecards アクション](https://github.com/marketplace/actions/ossf-scorecard-action)と[ワークフロー テンプレート](https://github.com/actions/starter-workflows)を使って、セキュリティのベスト プラクティスに従うことができます。 構成された Scorecards アクションは、リポジトリが変更されると自動的に実行され、ビルトイン code scanning 環境を使用してリスクの高いサプライ チェーン プラクティスについて開発者に警告します。 Scorecards プロジェクトでは、スクリプト インジェクション攻撃、トークンのアクセス許可、ピン留めされたアクションなど、さまざまなチェックが実行されます。\n```\n\n### GitHub を扱うホストランナー\n\nGitHub ホストランナーは、セキュリティ リスクの軽減に役立つ対策を講じます。\n\n#### GitHub ホストランナーのサプライチェーンを見直す\n\nGitHub でホストされているランナーが GitHub によってメンテナンスされているイメージから作成された場合、ソフトウェア部品表 (SBOM) を表示して、ランナーにプリインストールされたソフトウェアを確認できます。 脆弱性スキャナーを介して実行できる SBOM をユーザーに提供して、製品に脆弱性があるかどうかを検証できます。 あなたが成果物をビルドする際には、このSBOMを部品表に含めることができれば、ソフトウェアの作成過程に必要なすべてを網羅した包括的なリストになります。\n\nGitHub によって保持される Ubuntu、Windows、および macOS ランナー イメージに対して、SBOM を使用できます。 ビルドの SBOM は、 <https://github.com/actions/runner-images/releases> に記載されているリリース資産で見つけることができます。\n`sbom.IMAGE-NAME.json.zip` の形式のファイル名を持つ SBOM は、各リリースの添付ファイルにあります。\n\nARM 搭載ランナーのイメージなど、サード パーティ製のイメージの場合は、[`actions/partner-runner-images` リポジトリ](https://github.com/actions/partner-runner-images)内のイメージに含まれているソフトウェアの詳細を確認できます。\n\n#### ホストへのアクセスを拒否する\n\nGitHub ホストランナーは、さまざまな暗号化マイニング プールや悪意のあるサイトへのネットワーク アクセスをブロックする `etc/hosts` ファイルでプロビジョニングされます。 MiningMadness.com や cpu-pool.com などのホストは、重大なセキュリティ リスクが存在しないように localhost に再ルーティングされます。 詳細については、「[GitHub ホステッド ランナー](/ja/actions/using-github-hosted-runners/about-github-hosted-runners)」を参照してください。\n\n### セルフホストランナーを強化する\n\n**GitHub のホストされた** ランナーは、一時的でクリーンな隔離された仮想マシン内でコードを実行します。したがって、この環境を永続的に損なう方法はなく、ブートストラッププロセスの間にこの環境に置かれたもの以外の情報にアクセスすることはできません。\n\nGitHub の**セルフホステッド** ランナーは、一時的でクリーンな仮想マシンでの実行に関する保証がなく、ワークフロー内の信頼されていないコードによって永続的に侵害される可能性があります。\n\nその結果、任意のユーザーがリポジトリに対して pull request を開き、環境を侵害できるため、ほとんどの場合、セルフホステッド ランナーは GitHub の[パブリック リポジトリには使わない](/ja/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions)ようにする必要があります。 同様に、プライベートまたは内部リポジトリでセルフホステッド ランナーを使うときは注意が必要です。リポジトリをフォークして pull request (プル リクエスト) を開くことができるユーザー (通常は、リポジトリへの読み取りアクセス権を持つユーザー) は、セルフホステッド ランナー環境を侵害できます。それには、シークレットへのアクセスや、リポジトリへの書き込みアクセス権を設定に応じて付与できる `GITHUB_TOKEN` の取得が含まれます。 ワークフローは、環境と必要なレビューを使用して環境シークレットへのアクセスを制御できますが、これらのワークフローは分離された環境では実行されず、セルフホストランナーで実行した場合でも同じリスクの影響を受けやすくなります。\n\nOrganization の所有者は、リポジトリ レベルのセルフホステッド ランナーの作成を許可するリポジトリを選択できます。\n\n詳細については、「[組織のGitHub Actionsの無効化または制限](/ja/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#limiting-the-use-of-self-hosted-runners)」を参照してください。\n\nセルフホステッド ランナーが organization または Enterprise のレベルで定義されている場合、GitHub は同じランナーに対して複数のリポジトリからのワークフローをスケジュールできます。 したがって、これらの環境へのセキュリティ侵害は、大きな影響をもたらす可能性があります。 侵害の範囲を狭めるために、セルフホストランナーを個別のグループにまとめることで、境界を作ることができます。 ランナー グループにアクセスできる組織、リポジトリを制限できます。 詳しくは、「[グループを使用してセルフホストランナーへのアクセスを管理する](/ja/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups)」をご覧ください。\n\n次のように、セルフホストランナーマシンの環境も考慮する必要があります。\n\n* セルフホストランナーとして設定されたマシンにはどのような機密情報が存在するか。 たとえば、SSH 秘密鍵、API アクセストークンなどです。\n* マシンが機密性の高いサービスにネットワークアクセス可能か。 たとえば、Azureや AWS メタデータ サービスなどです。 この環境での機密情報量は最小限に抑える必要があります。ワークフローを呼び出すことができるすべてのユーザがこの環境にアクセスできることを常に意識しておいてください。\n\n中には、それぞれのジョブの実行後にセルフホストランナーを自動的に破棄するようなシステムを実装することで、このリスクを部分的に軽減しようとするお客様もいます。 しかし、このアプローチは意図したほどには効果的ではないかもしれません。これは、セルフホストランナーが1つのジョブだけを実行するという保証がないためです。 一部のジョブでは、コマンド ライン引数としてシークレットが使われ、同じランナーで実行している別のジョブで見ることができます (`ps x -w` など)。 これにより、シークレットが漏えいする可能性があります。\n\n#### ジャストインタイムランナーの使用\n\nランナー登録のセキュリティを向上させるために、REST API を使ってエフェメラル Just-In-Time (JIT) ランナーを作成できます。 これらのセルフホステッド ランナーは、リポジトリ、組織、またはエンタープライズから自動的に削除される前に、最大 1 つのジョブを実行します。 JIT ランナーの構成の詳細については、「[セルフホステッド ランナーの REST API エンドポイント](/ja/rest/actions/self-hosted-runners#create-configuration-for-a-just-in-time-runner-for-an-organization)」を参照してください。\n\n> \\[!NOTE]\n> ハードウェアを再利用して JIT ランナーをホストすると、環境から情報が公開されるリスクがあります。 自動化を利用して、JIT ランナーが確実にクリーンな環境を使用するようにしてください。 詳しくは、「[セルフホステッド ランナー リファレンス](/ja/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners#using-ephemeral-runners-for-autoscaling)」をご覧ください。\n\nREST API の応答から構成ファイルを作成したら、ランナーに起動時に渡すことができます。\n\n```shell\n./run.sh --jitconfig ${encoded_jit_config}\n```\n\n#### セルフホステッドランナーの管理戦略を計画する\n\nセルフホステッド ランナーは、GitHub 階層のさまざまなレベル (Enterprise、Organization、リポジトリ レベル) に追加できます。 この配置により、ランナーを管理できるユーザーが決まります。\n\n```\n          **一元管理:**\n```\n\n* 一元化されたチームでセルフホステッド ランナーを所有する場合は、最も高い相互 Organization または Enterprise レベルにランナーを追加することをお勧めします。 これにより、チームは 1 つの場所でランナーを表示および管理できます。\n\n* Organization が 1 つだけの場合、Organization レベルでランナーを追加するのは実質的に同じ方法ですが、将来別の Organization を追加したときに問題が発生する可能性があります。\n\n  ```\n          **分散管理:**\n  ```\n\n* 各チームが自分のセルフホステッド ランナーを管理する場合は、チームの所有権の最上位レベルでランナーを追加することをお勧めします。 たとえば、各チームが自分の Organization を所有している場合は、ランナーも Organization レベルで追加すると最も簡単になります。\n\n* リポジトリ レベルでランナーを追加することもできますが、リポジトリ間ではランナーを共有できないため、管理オーバーヘッドが増加し、必要なランナーの数も増えます。\n\n#### クラウド プロバイダーへの認証を行う\n\nGitHub Actions を使ってクラウド プロバイダーにデプロイする場合、またはシークレット管理に HashiCorp Vault を使う場合は、OpenID Connect を使って、ワークフロー実行用に有効期間が短く、適切なスコープ設定のアクセス トークンの作成を検討することをお勧めします。 詳しくは、「[OpenID Connect](/ja/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)」をご覧ください。\n\n### GitHub Actionsイベントの監査\n\nセキュリティ ログを使用してユーザー アカウントのアクティビティを監視し、監査ログを使用して組織のアクティビティを監視できます。 セキュリティおよび監査ログには、アクションの種類、実行された日時、アクションを実行した個人アカウントが記録されます。\n\nたとえば、監査ログを使って、Organization のシークレットへの変更を追跡する `org.update_actions_secret` イベントを追跡できます。\n\n![組織の監査ログからの \"action:org.update\\_actions\\_secret\" の検索を示すスクリーンショット。 2 つの結果が表示されます。](/assets/images/help/repository/audit-log-entries.png)\n\n各アカウントの種類の監査ログに表示されるイベントの完全な一覧については、次の記事を参照してください。\n\n* [セキュリティ ログのイベント](/ja/authentication/keeping-your-account-and-data-secure/security-log-events)\n* 「[Organization の監査ログ イベント](/ja/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization)」\n\n### ワークフローの依存関係について理解する\n\n依存関係グラフを使用し、リポジトリのワークフローが使用するアクションを調べることができます。 依存関係グラフは、リポジトリに保存されたマニフェストとロック ファイルの概要です。 また、`./github/workflows/` 内のファイルもマニフェストとして認識されます。つまり、構文 `jobs[*].steps[*].uses` または `jobs.<job_id>.uses` を使って参照されるすべてのアクションまたはワークフローは、依存関係として解析されます。\n\n依存関係グラフには、ワークフローで使用されるアクションに関する次の情報が表示されます。\n\n* アクションを所有するアカウントまたは組織。\n* アクションを参照するワークフロー ファイル。\n* アクションの固定先であるバージョンまたはSHA。\n\n依存関係グラフでは、依存関係は脆弱性の重大度によって自動的に並べ替えられます。 使用するいずれかのアクションにセキュリティ アドバイザリがある場合、リストの上部に表示されます。 依存関係グラフからアドバイザリに移動し、脆弱性を解決する手順にアクセスできます。\n\n依存関係グラフはパブリック リポジトリに対して有効にされ、プライベート リポジトリに有効にすることができます。 依存関係グラフの使用方法の詳細については、「[リポジトリの依存関係を調べる](/ja/code-security/supply-chain-security/understanding-your-software-supply-chain/exploring-the-dependencies-of-a-repository)」を参照してください。\n\n### 使用するアクションのセキュリティ脆弱性を認識する\n\nマーケットプレースで利用可能なアクションの場合、GitHubは関連するセキュリティ アドバイザリを確認し、それらのアドバイザリをGitHub Advisory Databaseに追加します。 データベースを検索して既存の脆弱性に関する情報とその修正方法の手順を見つけるため、使用するアクションを調べることができます。 検索を効率化するには、[GitHub Actions](https://github.com/advisories?query=type%3Areviewed+ecosystem%3Aactions)でGitHub Advisory Databaseフィルターを使用します。\n\n次のことができるようにリポジトリを設定できます。\n\n* ワークフローで使用されるアクションが脆弱性レポートを受け取ったときにアラートを受信します。 詳細については、「[ワークフローのアクションを監視する](#monitoring-the-actions-in-your-workflows)」を参照してください。\n* ワークフローでアクションを追加または更新すると、既存のアドバイザリに関する警告が表示されます。 詳細については、「[新規または更新されたワークフローで脆弱性に対するアクションのスクリーニング](#screening-actions-for-vulnerabilities-in-new-or-updated-workflows)」を参照してください。\n\n#### ワークフローでアクションを監視する\n\nDependabotを使用してワークフローのアクションを監視し、Dependabot alertsを有効にして使用するアクションに報告された脆弱性があるときに通知されるようにすることができます。 Dependabotは、有効にしたリポジトリの既定のブランチにスキャンを実行し、不安定な依存関係を検知します。 Dependabotは、新しいアドバイザリがDependabot alertsに追加されるか、使用するアクションが更新された場合、GitHub Advisory Databaseを生成します。\n\n> \\[!NOTE]\n> Dependabot は、セマンティック バージョニングを使用する脆弱なアクションのアラートのみを作成し、SHA 値にピン留めされたアクションのアラートを作成しません。\n\n個人用アカウント用、リポジトリ用、組織用にDependabot alertsを有効にできます。 詳細については、「[Dependabot アラートの構成](/ja/code-security/dependabot/dependabot-alerts/configuring-dependabot-alerts)」を参照してください。\n\nリポジトリの \\[Dependabot alerts] タブで、開いているDependabot security updatesと閉じているすべてのDependabotを表示できます。詳細については、「[Dependabot アラートの表示と更新](/ja/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts)」を参照してください。\n\n#### 新しいワークフローまたは更新されたワークフローの脆弱性のスクリーニング アクション\n\nPull request を開いてワークフローを更新するとき、使用するアクションに加えた変更のセキュリティ上の影響を理解するため、依存関係レビューの使用をお勧めします。 依存関係レビューを使うと、すべてのPull Reqeustにおける以下の変更による依存関係の変化とセキュリティについての影響を理解しやすくなります。pull request の \\[Files Changed]\\(変更されたファイル) タブ上のリッチ diff で依存関係の変更をわかりやすく視覚化できます。 依存関係レビューは、以下のことを知らせます:\n\n* リリース日と合わせて、追加、削除、更新された依存関係\n* これらのコンポーネントを使うプロジェクトの数\n* これらの依存関係に関する脆弱性のデータ\n\nワークフローに加えた変更に脆弱性のフラグが付けられている場合、プロジェクトに追加することを回避するか、セキュリティで保護されたバージョンに更新することができます。\n\n依存関係レビューの詳細については、「[依存関係の確認について](/ja/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review)」を参照してください。\n\n\"依存関係レビュー アクション\" とは、GitHub Actions コンテキスト内の pull request の差異を報告できる特定のアクションです。 以下を参照してください。[`dependency-review-action`](https://github.com/actions/dependency-review-action) リポジトリで 依存関係レビュー アクション を使って、pull request に依存関係レビューを適用できます。 このアクションは、pull request のパッケージ バージョンの変更によって発生した依存関係の脆弱なバージョンをスキャンし、関連するセキュリティの脆弱性について警告します。 これにより、pull request で何が変更されているかをより正確に把握でき、リポジトリに脆弱性が追加されるのを防ぐことができます。 詳細については、「[依存関係の確認について](/ja/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#about-the-dependency-review-action)」を参照してください。\n\n### ワークフローのアクションをセキュリティで保護して最新の状態に維持\n\nリポジトリで使用されるアクションおよび再利用可能なワークフローのリファレンスを常に最新の状態に保つため、Dependabotを使用できます。 多くの場合、アクションはバグ修正および新しい機能で更新され、自動化プロセスの速度、安全性、信頼性が向上しています。 Dependabotは、依存関係の保守を自動的に実行するため、作業量が軽減されます。 詳細については、「[Dependabot でアクションを最新に保つ](/ja/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot)」および「[Dependabot のセキュリティ アップデート](/ja/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)」を参照してください。\n\n次の機能を使用すると、ワークフローのアクションを自動的に更新できます。\n\n* **Dependabot version updates** 新しいバージョンがリリースされたときに pull request を開いてアクションを最新バージョンに更新します。\n* **Dependabot security updates** Pull request を開き、報告された脆弱性があるアクションを最小のパッチ バージョンに更新します。\n\n> \\[!NOTE]\n>\n> * Dependabot では、GitHub Actions リポジトリ構文 (`GitHub` や `actions/checkout@<commit>` など) を使用した actions/checkout\\@v6 の更新のみがサポートされます。 Dependabot は、ローカルで参照されているアクションまたは再利用可能なワークフロー (たとえば、`./.github/actions/foo.yml`) を無視します。\n> * Dependabot は、コメントが同じ行 ( `actions/checkout@<commit> #<tag or link>` や `actions/checkout@<tag> #<tag or link>`など) にある場合に、GitHub Actions のバージョン ドキュメントを更新します。\n> * 使用するコミットがどのタグにも関連付けられていない場合、Dependabot は GitHub Actions を最新のコミットに更新します（これが最新のリリースとは異なる場合があります）。\n> * Docker Hub と GitHub Packages Container registry URL は現在、サポートされていません。 たとえば、`docker://` 構文を使用した Docker コンテナー アクションへの参照はサポートされていません。\n> * Dependabot では、GitHub Actions のパブリック リポジトリとプライベート リポジトリの両方がサポートされます。 プライベート レジストリ構成オプションについては、「`git`」の「[](/ja/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#git)」を参照してください。\n\nDependabot version updates を構成する方法の詳細については、「[Dependabot バージョンの更新の構成](/ja/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates)」を参照してください。\n\nDependabot security updates を構成する方法の詳細については、「[Dependabot セキュリティの更新の構成](/ja/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates)」を参照してください。\n\n### 作成したアクションの保護\n\nGitHub を使うと、アクションを公開して保守する担当者と脆弱性の報告者とのコラボレーションが可能になり、安全なコーディングを促進できます。 リポジトリ セキュリティ アドバイザリを使用すると、パブリック リポジトリのメンテナーは、プロジェクト内のセキュリティの脆弱性について非公開で話し合い、修正することができます。 共同で修正を行った後、リポジトリ保守担当者はセキュリティ アドバイザリを公開して、セキュリティの脆弱性をプロジェクトのコミュニティに開示することができます。 セキュリティ アドバイザリを公開することにより、リポジトリ保守担当者は、コミュニティがいっそう簡単にパッケージの依存関係を更新したり、セキュリティの脆弱性の影響を調べたりできるようにします。\n\nその他のプロジェクトで使用するアクションを保持しているユーザーの場合、次のGitHub機能を使用して公開したアクションのセキュリティを強化できます。\n\n* 依存関係グラフの依存ビューを使用し、どのプロジェクトがコードに依存するか確認します。 脆弱性レポートを受信した場合、脆弱性とその修正方法について誰に連絡する必要があるかについて検討ができます。 詳しくは、「[リポジトリの依存関係を調べる](/ja/code-security/supply-chain-security/understanding-your-software-supply-chain/exploring-the-dependencies-of-a-repository#dependents-view)」をご覧ください。\n* リポジトリのセキュリティ アドバイザリを使用してセキュリティ アドバイザリを作成し、プライベートで共同作業をして一時的な個人用フォークの脆弱性を修正し、セキュリティ アドバイザリを公開してパッチがリリースされた後にコミュニティに対して脆弱性を警告します。 詳細については、「[リポジトリのプライベート脆弱性レポートの構成](/ja/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository)」および「[リポジトリ セキュリティ アドバイザリの作成](/ja/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory)」を参照してください。"}