Translated ['src/pentesting-ci-cd/argocd-security.md', 'src/pentesting-c

src/pentesting-ci-cd/argocd-security.md

@@ -0,0 +1,219 @@
+# Argo CD Security
+
+{{#include ../banners/hacktricks-training.md}}
+
+## 基本情報
+
+[Argo CD](https://argo-cd.readthedocs.io/) は、Kubernetes 向けの GitOps 継続的デリバリープラットフォームです。Git リポジトリを監視し、Helm、Kustomize、Jsonnet、または config management plugins などのツールで Kubernetes manifests をレンダリングし、Git に保存された desired state と live cluster state を照合します。
+
+攻撃者の視点では、Argo CD は Kubernetes credentials を持つ **deployment engine** として扱ってください。Argo CD の有効な compromise は、次のような結果につながる可能性があります。
+
+- Private Git repositories と repository credentials へのアクセス。
+- Argo CD が使用する Kubernetes cluster secrets へのアクセス。
+- `argocd-repo-server` における manifest generation code execution。
+- trusted Git repositories、Argo CD applications、または cache manipulation を通じた unauthorized な Kubernetes object deployment。
+
+## Architecture & Interesting Components
+
+一般的な Kubernetes objects と services:
+```bash
+kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd'
+kubectl get applications,appprojects,applicationsets -A 2>/dev/null
+kubectl get secrets,configmaps -n argocd 2>/dev/null
+kubectl get networkpolicy -n argocd 2>/dev/null
+```
+興味深いサービス:
+
+- **`argocd-server`**: public API、web UI、CLI API、authentication と authorization。
+- **`argocd-application-controller`**: desired state と live state を比較し、その後 Kubernetes に resources を適用する。
+- **`argocd-repo-server`**: repositories を clone し、Git data を cache し、Helm/Kustomize/Jsonnet/plugins を実行して manifests を生成する。デフォルトの gRPC port は **8081**。
+- **`argocd-redis`**: application、manifest、Git reference data の cache。デフォルトの Redis port は **6379**。
+- **`argocd-applicationset-controller`**: Git、SCM、clusters、pull requests などの generators から Argo CD `Application` objects を生成する。
+
+compromised pod または internal network segment から、internal reachability を確認する:
+```bash
+nc -vz <argocd-server> 443
+nc -vz <argocd-repo-server> 8081
+nc -vz <argocd-redis> 6379
+```
+## Public API / UI Attacks
+
+Argo CDのcredentialsまたは公開されたinstanceがあるなら、通常のAPI surfaceから始める:
+```bash
+argocd login <argocd-server>
+argocd account get-user-info
+argocd account list
+argocd proj list
+argocd app list
+argocd repo list
+argocd cluster list
+argocd admin settings rbac can <subject> <action> <resource> <object>
+```
+有用なattack paths:
+
+- **Application write access**: `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings or sync optionsを変更して、Argo CDにattacker-controlled manifestsをdeployさせる。
+- **Project misconfiguration**: `AppProject` objectsは、広い `sourceRepos`、広い `destinations`、unsafeな `clusterResourceWhitelist`、または弱いnamespace restrictionsを許可できる。
+- **Repository credential abuse**: repository secrets、GitHub App credentials、SSH keys、tokensにより、trusted reposへのpushやmalicious dependenciesの追加が可能になる。
+- **Cluster credential abuse**: cluster secretsには、Argo CDがtarget clustersへdeployするために使うbearer tokensやexec-provider configurationが含まれている場合がある。
+- **Local admin / project tokens**: 長寿命のArgo CD tokensは、revokeされるか期限切れになるまでAPI経由で再利用できる。
+
+cluster read accessがある場合は、Kubernetesからconfigurationを列挙する:
+```bash
+kubectl get applications.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey'
+kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml
+```
+## Trusted Git Repository Abuse
+
+Argo CD が信頼している repository に push できる場合、通常は何がデプロイされるかに影響を与えられます。影響は `AppProject` の境界と、application controller が使う service account の権限に依存します。
+
+一般的な payload の場所:
+
+- application path 配下の生の Kubernetes YAML。
+- Helm chart templates と `values.yaml`。
+- Kustomize overlays、remote bases、generators。
+- Jsonnet または config management plugin の入力。
+- `Application` objects を作成または更新する ApplicationSet generator files。
+
+app が automated sync、pruning、self-heal、sync windows、または manual approvals を使っているか確認します:
+```bash
+kubectl get applications.argoproj.io -A \
+-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server'
+```
+## `argocd-repo-server` の直接的な悪用
+
+公開されている Argo CD API だけが attack surface だと仮定しないでください。内部の Argo CD コンポーネントは `argocd-repo-server` と gRPC 経由で通信します。任意の pod が repo-server に到達できる場合、攻撃者が制御する内部リクエストによって、通常 `argocd-server` によって強制されるチェックを bypass できる可能性があります。
+
+実践的な確認事項:
+```bash
+kubectl get svc -n argocd argocd-repo-server -o yaml
+kubectl get endpoints -n argocd argocd-repo-server -o wide
+nc -vz <argocd-repo-server> 8081
+```
+興味深い兆候:
+
+- repo-server の gRPC endpoint が非 Argo CD pod から到達可能。
+- NetworkPolicies が欠落しているか、deny ingress なしで allow-list egress のみになっている。
+- repo-server が custom config management plugins、decryption tools、または複数 tenant の repository content にアクセスできる。
+- Redis が非 Argo CD pod から到達可能で、credentials が利用可能、または不要な場合に cache の inspection や tampering ができる。
+
+## Kustomize Options 経由の Unauthenticated Repo-Server RCE
+
+2026年7月、Synacktiv は、攻撃者が内部 gRPC service に到達できる場合の Argo CD の `repo-server` における unauthenticated code execution chain を公開した。攻撃は、`/repository.RepoServerService/GenerateManifest` への direct access と、攻撃者制御の `KustomizeOptions` を悪用する。
+
+危険な primitive は、repo-server に攻撃者制御の repository content を clone させ、Helm support 付きで Kustomize を実行させることだ:
+```bash
+kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
+```
+Helm processing をトリガーするために必要な最小の悪意ある Kustomize input:
+```yaml
+helmCharts:
+- name: pwn
+version: 0.0.1
+```
+なぜこれが動くのか:
+
+- `argocd-repo-server` は rendering の前に repository を clone する。
+- `--helm-command ./payload.sh` は cloned repository を基準に相対解決される。
+- attacker が rendered repository と Kustomize build options を制御できるなら、code execution に shell metacharacter injection は不要。
+
+Synacktiv の 2026年7月1日の disclosure 時点では、この issue には official fix も CVE もないと報告されていた。まずは network-exposure issue として扱うこと: exploitation には internal repo-server gRPC port への reachability が必要。
+
+## Redis Cache Poisoning to Deploy Manifests
+
+`argocd-repo-server` で code execution ができた後、または valid credentials を使って Redis に direct access した後は、Redis-backed cache entries を調べる。Argo CD は一般に gzip-compressed JSON values を保存する。
+
+興味深い key prefixes:
+```text
+mfst|...       # cached rendered manifests
+git-refs|...   # Git branch/ref to commit mappings
+app|...        # application resource/cache data
+cluster|...    # cluster cache information
+```
+Synacktiv によって説明された cache poisoning attack は、2 つの state を悪用します。
+
+1. 対象の `mfst|...` manifest cache entry を変更して、attacker-controlled な Kubernetes manifest を含める。
+2. 関連する `git-refs|...` mapping を変更して、Argo CD に branch が移動したと誤認させ、その後 cached revision に再度 reconcile させる。
+
+Impact:
+
+- Auto Sync が有効な場合、Argo CD は poisoned された cached manifest を自動的に apply する可能性があります。
+- Auto Sync が無い場合でも、ユーザーが application を手動で sync した際に payload が apply される可能性があります。
+- 最終的な impact は、target application の destination と、Argo CD に付与された Kubernetes permissions によって制限されます。
+
+## ApplicationSet Attacks
+
+ApplicationSet は特に sensitive です。なぜなら、generator output から `Application` objects を作成または更新するからです。
+
+Review:
+```bash
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+```
+興味深いパターン:
+
+- 攻撃者が書き込み可能なファイルを読み取る Git generators で、app names、paths、projects、destinations を制御できる。
+- public repositories の Pull request generators で、trusted されていない contributors が generated applications に影響を与えられる。
+- broad な destination clusters/namespaces を許可する template fields。
+- `sourceRepos: ["*"]` や broad な `destinations` を許可する AppProjects。
+- automated sync と pruning を継承する generated applications。
+
+## Post-Exploitation
+
+Argo CD pod shell からは、次を優先:
+```bash
+env
+cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
+find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null
+mount | grep -E 'secret|token|config'
+```
+Useful objectives:
+
+- `REDIS_PASSWORD` や Redis TLS/client material を盗む。
+- マウントされた secrets や Argo CD Kubernetes secrets から repository credentials を抽出する。
+- Argo CD が使用する cluster credentials を特定する。
+- 生成された manifests と、注入された secrets を含む可能性のある plugin output を読む。
+- custom plugins、SOPS、Helm secrets、Vault plugins、または cloud CLIs が decryption keys と cloud credentials を露出していないか確認する。
+
+## Detection & Hardening
+
+Important checks:
+
+- NetworkPolicies で `argocd-repo-server` の port **8081** と Redis port **6379** を制限し、想定された Argo CD components だけが到達できるようにする。
+- Helm deployments では、network policies が実際に作成されることを確認する。Argo CD Helm chart values は historically、component の network policy creation を disabled にしていた。
+- `argocd-server` を authenticated entry point として維持する。内部 services は任意の workloads から到達できてはいけない。
+- 未使用の config management tools と plugins を無効化する。
+- `AppProject` の `sourceRepos`、`destinations`、namespace permissions、cluster-scoped resources を制限する。
+- 低権限の Argo CD user が再利用を引き起こせるような広い repository credentials の保存を避ける。
+- repo-server requests、Kustomize build options、plugin executions、Redis writes、そして `mfst|` / `git-refs|` keys への予期しない access を監視する。
+- compromise 後は Argo CD local users、project tokens、repository credentials、cluster credentials を rotate する。
+
+Useful commands:
+```bash
+kubectl get networkpolicy -n argocd
+kubectl get networkpolicy -A | grep -i argocd
+kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null
+kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null
+```
+## CodeQL における Static Analysis Note: Typed API Requests
+
+Go services で gRPC/REST handlers を使う場合、raw input が typed request objects に unmarshal された後は、default の CodeQL remote sources では flow を見逃すことがあります。Argo CD-style の services に有用な model は次のとおりです:
+
+- `Server` や `Service` のような receiver type.
+- First parameter は `context.Context`.
+- Second parameter は typed request object.
+
+その second parameter を remote source として model し、`exec.Command` / `exec.CommandContext` の arguments に custom sinks を追加します。これにより、internal API request fields から command execution helpers への flow を見つけやすくなります。
+
+## References
+
+- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)
+- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
+- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
+- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
+- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
+- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
+- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
+- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS は **Version Control System** の略で、このシステムは開発者が **ソースコードを管理** することを可能にします。最も一般的なのは **git** で、通常は以下の **platforms** のいずれかで使われています。
+VCS は **Version Control System** の略で、このシステムは開発者が **source code を管理**することを可能にします。最も一般的なのは **git** で、通常は次の **platforms** のいずれかで企業が使っているのを見つけるでしょう。
 
 - Github
 - Gitlab
@@ -18,39 +18,39 @@ VCS は **Version Control System** の略で、このシステムは開発者が
 
 ## CI/CD Pipelines
 
-CI/CD pipelines は、開発者がビルド、テスト、デプロイなどのさまざまな目的で **コードの実行を自動化** できるようにします。これらの自動化されたワークフローは、コードの push、pull request、スケジュールされたタスクなどの特定のアクションによって **トリガー** されます。開発から本番までのプロセスを効率化するのに役立ちます。
+CI/CD pipelines により、開発者はビルド、テスト、アプリケーションのデプロイなど、さまざまな目的で **code の実行を自動化**できます。これらの自動化されたワークフローは、code の push、pull request、scheduled task などの特定のアクションによって **triggered** されます。開発から本番までのプロセスを効率化するのに役立ちます。
 
-ただし、これらのシステムは **どこかで実行** される必要があり、通常はコードをデプロイしたり機密情報へアクセスしたりするための **特権付き認証情報** を伴います。
+しかし、これらのシステムは **どこかで実行される必要があり**、通常は code のデプロイや機密情報へのアクセスのために **privileged credentials** が必要です。
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> 一部の VCS platforms ではこのセクション向けに pipeline を作成できますが、ここではソースコードの制御に対する潜在的な攻撃のみを分析します。
+> Some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
 
-プロジェクトのソースコードを含む platforms には機密情報が含まれており、この platform 内で付与される権限には細心の注意が必要です。以下は、攻撃者が悪用できる VCS platforms に共通する問題です。
+プロジェクトの source code を含む platform には機密情報が含まれており、この platform 内で付与される権限には非常に注意する必要があります。以下は、attacker が悪用できる可能性がある VCS platform に共通する問題です。
 
-- **Leaks**: コミット内のコードに leak が含まれていて、攻撃者が repo にアクセスできれば（公開されている、またはアクセス権を持っているため）、その leak を見つけられる可能性があります。
-- **Access**: 攻撃者が **VCS platform 内のアカウントにアクセス** できれば、**より多くの可視性と権限** を得られる可能性があります。
-- **Register**: 一部の platforms では外部ユーザーがアカウントを作成できるだけです。
-- **SSO**: 一部の platforms ではユーザー登録はできませんが、有効な SSO があれば誰でもアクセスできます（たとえば攻撃者は自身の github アカウントで入れる）。
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... repo に何らかの形でアクセスするためにユーザーが盗める token にはいくつかの種類があります。
-- **Webhooks**: VCS platforms は webhook を生成できます。非公開の secret で保護されていない場合、**攻撃者が悪用できる** 可能性があります。
-- secret が設定されていなければ、攻撃者は third party platform の webhook を悪用できます
-- secret が URL に含まれている場合も同様で、攻撃者は secret も入手してしまいます
-- **Code compromise:** 悪意ある攻撃者が repo に対して何らかの **write** アクセスを持っている場合、**悪意あるコードを注入** しようとするかもしれません。成功するために、**branch protections を回避** する必要がある場合があります。これらの行為は、さまざまな目的で実行され得ます。
-- main branch を侵害して **production を侵害** する。
-- main（または他の branches）を侵害して **developers machines を侵害** する（通常、彼らは自身の machine 上で repo 内の test、terraform、その他の処理を実行するため）。
-- **pipeline を侵害する**（次のセクションを参照）
+- **Leaks**: コミット内に code の leaks があり、attacker が repo にアクセスできる場合（公開されている、またはアクセス権があるため）、leaks を発見できる可能性があります。
+- **Access**: attacker が **VCS platform 内のアカウントに access できる**場合、**より多くの可視性と権限**を得られる可能性があります。
+- **Register**: 一部の platform は外部ユーザーによるアカウント作成をそのまま許可します。
+- **SSO**: 一部の platform はユーザー登録を許可しませんが、有効な SSO があれば誰でも access できるようにします（そのため attacker は例えば自身の github アカウントを使って侵入できます）。
+- **Credentials**: Username+Pwd、personal token、ssh key、Oauth token、cookie... repo に access するためにユーザーから steal されうる token はいくつもあります。
+- **Webhooks**: VCS platform は webhooks を生成できます。外から見えない secret で **保護されていない**場合、**attacker が悪用できる**可能性があります。
+- secret が設定されていなければ、attacker は third party platform の webhook を悪用できます
+- secret が URL に含まれている場合も同様で、attacker はその secret も入手できます
+- **Code compromise:** 悪意ある actor が repo に対して何らかの **write** access を持っている場合、**malicious code を注入**しようとする可能性があります。成功させるには、**branch protections を bypass** する必要があるかもしれません。これらの行為は、いくつかの目的で実行できます。
+- main branch を compromise して **production を compromise** する。
+- main（または他の branches）を compromise して **developers machines を compromise** する（通常、彼らは自身のマシン上で repo 内の test、terraform、その他の処理を実行するため）。
+- **pipeline を compromise する**（次の section を確認）
 
 ## Pipelines Pentesting Methodology
 
-pipeline を定義する最も一般的な方法は、pipeline がビルドする repository 内にホストされた **CI configuration file** を使うことです。この file は、実行される jobs の順序、フローに影響する条件、build environment settings を記述します。\
-これらの files は通常、Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI)、および .github/workflows 配下にある GitHub Actions の YAML files など、一貫した名前と形式を持ちます。トリガーされると、pipeline job は選択された source（例: commit / branch）から **code を取得** し、その code に対して CI configuration file で指定された **commands を実行** します。
+pipeline を定義する最も一般的な方法は、pipeline が build する repo にホストされた **CI configuration file** を使うことです。この file には、実行される job の順序、flow に影響する条件、build environment の設定が記述されています。\
+これらの file は通常、Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)、および .github/workflows 配下にある GitHub Actions の YAML file など、一定の name と format を持ちます。triggered されると、pipeline job は選択された source（例: commit / branch）から **code を pull** し、CI configuration file に指定された commands をその code に対して **実行**します。
 
-したがって、攻撃者の最終目標は、何らかの方法でそれらの **configuration files** またはそれらが実行する **commands** を **侵害** することです。
+したがって、attacker の最終目標は、何らかの方法で **それらの configuration file を compromise すること**、または **それらが実行する commands を compromise すること**です。
 
 > [!TIP]
-> 一部の hosted builders では、contributors が Docker build context と Dockerfile path を選択できます。context が attacker-controlled なら、build 中に host files を取り込んで secrets を exfiltrate するために repo 外（例: ".."）を指定できます。参照:
+> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,72 +58,73 @@ pipeline を定義する最も一般的な方法は、pipeline がビルドす
 
 ### PPE - Poisoned Pipeline Execution
 
-Poisoned Pipeline Execution (PPE) path は、SCM repository 内の権限を悪用して CI pipeline を操作し、害のある commands を実行します。必要な権限を持つ users は、CI configuration files や pipeline job が使用する他の files を変更して malicious commands を含めることができます。これにより CI pipeline が「poison」され、これらの malicious commands が実行されます。
+Poisoned Pipeline Execution (PPE) は、SCM repository の permissions を悪用して CI pipeline を操作し、有害な commands を実行する path です。必要な permissions を持つユーザーは、CI configuration file や pipeline job で使われる他の file を変更して malicious commands を含めることができます。これにより CI pipeline が「poison」され、これらの malicious commands が実行されます。
 
-悪意ある actor が PPE attack を成功させるには、以下が必要です。
+attacker が PPE attack に成功するには、以下が必要です。
 
-- 通常、pipeline は push または pull request が行われたときにトリガーされるため、**VCS platform への write access** を持つこと。（アクセス方法の要約は VCS pentesting methodology を確認してください）。
-- 場合によっては **external PR が "write access" と見なされる** 点に注意してください。
-- write 権限があっても、**CI config file または config が依存している他の files を変更できる** ことを確認する必要があります。
-- そのために、**branch protections を回避** できる必要があるかもしれません。
+- 通常 pipeline は push や pull request が行われたときに triggered されるため、**VCS platform への write access** を持つこと。（access を得る方法の概要は VCS pentesting methodology を確認）
+- 場合によっては、**external PR が "write access" と見なされる**ことに注意。
+- write 権限があっても、**CI config file または config が依存する他の file を変更できる**ことを確認する必要があります。
+- そのために、**branch protections を bypass** できる必要があるかもしれません。
 
-PPE には 3 つの種類があります。
+PPE には 3 種類あります。
 
-- **D-PPE**: **Direct PPE** attack は、実行される **CI config** file を actor が **変更** したときに発生します。
-- **I-DDE**: **Indirect PPE** attack は、実行される **CI config** file が **依存している** **file**（make file や terraform config など）を actor が **変更** したときに発生します。
-- **Public PPE or 3PE**: 場合によっては、pipeline は repo への write access を持たない users（org の一員ですらない可能性がある）によってもトリガーされます。PR を送信できるためです。
-- **3PE Command Injection**: 通常、CI/CD pipelines は PR に関する **情報を含む environment variables** を **設定** します。その値が攻撃者によって制御可能で（たとえば PR の title など）、かつ **危険な場所**（**sh commands** の実行など）で **使用** される場合、攻撃者はそこに **commands を注入** できる可能性があります。
+- **D-PPE**: actor が実行される **CI config** file を **modifies** する場合に起こる **Direct PPE** attack。
+- **I-DDE**: actor が実行される **CI config file が依存している** **file** を **modifies** する場合に起こる **Indirect PPE** attack。（make file や terraform config など）
+- **Public PPE or 3PE**: 場合によっては、pipeline は repo に write access を持たないユーザー（org の一員でさえない可能性がある）によっても **triggered** されます。PR を送信できるからです。
+- **3PE Command Injection**: 通常、CI/CD pipelines は PR に関する **情報を持つ environment variables** を **set** します。その値が attacker によって制御可能で（PR の title など）、かつ **dangerous place**（**sh commands** の実行など）で **used** される場合、attacker はそこに commands を **inject** できる可能性があります。
 
 ### Exploitation Benefits
 
-pipeline を poison する 3 つの種類を理解したら、攻撃者が成功した exploitation の後に何を得られるかを見ていきます。
+pipeline を poison する 3 つの種類を理解したところで、成功した exploitation の後に attacker が何を得られるかを確認しましょう。
 
-- **Secrets**: 前述のとおり、pipelines の jobs には（code の取得、build、deploy などのための）**特権** が必要であり、この特権は通常 **secrets により付与** されます。これらの secrets は通常、**env variables** や system 内の files 経由でアクセスできます。したがって攻撃者は、常にできるだけ多くの secrets を exfiltrate しようとします。
-- pipeline platform によっては、攻撃者が **config に secrets を指定** する必要がある場合があります。これは、攻撃者が CI configuration pipeline（たとえば **I-PPE**）を変更できない場合、**その pipeline が持つ secrets だけを exfiltrate できる** ことを意味します。
-- **Computation**: code はどこかで実行されるため、実行場所によっては攻撃者がさらに pivot できる可能性があります。
-- **On-Premises**: pipelines が on premises で実行される場合、攻撃者は **より多くの resources にアクセスできる内部 network** に到達する可能性があります。
-- **Cloud**: 攻撃者は **他の cloud 上の machines** にアクセスできるだけでなく、そこで IAM roles/service accounts **tokens** を exfiltrate して、cloud 内のさらなる access を得られる可能性があります。
-- **Platforms machine**: 場合によっては jobs が **pipelines platform machines** 内で実行されますが、通常は cloud 内にあり、**それ以上の access はありません**。
-- **Select it:** 場合によっては、**pipelines platform が複数の machines を構成している** ことがあり、CI configuration file を **変更できる** なら、悪意ある code をどこで実行するかを **指定** できます。この状況では、攻撃者はおそらく可能な各 machine 上で reverse shell を実行し、さらに exploitation を試みます。
-- **Compromise production**: あなたが pipeline 内にいて、最終版がそこから build され deploy されるなら、本番環境で実行される code を **侵害** できる可能性があります。
+- **Secrets**: 先述のとおり、pipeline の job には **privileges** が必要です（code の取得、build、deploy など）。これらの privileges は通常 **secrets に格納**されています。これらの secrets は通常、**env variables や system 内の file** からアクセスできます。そのため attacker は常に、できるだけ多くの secrets を exfiltrate しようとします。
+- pipeline platform によっては、attacker が **config に secrets を指定する必要がある**場合があります。つまり、attacker が CI configuration pipeline（例えば **I-PPE**）を変更できない場合、その pipeline が持つ secrets だけを **exfiltrate** できるということです。
+- **Computation**: code はどこかで実行されます。どこで実行されるかによっては、attacker はさらに pivot できる可能性があります。
+- **On-Premises**: pipelines が on premises で実行されている場合、attacker は **より多くの resources に access できる internal network** に到達する可能性があります。
+- **Cloud**: attacker は **cloud 内の他の machine** に access できるだけでなく、そこから IAM roles/service accounts の **tokens を exfiltrate** して、cloud 内でさらに access を得られる可能性があります。
+- **Platforms machine**: job が **pipelines platform machines** 上で実行されることがあり、通常それらは cloud 内にあるものの、**それ以上の access はありません**。
+- **Select it:** 場合によっては **pipelines platform が複数の machine を設定**しており、CI configuration file を **modify** できるなら、悪意ある code をどこで実行するかを **指定**できます。この状況では attacker は、おそらく利用可能な各 machine で reverse shell を実行して、さらに exploit しようとするでしょう。
+- **Compromise production**: pipeline 内に入り、最終版がそこから build され deploy される場合、**production で最終的に実行される code を compromise** できます。
 
 ### Dependency & Registry Supply-Chain Abuse
 
-CI/CD pipeline を侵害したり、そこから認証情報を盗んだりすると、dependencies や release tooling を backdoor 化することで、攻撃者は **pipeline execution** から **ecosystem-wide code execution** へ移行できる可能性があります。
+CI/CD pipeline を compromise したり、そこから credentials を steal したりすると、dependencies や release tooling を backdoor することで、attacker は **pipeline execution** から **ecosystem-wide code execution** へ移行できます。
 
-- **Install-time code execution via package hooks**: `preinstall`, `postinstall`, `prepare` などの hook を追加した package version を公開し、dependency installation 中に developer workstations と CI runners の両方で payload が自動実行されるようにする。
-- **Secondary execution paths**: たとえ targets が `--ignore-scripts` で install しても、悪意ある package は `bin` field に **共通の CLI name** を登録できるため、攻撃者が制御する wrapper が `PATH` に symlink され、後でその command が使われたときに実行される。
-- **Runtime bootstrapping**: 小さな installer が installation 中に二次の runtime や toolchain をダウンロードし（たとえば Bun や packed interpreter）、それを使って main payload を起動することで、ローカルの dependency requirements を回避できる。
-- **Credential harvesting from build environments**: code が CI 内で実行されたら、environment variables、`~/.npmrc`、`~/.git-credentials`、SSH keys、cloud CLI configs、`gh auth token` のような local tooling を確認する。GitHub Actions では、runner-specific secrets や artifacts も確認する。
-- **Workflow injection with stolen GitHub tokens**: **`repo` + `workflow`** permissions を持つ token があれば、branch を作成し、`.github/workflows/` 内に malicious file を commit してそれを trigger し、生成された artifacts/logs を収集し、その後一時的な branch/workflow run を削除して痕跡を減らせる。
-- **Wormable registry propagation**: 盗んだ npm tokens は **publish** permissions と 2FA を回避できるかを検証するべきです。回避できるなら、書き込み可能な packages を列挙し、それらの tarballs をダウンロードして、`setup.mjs` のような loader を注入し、`preinstall` でそれを実行するように設定し、patch version を上げて再公開します。これにより、1 回の CI compromise が他の環境での下流の auto-execution へと変わります。
+- **Install-time code execution via package hooks**: `preinstall`、`postinstall`、`prepare` などの hooks を追加した package version を publish し、dependency の install 中に developer workstation や CI runner 上で payload が自動的に実行されるようにする。
+- **Secondary execution paths**: targets が `--ignore-scripts` で install していても、malicious package は `bin` field に **common CLI name** を登録できるため、attacker-controlled wrapper が `PATH` 内に symlink され、後でその command が使われたときに実行されます。
+- **Runtime bootstrapping**: 小さな installer が install 中に second runtime や toolchain（例えば Bun や packed interpreter）を download し、それを使って main payload を起動することで、local dependency requirements を回避できます。
+- **Credential harvesting from build environments**: code が CI 内で実行されたら、environment variables、`~/.npmrc`、`~/.git-credentials`、SSH keys、cloud CLI configs、`gh auth token` のような local tooling を確認します。GitHub Actions では、runner-specific secrets や artifacts も確認してください。
+- **Workflow injection with stolen GitHub tokens**: **`repo` + `workflow`** permissions を持つ token があれば、branch を作成し、`.github/workflows/` 内に malicious file を commit してそれを trigger し、生成された artifacts/logs を収集し、その後 temporary branch/workflow run を削除して痕跡を減らすことができます。
+- **Wormable registry propagation**: steal した npm tokens については、**publish** 権限があるか、2FA を bypass できるかを確認すべきです。可能であれば、書き込み可能な packages を列挙し、tarball を download して、`setup.mjs` のような loader を inject し、`preinstall` でそれを実行するように設定し、patch version を上げて再 publish します。これにより、1 回の CI compromise が他の environment での downstream auto-execution に変わります。
 
 #### Practical checks during an assessment
 
-- `package.json` に追加された package-manager hooks、予期しない `bin` entries、または release artifact のみを変更する version bumps がないか release automation を確認する。
-- CI が短命な OIDC や trusted publishing の代わりに、`~/.npmrc` のような plaintext files に長期有効な registry credentials を保存していないか確認する。
-- CI で利用可能な GitHub tokens が workflow files を書き込んだり branch/tag を作成できるか検証する。
-- 侵害された package が疑われる場合は、Git repository だけでなく公開された tarball も調査する。悪意ある loader/runtime は公開 artifact のみに存在する可能性があるため。
-- `npm install` の代わりに `npm ci` ではない、予期しない Bun のダウンロード/実行、新しい workflow artifacts が一時的な branches から生成されていないかなど、CI 内での予期しない package-manager execution を探す。
+- `package.json` に追加された package-manager hooks、予期しない `bin` entries、または release artifact だけを変更する version bump がないか release automation を確認する。
+- CI が短命な OIDC や trusted publishing ではなく、`~/.npmrc` のような plaintext file に長期的な registry credentials を保存していないか確認する。
+- CI で利用可能な GitHub tokens が workflow files を書き込めるか、branch/tag を作成できるかを検証する。
+- compromised package が疑われる場合は、Git repository だけでなく published tarball も確認すること。malicious loader/runtime は published artifact にのみ存在する可能性があるためです。
+- CI 内で `npm install` のような予期しない package-manager execution がないか、`npm ci` の代わりに使われていないか、予期しない Bun の download/execution がないか、または transient branches から新しい workflow artifacts が生成されていないかを調べる。
+- GitOps deployment engines も CI/CD targets として確認する。Argo CD 固有の enumeration、repo-server の悪用、Redis cache poisoning attacks は [Argo CD Security](argocd-security.md) に記載されています。
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) は、[**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) に基づいて software supply chain stack の security compliance を監査するための open-source tool です。この auditing は SDLC process 全体に焦点を当てており、code time から deploy time までの risk を明らかにできます。
 
 ### Top 10 CI/CD Security Risk
 
-Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Cider による CI/CD risks のトップ 10 についての興味深い article を確認してください: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it
+- ローカルで実行できる各 platform では、ローカルでの起動方法が示されており、好きなように configure して test できます
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** は infrastructure-as-code 向けの static code analysis tool です。
 
 ## References