Translated ['', 'src/pentesting-ci-cd/gitblit-security/README.md', 'src/

src/pentesting-ci-cd/gitblit-security/README.md

@@ -1,10 +1,10 @@
-# Segurança do Gitblit
+# Gitblit Segurança
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## O que é o Gitblit
 
-Gitblit é um servidor Git auto-hospedado escrito em Java. Pode ser executado como um JAR standalone ou em containers de servlet e inclui um serviço SSH embutido (Apache MINA SSHD) para Git over SSH.
+Gitblit é um servidor Git auto‑hospedado escrito em Java. Pode ser executado como um JAR standalone ou em contêineres de servlet e fornece um serviço SSH embutido (Apache MINA SSHD) para Git sobre SSH.
 
 ## Tópicos
 

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -4,7 +4,7 @@
 
 ## Resumo
 
-CVE-2024-28080 é um bypass de autenticação no serviço SSH embutido do Gitblit devido ao tratamento incorreto do estado da sessão ao integrar com Apache MINA SSHD. Se uma conta de usuário tiver pelo menos uma chave pública SSH registrada, um atacante que conheça o username e qualquer uma das public keys desse usuário pode autenticar sem a private key e sem a password.
+CVE-2024-28080 é um bypass de autenticação no serviço SSH embutido do Gitblit devido ao manuseio incorreto do estado da sessão ao integrar com Apache MINA SSHD. Se uma conta de usuário tiver pelo menos uma chave pública SSH registrada, um atacante que conhece o nome de usuário e qualquer uma das chaves públicas desse usuário pode se autenticar sem a chave privada e sem a senha.
 
 - Affected: Gitblit < 1.10.0 (observed on 1.9.3)
 - Fixed: 1.10.0
@@ -13,27 +13,27 @@ CVE-2024-28080 é um bypass de autenticação no serviço SSH embutido do Gitbli
 - Victim account has at least one SSH public key registered in Gitblit
 - Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/<username>.keys)
 
-## Causa raiz (state leaks between SSH methods)
+## Root cause (state leaks between SSH methods)
 
-No RFC 4252, a autenticação por public‑key ocorre em duas fases: o servidor primeiro verifica se uma public key fornecida é aceitável para um username, e somente após um challenge/response com uma signature é que autentica o usuário. Em MINA SSHD, o PublickeyAuthenticator é invocado duas vezes: na aceitação da key (ainda sem signature) e mais tarde depois que o cliente retorna uma signature.
+No RFC 4252, a autenticação por chave‑pública procede em duas fases: o servidor primeiro verifica se uma chave pública fornecida é aceitável para um nome de usuário, e somente após um challenge/response com uma assinatura é que autentica o usuário. No MINA SSHD, o PublickeyAuthenticator é invocado duas vezes: na aceitação da chave (ainda sem assinatura) e mais tarde, depois que o cliente retorna uma assinatura.
 
-O PublickeyAuthenticator do Gitblit mutou o contexto da sessão na primeira chamada pré‑signature ao vincular o UserModel autenticado à sessão e retornar true ("key acceptable"). Quando a autenticação mais tarde caía para password, o PasswordAuthenticator confiava naquele estado de sessão mutado e atalhava o fluxo, retornando true sem validar a password. Como resultado, qualquer password (incluindo vazia) era aceita após uma "acceptance" prévia por public‑key para o mesmo usuário.
+O PublickeyAuthenticator do Gitblit mutou o contexto da sessão na primeira chamada pré‑assinatura ao vincular o UserModel autenticado à sessão e retornar true ("key acceptable"). Quando a autenticação depois recorria à senha, o PasswordAuthenticator confiava naquele estado de sessão mutado e encurtava o fluxo, retornando true sem validar a senha. Como resultado, qualquer senha (incluindo vazia) era aceita após uma aceitação prévia por chave pública para o mesmo usuário.
 
-High‑level flawed flow:
+Fluxo com falha em alto nível:
 
-1) Client offers username + public key (no signature yet)
-2) Server recognizes the key as belonging to the user and prematurely attaches user to the session, returns true ("acceptable")
-3) Client cannot sign (no private key), so auth falls back to password
-4) Password auth sees a user already present in session and unconditionally returns success
+1) Cliente oferece username + public key (ainda sem assinatura)  
+2) Servidor reconhece a chave como pertencente ao usuário e prematuramente associa o usuário à sessão, retornando true ("acceptable")  
+3) Cliente não consegue assinar (sem private key), então a autenticação recorre à senha  
+4) A autenticação por senha vê um usuário já presente na sessão e retorna sucesso incondicionalmente
 
 ## Exploração passo a passo
 
-- Colete o username da vítima e uma das suas public keys:
+- Colete o username da vítima e uma de suas public keys:
 - GitHub expõe public keys em https://github.com/<username>.keys
 - Servidores públicos frequentemente expõem authorized_keys
-- Configure o OpenSSH para apresentar apenas a metade pública para que a geração da signature falhe, forçando o fallback para password enquanto ainda dispara o caminho de aceitação por public‑key no servidor.
+- Configure o OpenSSH para apresentar apenas a metade pública para que a geração da signature falhe, forçando o fallback para password enquanto ainda aciona o caminho de aceitação por public‑key no servidor.
 
-Exemplo SSH client config (no private key available):
+Exemplo de configuração do cliente SSH (no private key disponível):
 ```sshconfig
 # ~/.ssh/config
 Host gitblit-target
@@ -44,58 +44,58 @@ PreferredAuthentications publickey,password
 IdentitiesOnly yes
 IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
 ```
-Conecte-se e pressione Enter no password prompt (ou digite qualquer string):
+Conecte-se e pressione Enter no prompt de senha (ou digite qualquer string):
 ```bash
 ssh gitblit-target
 # or Git over SSH
 GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
 ```
-A autenticação tem sucesso porque a fase anterior de public‑key mutou a sessão para um usuário autenticado, e a autenticação por password confia incorretamente nesse estado.
+A autenticação ocorre com sucesso porque a fase anterior de public‑key alterou a sessão para um usuário autenticado, e o password auth confia incorretamente nesse estado.
 
-Nota: Se o ControlMaster multiplexing estiver habilitado na sua configuração SSH, comandos Git subsequentes podem reutilizar a conexão autenticada, aumentando o impacto.
+Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
 
-## Impact
+## Impacto
 
-- Impersonação total de qualquer usuário do Gitblit com pelo menos uma SSH public key registrada
-- Acesso de leitura/escrita aos repositórios conforme as permissões da vítima (exfiltração de código, pushes não autorizados, supply‑chain risks)
-- Impacto administrativo potencial se o alvo for um usuário admin
-- Exploração puramente de rede; no brute force ou private key requerido
+- Impersonar completamente qualquer Gitblit user com pelo menos uma SSH public key registrada
+- Acesso de leitura/escrita aos repositórios conforme as permissões da vítima (source exfiltration, unauthorized pushes, supply‑chain risks)
+- Impacto administrativo potencial se o alvo for um admin user
+- Exploração puramente de rede; sem brute force ou private key necessários
 
-## Detection ideas
+## Detecção
 
-- Revise os logs do SSH procurando sequências onde uma tentativa de publickey é seguida por uma autenticação por password bem‑sucedida com uma password vazia ou muito curta
-- Procure por fluxos: método publickey oferecendo material de key não suportado/descasado seguido por sucesso imediato de password para o mesmo username
+- Revise os SSH logs por sequências onde uma tentativa publickey é seguida por uma autenticação password bem‑sucedida com uma senha vazia ou muito curta
+- Procure fluxos: método publickey oferecendo material de chave não suportado/incompatível seguido por sucesso imediato do password para o mesmo username
 
-## Mitigations
+## Mitigações
 
 - Atualize para Gitblit v1.10.0+
 - Até a atualização:
 - Desative Git over SSH no Gitblit, ou
 - Restrinja o acesso de rede ao serviço SSH, e
 - Monitore por padrões suspeitos descritos acima
-- Rotacione as credenciais dos usuários afetados se houver suspeita de comprometimento
+- Altere as credenciais dos usuários afetados se houver suspeita de comprometimento
 
-## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+## Geral: abusando do SSH auth method state‑leakage (MINA/OpenSSH‑based services)
 
-Pattern: Se o public‑key authenticator de um servidor muta o estado do usuário/sessão durante a fase pré‑assinatura "key acceptable" e outros authenticators (ex.: password) confiam nesse estado, você pode contornar a autenticação ao:
+Padrão: Se o public‑key authenticator de um servidor muta o estado do usuário/sessão durante a fase pré‑assinatura "key acceptable" e outros authenticators (e.g., password) confiam nesse estado, você pode contornar a autenticação por:
 
 - Apresentar uma public key legítima para o usuário alvo (sem private key)
-- Forçar o client a falhar na assinatura para que o servidor recorra ao password
-- Fornecer qualquer password enquanto o password authenticator short‑circuits em leaked state
+- Forçar o cliente a falhar ao assinar para que o servidor caia de volta para password
+- Fornecer qualquer password enquanto o password authenticator ignora a verificação devido ao leaked state
 
 Dicas práticas:
 
-- Coleta de public keys em escala: obtenha public keys de fontes comuns como https://github.com/<username>.keys, diretórios organizacionais, páginas de equipe, leaked authorized_keys
-- Forçar falha de assinatura (client‑side): aponte IdentityFile somente para o .pub, defina IdentitiesOnly yes, mantenha PreferredAuthentications para incluir publickey e depois password
+- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forçar falha de assinatura (lado cliente): aponte IdentityFile somente para o .pub, defina IdentitiesOnly yes, mantenha PreferredAuthentications incluindo publickey then password
 - Armadilhas de integração do MINA SSHD:
-- PublickeyAuthenticator.authenticate(...) não deve anexar o estado de usuário/sessão até que o caminho de verificação pós‑assinatura confirme a assinatura
-- PasswordAuthenticator.authenticate(...) não deve inferir sucesso a partir de qualquer estado mutado durante um método de autenticação anterior incompleto
+- PublickeyAuthenticator.authenticate(...) não deve anexar estado do usuário/sessão até que o caminho de verificação pós‑assinatura confirme a assinatura
+- PasswordAuthenticator.authenticate(...) não deve inferir sucesso a partir de qualquer estado mutado durante um método de autenticação prévio incompleto
 
-Related protocol/design notes and literature:
+Notas e literatura relacionadas ao protocolo/design:
 - SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
-- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+- Discussões históricas sobre early acceptance oracles e auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
 
-## References
+## Referências
 
 - [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
 - [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)

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

@@ -1,4 +1,4 @@
-# Metodologia de Pentesting CI/CD
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,93 +6,93 @@
 
 ## VCS
 
-VCS significa **Version Control System**, estes sistemas permitem que desenvolvedores **gerenciem seu código fonte**. O mais comum é **git** e normalmente você encontrará empresas usando-o em uma das seguintes **platforms**:
+VCS significa **Sistema de Controle de Versão**, esses sistemas permitem aos desenvolvedores **gerenciar seu código-fonte**. O mais comum é **git** e normalmente você encontrará empresas usando-o em uma das seguintes **plataformas**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (they offer their own VCS platforms)
+- Fornecedores de cloud (eles oferecem suas próprias plataformas VCS)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines permitem que desenvolvedores **automatizem a execução de código** para diversos fins, incluindo build, testes e deploy de aplicações. Esses fluxos automatizados são **disparados por ações específicas**, como code pushes, pull requests, ou tarefas agendadas. Eles são úteis para otimizar o processo do desenvolvimento até a produção.
+As pipelines CI/CD permitem que desenvolvedores **automatizem a execução de código** para vários fins, incluindo build, testes 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 agilizar o processo do desenvolvimento até a produção.
 
-No entanto, esses sistemas precisam ser **executados em algum lugar** e geralmente com **credenciais privilegiadas para deploy do código ou acesso a informações sensíveis**.
+No entanto, esses sistemas precisam ser **executados em algum lugar** e geralmente com **credenciais privilegiadas para deploy de código ou acesso a informações sensíveis**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Mesmo que algumas VCS platforms permitam criar pipelines, para esta seção vamos analisar apenas ataques potenciais ao controle do código fonte.
+> Mesmo que algumas plataformas 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 guardam informações sensíveis e é preciso ter muito cuidado com as permissões concedidas nessa plataforma. A seguir alguns problemas comuns em VCS platforms que um atacante pode abusar:
+Plataformas que contêm o código-fonte do seu projeto guardam informações sensíveis e as pessoas precisam ter muito cuidado com as permissões concedidas dentro dessa plataforma. Estes são alguns problemas comuns nas plataformas VCS que um atacante poderia abusar:
 
-- **Leaks**: Se seu código contém leaks nos commits e o atacante consegue acessar o repo (porque é público ou porque ele tem acesso), ele pode descobrir os leaks.
-- **Access**: Se um atacante consegue **acessar uma conta dentro da VCS platform** ele pode obter **mais visibilidade e permissões**.
-- **Register**: Algumas plataformas permitem simplesmente que usuários externos criem uma conta.
-- **SSO**: Algumas plataformas não permitem registro, mas permitem que qualquer um acesse com um SSO válido (por exemplo, um atacante poderia usar sua conta do github para entrar).
+- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
+- **Access**: Se um atacante puder **acessar uma conta dentro da plataforma VCS** ele poderia obter **mais visibilidade e permissões**.
+- **Register**: Algumas plataformas simplesmente permitem que usuários externos criem uma conta.
+- **SSO**: Algumas plataformas não permitem registros, 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... existem vários tipos de tokens que um usuário pode roubar para acessar de alguma forma um repo.
-- **Webhooks**: VCS platforms permitem gerar webhooks. Se não estiverem **protegidos** com segredos não-visíveis, um **atacante poderia abusar deles**.
-- Se nenhum segredo estiver em vigor, o atacante poderia abusar do webhook da plataforma terceira.
-- Se o segredo estiver na URL, o mesmo acontece e o atacante também terá o segredo.
-- **Code compromise:** Se um ator malicioso tem algum tipo de **write** sobre os repos, ele poderia tentar **injetar código malicioso**. Para ter sucesso pode ser necessário **bypass branch protections**. Essas ações podem ser realizadas com diferentes objetivos:
-  - Comprometer a main branch para **comprometer a produção**.
-  - Comprometer a main (ou outras branches) para **comprometer máquinas de desenvolvedores** (pois eles geralmente executam testes, terraform ou outras coisas dentro do repo em suas máquinas).
-- **Compromise the pipeline** (veja a próxima seção)
+- **Webhooks**: Plataformas VCS permitem gerar webhooks. Se não estiverem **protegidos** com segredos não visíveis, um **atacante pode abusar deles**.
+- Se não houver segredo em vigor, o atacante poderia abusar do webhook da plataforma terceira
+- Se o segredo estiver na URL, o mesmo acontece e o atacante também terá o segredo
+- **Code compromise:** Se um ator malicioso tiver algum tipo de **acesso de escrita aos repos**, ele poderia tentar **injetar código malicioso**. Para ter sucesso, pode precisar **bypassar branch protections**. Essas ações podem ser realizadas com diferentes objetivos:
+- Comprometer a branch principal para **comprometer a produção**.
+- Comprometer a branch principal (ou outras branches) para **comprometer máquinas dos desenvolvedores** (já que eles costumam executar testes, terraform ou outras coisas do repo em suas máquinas).
+- **Comprometer a pipeline** (veja a próxima seção)
 
 ## Pipelines Pentesting Methodology
 
-A forma mais comum de definir uma pipeline é usando um **CI configuration file hospedado no repositório** que a pipeline constrói. Esse arquivo descreve a ordem dos jobs executados, condições que afetam o fluxo e as configurações do ambiente de build.\
-Esses arquivos tipicamente têm nomes e formatos consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e os YAML do GitHub Actions em .github/workflows. Quando disparado, o job da pipeline **puxa o código** da fonte selecionada (ex.: commit / branch) e **executa os comandos especificados no CI configuration file** contra esse código.
+A maneira mais comum de definir uma pipeline é usando um **arquivo de configuração CI hospedado no repositório** que a pipeline constrói. Esse arquivo descreve a ordem dos jobs executados, condições que afetam o fluxo e configurações do ambiente de build.\
+Esses arquivos tipicamente têm um nome e formato consistente, 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 da pipeline **puxa o código** da fonte selecionada (por ex. commit / branch) e **executa os comandos especificados no arquivo de configuração CI** contra esse código.
 
-Portanto o objetivo final do atacante é de alguma forma **comprometer esses arquivos de configuração** ou os **comandos que eles executam**.
+Portanto, o objetivo final do atacante é de alguma forma **comprometer esses arquivos de configuração** ou os **comandos que eles executam**.
 
 ### PPE - Poisoned Pipeline Execution
 
-A Poisoned Pipeline Execution (PPE) explora permissões em um SCM repository para manipular uma CI pipeline e executar comandos maliciosos. Usuários com as permissões necessárias podem modificar CI configuration files ou outros arquivos usados pelo job da pipeline para incluir comandos maliciosos. Isso "envenena" a CI pipeline, levando à execução desses comandos maliciosos.
+O caminho Poisoned Pipeline Execution (PPE) explora permissões em um repositório SCM para manipular uma 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 da pipeline para incluir comandos maliciosos. Isso "envenena" a pipeline CI, levando à execução desses comandos maliciosos.
 
-Para que um ator malicioso tenha sucesso ao realizar um ataque PPE ele precisa ser capaz de:
+Para que um ator malicioso tenha sucesso realizando um ataque PPE ele precisa ser capaz de:
 
-- Ter **write access to the VCS platform**, já que geralmente pipelines são disparadas quando um push ou um pull request é realizado. (Veja a VCS pentesting methodology para um resumo de formas de obter acesso).
-- Note que às vezes um **external PR conta como "write access"**.
-- Mesmo tendo permissões de escrita, ele precisa ter certeza que pode **modificar o CI config file ou outros arquivos dos quais o config depende**.
-- Para isso, pode ser necessário ser capaz de **bypass branch protections**.
+- Ter **acesso de escrita à plataforma VCS**, já que geralmente as pipelines são acionadas quando um push ou pull request é realizado. (Consulte a VCS pentesting methodology para um resumo das formas de obter acesso).
+- Note que às vezes um **PR externo conta como "acesso de escrita"**.
+- Mesmo que tenha permissões de escrita, ele precisa ter certeza de que pode **modificar o arquivo de configuração CI ou outros arquivos dos quais a configuração depende**.
+- Para isso, pode ser necessário **bypassar branch protections**.
 
-Existem 3 sabores de PPE:
+Existem 3 variantes de PPE:
 
-- **D-PPE**: Um **Direct PPE** ocorre quando o ator **modifica o CI config** file que será executado.
-- **I-DDE**: Um **Indirect PPE** ocorre quando o ator **modifica** um **file** do qual o CI config que será executado **relys on** (como um make file ou uma terraform config).
-- **Public PPE or 3PE**: Em alguns casos as pipelines podem ser **disparadas por usuários que não têm write access no repo** (e que podem nem fazer parte da org) porque conseguem enviar um PR.
-- **3PE Command Injection**: Normalmente, CI/CD pipelines irão **set environment variables** com **informação sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um lugar **perigoso** (por exemplo ao executar **sh commands**), um atacante pode **injetar comandos 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 makefile ou uma configuração terraform).
+- **Public PPE ou 3PE**: Em alguns casos as pipelines podem ser **acionadas por usuários que não têm acesso de escrita no repo** (e que podem nem fazer parte da org) porque podem enviar um PR.
+- **3PE Command Injection**: Normalmente, pipelines CI/CD 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**.
 
 ### Exploitation Benefits
 
-Conhecendo os 3 sabores para envenenar uma pipeline, vejamos o que um atacante poderia obter após uma exploração bem-sucedida:
+Conhecendo as 3 variantes para envenenar uma pipeline, vejamos o que um atacante poderia obter após uma exploração bem-sucedida:
 
-- **Secrets**: Como mencionado anteriormente, pipelines requerem **privileges** para seus jobs (recuperar o código, build, deploy...) e esses privilégios geralmente são guardados em **secrets**. Esses secrets normalmente ficam acessíveis via **env variables ou arquivos dentro do sistema**. Portanto um atacante sempre tentará exfiltrar o máximo de secrets possível.
-- Dependendo da plataforma da pipeline o atacante **pode precisar especificar os secrets no config**. Isso significa que se o atacante não puder modificar a CI configuration pipeline (**I-PPE** por exemplo), ele poderia **apenas exfiltrar os secrets que aquela pipeline possui**.
-- **Computation**: O código é executado em algum lugar; dependendo de onde for executado, o atacante pode ser capaz de pivotar ainda mais.
-- **On-Premises**: Se as pipelines são executadas on premises, um atacante pode acabar em uma **rede interna com acesso a mais recursos**.
-- **Cloud**: O atacante pode acessar **outras máquinas na cloud** e também pode **exfiltrar** tokens de IAM roles/service accounts para obter **mais acesso dentro da cloud**.
-- **Platforms machine**: Às vezes os jobs serão executados nas **máquinas da pipelines platform**, que normalmente estão na cloud sem muito mais acesso.
-- **Select it:** Às vezes a **pipelines platform terá várias máquinas configuradas** e se você pode **modificar o CI configuration file** pode **indicar onde quer rodar o código malicioso**. Nessa situação, um atacante provavelmente executará um reverse shell em cada máquina possível para tentar explorá-la mais.
-- **Compromise production**: Se você estiver dentro da pipeline e a versão final for construída e deployada a partir dela, você pode **comprometer o código que vai rodar em produção**.
+- **Secrets**: Como mencionado anteriormente, pipelines requerem **privilégios** para seus jobs (retrair o código, build, deploy...) e esses privilégios geralmente são **concedidos em secrets**. Esses secrets normalmente são acessíveis via **env variables ou arquivos dentro do sistema**. Portanto um atacante sempre tentará exfiltrar o máximo possível de secrets.
+- Dependendo da plataforma de pipeline o atacante **pode precisar especificar os secrets na config**. Isso significa que, se o atacante não puder modificar a configuração CI da pipeline (**I-PPE** por exemplo), ele poderia **apenas exfiltrar os secrets que essa pipeline possui**.
+- **Computation**: O código é executado em algum lugar; dependendo de onde é executado, um atacante pode ser capaz de pivotar mais adiante.
+- **On-Premises**: Se as pipelines são executadas on-premises, um atacante pode terminar 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 **dela** para obter **acesso adicional dentro da cloud**.
+- **Platforms machine**: Às vezes os jobs serão executados dentro das **máquinas da plataforma de pipelines**, que geralmente estão numa cloud sem **acesso adicional**.
+- **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** você pode **indicar onde quer rodar o código malicioso**. Nessa situação, um atacante provavelmente executará um reverse shell em cada máquina possível para tentar explorá-la mais a fundo.
+- **Compromise production**: Se você estiver dentro da pipeline e a versão final for buildada e deployada a partir dela, você poderia **comprometer o código que acabará rodando em produção**.
 
-## Mais informações relevantes
+## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta open-source para auditar sua cadeia de software para conformidade de segurança baseada 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 no processo completo de SDLC, onde pode revelar riscos desde o tempo de código até o tempo de deploy.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta open-source para auditar sua cadeia de suprimentos de software 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 SDLC, onde pode revelar riscos desde o tempo de código até o tempo de deploy.
 
 ### 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 top 10 riscos CI/CD segundo a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Em cada plataforma que você puder rodar localmente você encontrará como lançá-la localmente para poder configurá-la como quiser e testar.
+- Em cada plataforma que você puder rodar localmente você encontrará como lançá-la localmente para poder configurá-la como quiser para testar
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools