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}}
+
+## Informações Básicas
+
+[Argo CD](https://argo-cd.readthedocs.io/) é uma plataforma de continuous delivery GitOps para Kubernetes. Ela monitora repositórios Git, renderiza manifests do Kubernetes com ferramentas como Helm, Kustomize, Jsonnet ou config management plugins, e reconcilia o estado atual do cluster com o estado desejado armazenado no Git.
+
+Da perspectiva de um attacker, trate o Argo CD como um **deployment engine com credenciais do Kubernetes**. Um compromise útil do Argo CD pode levar a:
+
+- Acesso a repositórios Git privados e credenciais de repositório.
+- Acesso a secrets do cluster Kubernetes usados pelo Argo CD.
+- Execução de código na geração de manifests em `argocd-repo-server`.
+- Deployment não autorizado de objetos do Kubernetes por meio de repositórios Git confiáveis, applications do Argo CD ou manipulação de cache.
+
+## Arquitetura & Componentes Interessantes
+
+Objetos e serviços comuns do Kubernetes:
+```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
+```
+Serviços interessantes:
+
+- **`argocd-server`**: API pública, web UI, CLI API, autenticação e autorização.
+- **`argocd-application-controller`**: compara o estado desejado e o estado em execução, depois aplica recursos ao Kubernetes.
+- **`argocd-repo-server`**: clona repositórios, faz cache de dados Git e executa Helm/Kustomize/Jsonnet/plugins para gerar manifests. A porta gRPC padrão é **8081**.
+- **`argocd-redis`**: cache para dados de application, manifest e Git reference. A porta Redis padrão é **6379**.
+- **`argocd-applicationset-controller`**: gera objetos Argo CD `Application` a partir de generators como Git, SCM, clusters e pull requests.
+
+A partir de um pod comprometido ou de um segmento de rede interno, verifique a acessibilidade interna:
+```bash
+nc -vz <argocd-server> 443
+nc -vz <argocd-repo-server> 8081
+nc -vz <argocd-redis> 6379
+```
+## Public API / UI Attacks
+
+Se você tiver credenciais do Argo CD ou uma instância exposta, comece pela superfície normal da API:
+```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>
+```
+Caminhos de ataque úteis:
+
+- **Application write access**: modificar `source.repoURL`, `source.path`, valores do Helm, opções do Kustomize, configurações do plugin ou opções de sync para fazer o Argo CD deploy de manifests controlados pelo atacante.
+- **Project misconfiguration**: objetos `AppProject` podem permitir `sourceRepos` amplos, `destinations` amplos, `clusterResourceWhitelist` inseguro, ou restrições fracas de namespace.
+- **Repository credential abuse**: secrets de repositório, credenciais de GitHub App, chaves SSH e tokens podem permitir push para repos confiáveis ou adicionar dependências maliciosas.
+- **Cluster credential abuse**: secrets de cluster podem conter bearer tokens ou configuração de exec-provider usada pelo Argo CD para fazer deploy em target clusters.
+- **Local admin / project tokens**: tokens do Argo CD de longa duração podem ser reutilizados pela API, a menos que sejam revogados ou expirem.
+
+Enumere a configuração do Kubernetes quando você tiver cluster read access:
+```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
+```
+## Abuso de Trusted Git Repository
+
+Se você pode fazer push para um repository trusted pelo Argo CD, normalmente consegue influenciar o que é deployed. O impacto depende dos limites do `AppProject` e das permissões da service account usadas pelo application controller.
+
+Locais comuns de payload:
+
+- Raw Kubernetes YAML sob um caminho da application.
+- Templates de Helm chart e `values.yaml`.
+- Kustomize overlays, remote bases e generators.
+- Jsonnet ou input de config management plugin.
+- Arquivos de generator do ApplicationSet que criam ou atualizam objetos `Application`.
+
+Verifique se a app usa automated sync, pruning, self-heal, sync windows ou 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'
+```
+## Abuso direto de `argocd-repo-server`
+
+Não presuma que a API pública do Argo CD é a única superfície de ataque. Componentes internos do Argo CD se comunicam com `argocd-repo-server` via gRPC. Se pods arbitrários conseguirem alcançar o repo-server, requisições internas controladas pelo atacante podem contornar verificações normalmente aplicadas por `argocd-server`.
+
+Verificações práticas:
+```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
+```
+Sinais interessantes:
+
+- O endpoint gRPC do repo-server é acessível a partir de pods que não são do Argo CD.
+- NetworkPolicies estão ausentes ou só permitem allow-list de egress sem negar ingress.
+- O repo-server tem acesso a custom config management plugins, decryption tools, ou conteúdo de repository de múltiplos tenants.
+- Redis é acessível a partir de pods que não são do Argo CD, permitindo inspeção ou tampering do cache se credenciais estiverem disponíveis ou não forem necessárias.
+
+## Unauthenticated Repo-Server RCE via Kustomize Options
+
+Em julho de 2026, a Synacktiv divulgou uma cadeia de execução de código não autenticada no `repo-server` do Argo CD quando um atacante consegue alcançar o serviço gRPC interno. O ataque abusa do acesso direto a `/repository.RepoServerService/GenerateManifest` e de `KustomizeOptions` controladas pelo atacante.
+
+O primitive perigoso é forçar o repo-server a clonar conteúdo de repository controlado pelo atacante e executar Kustomize com suporte a Helm:
+```bash
+kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
+```
+Entrada maliciosa mínima do Kustomize precisa acionar o processamento do Helm:
+```yaml
+helmCharts:
+- name: pwn
+version: 0.0.1
+```
+Por que isso funciona:
+
+- `argocd-repo-server` clona o repositório antes de renderizar.
+- `--helm-command ./payload.sh` é resolvido em relação ao repositório clonado.
+- A execução de código não requer injeção de metacaracteres de shell se o atacante puder controlar o repositório renderizado e as opções de build do Kustomize.
+
+No momento da divulgação da Synacktiv em 1 de julho de 2026, eles relataram que a issue não tinha correção oficial nem CVE. Trate isso primeiro como um problema de exposição de rede: a exploração exige alcance ao port gRPC interno do repo-server.
+
+## Redis Cache Poisoning to Deploy Manifests
+
+Após execução de código em `argocd-repo-server`, ou após acesso direto ao Redis com credenciais válidas, inspecione entradas de cache baseadas em Redis. O Argo CD normalmente armazena valores JSON compactados com gzip.
+
+Prefixos de chave interessantes:
+```text
+mfst|...       # cached rendered manifests
+git-refs|...   # Git branch/ref to commit mappings
+app|...        # application resource/cache data
+cluster|...    # cluster cache information
+```
+O ataque de cache poisoning descrito por Synacktiv abusa de duas peças de estado:
+
+1. Modificar a entrada de cache do manifesto relevante `mfst|...` para incluir um manifesto Kubernetes controlado pelo atacante.
+2. Modificar o mapeamento relacionado `git-refs|...` para que o Argo CD acredite que a branch mudou e então faça reconcile de volta para a revisão em cache.
+
+Impacto:
+
+- Com Auto Sync habilitado, o Argo CD pode aplicar automaticamente o manifesto em cache corrompido.
+- Sem Auto Sync, o payload ainda pode ser aplicado quando um usuário fizer sync manual da aplicação.
+- O impacto final é limitado pelo destino da aplicação alvo e pelas permissões Kubernetes disponíveis para o Argo CD.
+
+## ApplicationSet Attacks
+
+ApplicationSet é especialmente sensível porque cria ou atualiza objetos `Application` a partir da saída do generator.
+
+Review:
+```bash
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+```
+Padrões interessantes:
+
+- Git generators lendo arquivos graváveis por attacker que controlam nomes de app, paths, projects ou destinations.
+- Pull request generators para repositórios públicos onde contributors não confiáveis podem influenciar aplicações geradas.
+- Campos de template que permitem broad destination clusters/namespaces.
+- AppProjects que permitem `sourceRepos: ["*"]` ou broad `destinations`.
+- Aplicações geradas que herdam automated sync e pruning.
+
+## Post-Exploitation
+
+A partir de um shell de pod do Argo CD, priorize:
+```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'
+```
+Objetivos úteis:
+
+- Roubar `REDIS_PASSWORD` ou material TLS/client do Redis.
+- Extrair credenciais de repositório de secrets montados ou de secrets do Kubernetes do Argo CD.
+- Identificar credenciais do cluster usadas pelo Argo CD.
+- Ler manifests gerados e saída de plugin que podem incluir secrets injetados.
+- Verificar se custom plugins, SOPS, Helm secrets, plugins do Vault ou cloud CLIs expõem chaves de decryption e credenciais de cloud.
+
+## Detection & Hardening
+
+Checks importantes:
+
+- Restrinja a porta **8081** do `argocd-repo-server` e a porta **6379** do Redis com NetworkPolicies para que apenas os componentes esperados do Argo CD possam acessá-los.
+- Em implantações Helm, verifique se as network policies estão realmente sendo criadas. Os valores do chart Helm do Argo CD historicamente vinham com a criação de network policy dos componentes desativada por padrão.
+- Mantenha `argocd-server` como o ponto de entrada autenticado. Serviços internos não devem estar acessíveis a workloads arbitrários.
+- Desative ferramentas e plugins de config management não usados.
+- Restrinja `AppProject` `sourceRepos`, `destinations`, permissões de namespace e recursos cluster-scoped.
+- Evite armazenar credenciais amplas de repositório onde um usuário do Argo CD com pouco privilégio possa fazer com que sejam reutilizadas.
+- Monitore requests do repo-server, opções de build do Kustomize, execuções de plugin, writes no Redis e acesso inesperado a chaves `mfst|` / `git-refs|`.
+- Faça rotate de usuários locais do Argo CD, tokens de projeto, credenciais de repositório e credenciais de cluster após compromise.
+
+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
+```
+## Nota de Static Analysis: Typed API Requests em CodeQL
+
+Para serviços Go usando handlers gRPC/REST, as default CodeQL remote sources podem perder flows depois que o raw input é unmarshaled em typed request objects. Um modelo útil para serviços no estilo Argo CD é:
+
+- Receiver type como `Server` ou `Service`.
+- O primeiro parâmetro é `context.Context`.
+- O segundo parâmetro é um typed request object.
+
+Modele esse segundo parâmetro como um remote source e adicione custom sinks para argumentos de `exec.Command` / `exec.CommandContext`. Isso ajuda a encontrar flows de campos de internal API request para command execution helpers.
+
+## 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

@@ -1,4 +1,4 @@
-# Metodologia de Pentesting de CI/CD
+# Metodologia de Pentesting CI/CD
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS significa **Version Control System**, este sistema permite aos desenvolvedores **gerenciar seu código-fonte**. O mais comum é **git** e você normalmente encontrará empresas usando-o em uma das seguintes **plataformas**:
+VCS significa **Version Control System**, este sistema permite que desenvolvedores **gerenciem seu código-fonte**. O mais comum é **git** e você normalmente encontrará empresas usando-o em uma das seguintes **plataformas**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (eles oferecem suas próprias plataformas VCS)
+- Cloud providers (eles oferecem suas próprias plataformas de VCS)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines permitem que desenvolvedores **automatizem a execução de código** para vários propósitos, incluindo build, test e deployment de aplicações. Esses workflows automatizados são **acionados por ações específicas**, como code pushes, pull requests ou tarefas agendadas. Eles são úteis para simplificar o processo de development até production.
+CI/CD pipelines permitem que desenvolvedores **automatizem a execução de código** para vários propósitos, incluindo build, teste e deploy de aplicações. Esses fluxos de trabalho automatizados são **acionados por ações específicas**, como pushes de código, pull requests ou tarefas agendadas. Eles são úteis para simplificar o processo do desenvolvimento até a produção.
 
-No entanto, esses sistemas precisam ser **executados em algum lugar** e normalmente com **credenciais privilegiadas para deploy de código ou acesso a informações sensíveis**.
+No entanto, esses sistemas precisam ser **executados em algum lugar** e, normalmente, com **credenciais privilegiadas para fazer deploy de código ou acessar informações sensíveis**.
 
-## Metodologia de Pentesting em VCS
+## Metodologia de Pentesting de VCS
 
 > [!NOTE]
-> Mesmo que algumas plataformas VCS permitam criar pipelines, para esta seção vamos analisar apenas ataques potenciais ao controle do código-fonte.
+> Mesmo que algumas plataformas de VCS permitam criar pipelines, para esta seção vamos analisar apenas ataques potenciais ao controle do código-fonte.
 
-Plataformas que contêm o código-fonte do seu projeto contêm informações sensíveis e as pessoas precisam ser muito cuidadosas com as permissões concedidas dentro dessa plataforma. Estes são alguns problemas comuns em plataformas VCS que um attacker pode abusar:
+Plataformas que contêm o código-fonte do seu projeto contêm informações sensíveis e as pessoas precisam ser muito cuidadosas com as permissões concedidas dentro dessa plataforma. Estes são alguns problemas comuns em plataformas de VCS que um atacante poderia abusar:
 
-- **Leaks**: Se seu código contém leaks nos commits e o attacker consegue acessar o repo (porque ele é público ou porque ele tem acesso), ele pode descobrir os leaks.
-- **Access**: Se um attacker consegue **acessar uma conta dentro da plataforma VCS** ele pode obter **mais visibility e permissions**.
-- **Register**: Algumas plataformas simplesmente permitem que usuários externos criem uma conta.
-- **SSO**: Algumas plataformas não permitem que usuários se cadastrem, mas permitem que qualquer pessoa acesse com um SSO válido (então um attacker poderia usar sua conta do github para entrar, por exemplo).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... há vários tipos de tokens que um user pode roubar para acessar de alguma forma um repo.
-- **Webhooks**: Plataformas VCS permitem gerar webhooks. Se eles **não estiverem protegidos** com secrets não visíveis, um **attacker pode abusar deles**.
-- Se nenhum secret estiver configurado, o attacker pode abusar do webhook da plataforma third party
-- Se o secret estiver na URL, o mesmo acontece e o attacker também terá o secret
-- **Code compromise:** Se um malicious actor tiver algum tipo de acesso de **write** aos repos, ele pode tentar **injetar malicious code**. Para ter sucesso, ele pode precisar **bypassar branch protections**. Essas ações podem ser realizadas com diferentes objetivos em mente:
-- Comprometer a main branch para **comprometer production**.
-- Comprometer a main (ou outras branches) para **comprometer as máquinas dos developers** (pois eles normalmente executam test, terraform ou outras coisas dentro do repo em suas máquinas).
+- **Leaks**: Se o seu código contém leaks nos commits e o atacante pode acessar o repo (porque ele é público ou porque ele tem acesso), ele pode descobrir os leaks.
+- **Access**: Se um atacante pode **acessar uma conta dentro da plataforma VCS**, ele pode ganhar **mais visibilidade e permissões**.
+- **Register**: Algumas plataformas apenas permitem que usuários externos criem uma conta.
+- **SSO**: Algumas plataformas não permitem que usuários se registrem, mas permitem que qualquer pessoa acesse com um SSO válido (então um atacante poderia usar sua conta do github para entrar, por exemplo).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... há vários tipos de tokens que um usuário poderia roubar para acessar de alguma forma um repo.
+- **Webhooks**: Plataformas de VCS permitem gerar webhooks. Se eles **não estiverem protegidos** com secrets invisíveis, um **atacante poderia abusar deles**.
+- Se nenhum secret estiver em uso, o atacante poderia abusar do webhook da plataforma de terceiros
+- Se o secret estiver na URL, a mesma coisa acontece e o atacante também terá o secret
+- **Code compromise:** Se um ator malicioso tiver algum tipo de acesso de **write** sobre os repos, ele poderia tentar **injetar código malicioso**. Para ter sucesso, ele pode precisar **bypassar branch protections**. Essas ações podem ser realizadas com diferentes objetivos em mente:
+- Comprometer a main branch para **comprometer a produção**.
+- Comprometer a main (ou outras branches) para **comprometer as máquinas dos desenvolvedores** (já que eles normalmente executam test, terraform ou outras coisas dentro do repo em suas máquinas).
 - **Comprometer o pipeline** (veja a próxima seção)
 
 ## Metodologia de Pentesting de Pipelines
 
-A forma mais comum de definir um pipeline é usando um **CI configuration file hospedado no repository** que o pipeline builda. Esse arquivo descreve a ordem dos jobs executados, as conditions que afetam o flow e as configurações do ambiente de build.\
-Esses arquivos normalmente têm um nome e formato consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e os arquivos YAML do GitHub Actions localizados em .github/workflows. Quando acionado, o job do pipeline **faz pull do code** da source selecionada (por exemplo, commit / branch) e **executa os commands especificados no CI configuration file** contra esse code.
+A forma mais comum de definir um pipeline é usando um **arquivo de configuração CI hospedado no repositório** que o pipeline constrói. Esse arquivo descreve a ordem dos jobs executados, as condições que afetam o fluxo e as configurações do ambiente de build.\
+Esses arquivos normalmente têm um nome e formato consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e os arquivos YAML do GitHub Actions localizados em .github/workflows. Quando acionado, o job do pipeline **faz pull do código** da origem selecionada (por exemplo, commit / branch) e **executa os comandos especificados no arquivo de configuração CI** contra esse código.
 
-Portanto, o objetivo final do attacker é de alguma forma **comprometer esses configuration files** ou os **commands que eles executam**.
+Portanto, o objetivo final do atacante é de alguma forma **comprometer esses arquivos de configuração** ou os **comandos que eles executam**.
 
 > [!TIP]
-> Alguns hosted builders permitem que contributors escolham o Docker build context e o caminho do Dockerfile. Se o context for controlado pelo attacker, você pode defini-lo fora do repo (por exemplo, "..") para ingerir host files durante o build e exfiltrar secrets. Veja:
+> Alguns builders hospedados permitem que contribuintes escolham o Docker build context e o caminho do Dockerfile. Se o context estiver sob controle do atacante, você pode defini-lo fora do repo (por exemplo, "..") para ingerir arquivos do host durante o build e exfiltrar secrets. Veja:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,63 +58,64 @@ Portanto, o objetivo final do attacker é de alguma forma **comprometer esses co
 
 ### PPE - Poisoned Pipeline Execution
 
-O caminho Poisoned Pipeline Execution (PPE) explora permissions em um repository SCM para manipular um pipeline CI e executar commands maliciosos. Users com as permissions necessárias podem modificar CI configuration files ou outros files usados pelo job do pipeline para incluir commands maliciosos. Isso "envenena" o CI pipeline, levando à execução desses commands maliciosos.
+O caminho Poisoned Pipeline Execution (PPE) explora permissões em um repositório SCM para manipular um pipeline CI e executar comandos maliciosos. Usuários com as permissões necessárias podem modificar arquivos de configuração CI ou outros arquivos usados pelo job do pipeline para incluir comandos maliciosos. Isso "envenena" o pipeline CI, levando à execução desses comandos maliciosos.
 
-Para um malicious actor ter sucesso ao realizar um ataque PPE, ele precisa ser capaz de:
+Para um ator malicioso ter sucesso ao realizar um ataque PPE, ele precisa ser capaz de:
 
-- Ter **write access à plataforma VCS**, já que normalmente os pipelines são acionados quando ocorre um push ou um pull request. (Veja a metodologia de pentesting em VCS para um resumo das formas de obter acesso).
+- Ter **write access à plataforma VCS**, já que normalmente pipelines são acionados quando um push ou um pull request é realizado. (Veja a metodologia de pentesting de VCS para um resumo das formas de obter acesso).
 - Note que às vezes um **external PR conta como "write access"**.
-- Mesmo tendo write permissions, ele precisa ter certeza de que consegue **modificar o CI config file ou outros files dos quais o config depende**.
+- Mesmo tendo permissões de write, ele precisa ter certeza de que pode **modificar o arquivo de configuração CI ou outros arquivos dos quais a config depende**.
 - Para isso, ele pode precisar ser capaz de **bypassar branch protections**.
 
-Há 3 variações de PPE:
+Existem 3 variações de PPE:
 
-- **D-PPE**: Um ataque **Direct PPE** ocorre quando o actor **modifica o CI config** file que será executado.
-- **I-DDE**: Um ataque **Indirect PPE** ocorre quando o actor **modifica** um **file** do qual o CI config file que será executado **depende** (como um make file ou uma terraform config).
-- **Public PPE or 3PE**: Em alguns casos os pipelines podem ser **acionados por users que não têm write access no repo** (e que talvez nem façam parte da org) porque eles podem enviar um PR.
-- **3PE Command Injection**: Normalmente, CI/CD pipelines vão **definir environment variables** com **informações sobre o PR**. Se esse valor puder ser controlado por um attacker (como o título do PR) e for **usado** em um **lugar perigoso** (como executar **sh commands**), um attacker pode **injetar commands ali**.
+- **D-PPE**: Um ataque **Direct PPE** ocorre quando o ator **modifica o arquivo de configuração CI** que será executado.
+- **I-DDE**: Um ataque **Indirect PPE** ocorre quando o ator **modifica** um **arquivo** do qual o arquivo de configuração CI que será executado **depende** (como um make file ou uma config terraform).
+- **Public PPE or 3PE**: Em alguns casos os pipelines podem ser **acionados por usuários que não têm write access no repo** (e que talvez nem façam parte da org) porque eles podem enviar um PR.
+- **3PE Command Injection**: Normalmente, CI/CD pipelines vão **definir variáveis de ambiente** com **informações sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um **local perigoso** (como executar comandos **sh**), um atacante pode **injetar comandos ali**.
 
-### Benefícios da Exploitation
+### Benefícios da Exploração
 
-Conhecendo as 3 variações para envenenar um pipeline, vamos ver o que um attacker pode obter após uma exploitation bem-sucedida:
+Conhecendo as 3 variações para envenenar um pipeline, vamos ver o que um atacante poderia obter após uma exploração bem-sucedida:
 
-- **Secrets**: Como mencionado anteriormente, pipelines exigem **privileges** para seus jobs (obter o code, buildá-lo, fazer deploy...) e esses privileges normalmente são **concedidos em secrets**. Esses secrets normalmente são acessíveis via **env variables ou files dentro do sistema**. Portanto, um attacker sempre tentará exfiltrar o máximo de secrets possível.
-- Dependendo da plataforma de pipeline, o attacker **pode precisar especificar os secrets no config**. Isso significa que, se o attacker não puder modificar o CI configuration pipeline (**I-PPE**, por exemplo), ele **só poderá exfiltrar os secrets que esse pipeline possui**.
-- **Computation**: O code é executado em algum lugar, dependendo de onde for executado um attacker pode conseguir fazer pivot further.
-- **On-Premises**: Se os pipelines forem executados on premises, um attacker pode acabar em uma **internal network com acesso a mais resources**.
-- **Cloud**: O attacker poderia acessar **outras machines na cloud** mas também poderia **exfiltrar** IAM roles/service accounts **tokens** de lá para obter **further access dentro da cloud**.
-- **Platforms machine**: Às vezes os jobs serão executados dentro das **pipelines platform machines**, que normalmente estão em uma cloud com **no more access**.
-- **Select it:** Às vezes a **pipelines platform terá várias machines configuradas** e, se você puder **modificar o CI configuration file**, poderá **indicar onde quer executar o malicious code**. Nessa situação, um attacker provavelmente executará um reverse shell em cada máquina possível para tentar explorá-la further.
-- **Compromise production**: Se você estiver dentro do pipeline e a versão final for buildada e deployed a partir dele, você poderá **comprometer o code que vai acabar sendo executado em production**.
+- **Secrets**: Como mencionado anteriormente, pipelines exigem **privilégios** para seus jobs (obter o código, buildá-lo, fazer deploy...) e esses privilégios geralmente são **concedidos em secrets**. Esses secrets normalmente ficam acessíveis via **variáveis de env ou arquivos dentro do sistema**. Portanto, um atacante sempre tentará exfiltrar o máximo de secrets possível.
+- Dependendo da plataforma do pipeline, o atacante **pode precisar especificar os secrets na config**. Isso significa que, se o atacante não puder modificar a configuração CI do pipeline (**I-PPE**, por exemplo), ele poderá **apenas exfiltrar os secrets que esse pipeline possui**.
+- **Computação**: O código é executado em algum lugar; dependendo de onde ele é executado, um atacante pode conseguir pivotar mais.
+- **On-Premises**: Se os pipelines forem executados on premises, um atacante pode acabar em uma **rede interna com acesso a mais recursos**.
+- **Cloud**: O atacante poderia acessar **outras máquinas na cloud**, mas também poderia **exfiltrar** tokens de IAM roles/service accounts **a partir dela** para obter **mais acesso dentro da cloud**.
+- **Platforms machine**: Às vezes os jobs serão executados dentro das **máquinas da plataforma de pipelines**, que normalmente estão dentro de uma cloud com **sem mais acesso**.
+- **Select it:** Às vezes a **plataforma de pipelines terá várias máquinas configuradas** e, se você puder **modificar o arquivo de configuração CI**, poderá **indicar onde quer executar o código malicioso**. Nessa situação, um atacante provavelmente executará uma reverse shell em cada máquina possível para tentar explorá-la mais.
+- **Compromise production**: Se você estiver dentro do pipeline e a versão final for buildada e deployada a partir dele, você poderia **comprometer o código que vai acabar executando em produção**.
 
 ### Dependency & Registry Supply-Chain Abuse
 
-Comprometer um CI/CD pipeline ou roubar credenciais dele pode permitir que um attacker vá de **pipeline execution** para **ecosystem-wide code execution** ao inserir backdoor em dependencies ou ferramentas de release:
+Comprometer um CI/CD pipeline ou roubar credenciais dele pode permitir que um atacante vá de **pipeline execution** para **code execution em todo o ecossistema** ao backdoorar dependencies ou ferramentas de release:
 
-- **Install-time code execution via package hooks**: publicar uma versão do package que adiciona hooks `preinstall`, `postinstall`, `prepare` ou similares para que o payload rode automaticamente em workstations de developers e CI runners durante a instalação de dependencies.
-- **Secondary execution paths**: mesmo que os targets instalem com `--ignore-scripts`, um package malicioso ainda pode registrar um **common CLI name** no campo `bin`, fazendo com que o wrapper controlado pelo attacker seja linked por symlink em `PATH` e executado depois quando o command for usado.
-- **Runtime bootstrapping**: um pequeno installer pode baixar um segundo runtime ou toolchain durante a instalação (por exemplo Bun ou um interpreter empacotado) e então lançar o main payload com ele, evitando dependências locais.
-- **Credential harvesting from build environments**: uma vez que o code rode dentro do CI, verifique environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs e ferramentas locais como `gh auth token`. No GitHub Actions, procure também secrets e artifacts específicos do runner.
-- **Workflow injection with stolen GitHub tokens**: um token com permissões **`repo` + `workflow`** é suficiente para criar uma branch, fazer commit de um file malicioso dentro de `.github/workflows/`, acioná-lo, coletar os artifacts/logs produzidos e depois apagar a branch/workflow run temporária para reduzir rastros.
-- **Wormable registry propagation**: tokens do npm roubados devem ser validados quanto a permissões de **publish** e se contornam 2FA. Se contornarem, enumere packages graváveis, baixe seus tarballs, injete um loader como `setup.mjs`, defina `preinstall` para executá-lo, incremente a patch version e publique novamente. Isso transforma um comprometimento de CI em auto-execution downstream em outros ambientes.
+- **Install-time code execution via package hooks**: publique uma versão de package que adicione `preinstall`, `postinstall`, `prepare` ou hooks similares para que o payload rode automaticamente nas máquinas dos developers e nos CI runners durante a instalação de dependências.
+- **Secondary execution paths**: mesmo que os alvos instalem com `--ignore-scripts`, um package malicioso ainda pode registrar um nome de CLI comum no campo `bin`, fazendo com que o wrapper controlado pelo atacante seja vinculado via symlink em `PATH` e execute depois quando o comando for usado.
+- **Runtime bootstrapping**: um pequeno installer pode baixar um segundo runtime ou toolchain durante a instalação (por exemplo Bun ou um interpreter empacotado) e então iniciar o payload principal com ele, evitando dependências locais.
+- **Credential harvesting from build environments**: uma vez que o código rode dentro do CI, verifique variáveis de ambiente, `~/.npmrc`, `~/.git-credentials`, chaves SSH, configs de cloud CLI e ferramentas locais como `gh auth token`. No GitHub Actions, procure também secrets e artifacts específicos do runner.
+- **Workflow injection with stolen GitHub tokens**: um token com permissões **`repo` + `workflow`** é suficiente para criar uma branch, fazer commit de um arquivo malicioso dentro de `.github/workflows/`, acioná-lo, coletar os artifacts/logs produzidos e depois apagar a branch temporária/execução do workflow para reduzir rastros.
+- **Wormable registry propagation**: tokens npm roubados devem ser validados quanto a permissões de **publish** e se eles contornam 2FA. Se sim, enumere packages graváveis, baixe seus tarballs, injete um loader como `setup.mjs`, defina `preinstall` para executá-lo, incremente a versão patch e republique. Isso transforma um compromisso de CI em autoexecução downstream em outros ambientes.
 
-#### Verificações práticas durante uma avaliação
+#### Practical checks during an assessment
 
-- Revise a automação de release em busca de hooks de package-manager adicionados ao `package.json`, entradas `bin` inesperadas ou bumps de versão que modificam apenas o release artifact.
-- Verifique se o CI armazena credenciais de registry de longa duração em files em texto puro como `~/.npmrc` em vez de usar OIDC de curta duração ou trusted publishing.
-- Verifique se tokens do GitHub disponíveis no CI podem escrever workflow files ou criar branches/tags.
-- Se houver suspeita de um package comprometido, inspecione o tarball publicado e não apenas o Git repository, porque o loader/runtime malicioso pode existir apenas no artifact publicado.
-- Procure execução inesperada de package-manager dentro do CI, como `npm install` em vez de `npm ci`, downloads/execução inesperados de Bun ou novos workflow artifacts gerados a partir de branches transitórias.
+- Revise a automação de release em busca de hooks de package-manager adicionados ao `package.json`, entradas `bin` inesperadas ou bumps de versão que apenas modificam o artifact de release.
+- Verifique se o CI armazena credenciais de registry de longa duração em arquivos de texto como `~/.npmrc` em vez de usar OIDC de curta duração ou trusted publishing.
+- Verifique se tokens do GitHub disponíveis no CI podem escrever arquivos de workflow ou criar branches/tags.
+- Se houver suspeita de um package comprometido, inspecione o tarball publicado e não apenas o repositório Git, porque o loader/runtime malicioso pode existir apenas no artifact publicado.
+- Procure por execução inesperada de package-manager dentro do CI, como `npm install` em vez de `npm ci`, downloads/execução inesperados de Bun ou novos artifacts de workflow gerados a partir de branches temporárias.
+- Revise engines de deploy GitOps também como alvos de CI/CD. Enumeração específica de Argo CD, abuso de repo-server e ataques de cache poisoning em Redis são cobertos em [Argo CD Security](argocd-security.md).
 
 ## Mais informações relevantes
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta open-source para auditar sua software supply chain stack quanto à conformidade de segurança com base em um novo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria se concentra em todo o processo de SDLC, onde pode revelar riscos desde o code time até o deploy time.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta open-source para auditar sua stack de software supply chain quanto à conformidade de segurança com base em um novo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria foca em todo o processo de SDLC, onde pode revelar riscos desde o code time até o deploy time.
 
 ### Top 10 CI/CD Security Risk
 
-Confira este artigo interessante sobre os top 10 riscos de CI/CD segundo a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Confira este artigo interessante sobre os 10 principais riscos de CI/CD segundo a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
@@ -123,7 +124,7 @@ Confira este artigo interessante sobre os top 10 riscos de CI/CD segundo a Cider
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** é uma ferramenta de static code analysis para infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** é uma ferramenta de análise estática de código para infrastructure-as-code.
 
 ## References