diff --git a/src/pentesting-ci-cd/gitblit-security/README.md b/src/pentesting-ci-cd/gitblit-security/README.md new file mode 100644 index 000000000..cb6df5348 --- /dev/null +++ b/src/pentesting-ci-cd/gitblit-security/README.md @@ -0,0 +1,21 @@ +# Segurança do Gitblit + +{{#include ../../banners/hacktricks-training.md}} + +## O que é o Gitblit + +Gitblit é um servidor Git auto-hospedado escrito em Java. Pode ser executado como um JAR standalone ou em containers de servlet e inclui um serviço SSH embutido (Apache MINA SSHD) para Git over SSH. + +## Tópicos + +- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080) + +{{#ref}} +gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md +{{#endref}} + +## Referências + +- [Gitblit project](https://gitblit.com/) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md new file mode 100644 index 000000000..fe3091584 --- /dev/null +++ b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md @@ -0,0 +1,107 @@ +# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080) + +{{#include ../../banners/hacktricks-training.md}} + +## Resumo + +CVE-2024-28080 é um bypass de autenticação no serviço SSH embutido do Gitblit devido ao tratamento incorreto do estado da sessão ao integrar com Apache MINA SSHD. Se uma conta de usuário tiver pelo menos uma chave pública SSH registrada, um atacante que conheça o username e qualquer uma das public keys desse usuário pode autenticar sem a private key e sem a password. + +- Affected: Gitblit < 1.10.0 (observed on 1.9.3) +- Fixed: 1.10.0 +- Requirements to exploit: +- Git over SSH enabled on the instance +- Victim account has at least one SSH public key registered in Gitblit +- Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/.keys) + +## Causa raiz (state leaks between SSH methods) + +No RFC 4252, a autenticação por public‑key ocorre em duas fases: o servidor primeiro verifica se uma public key fornecida é aceitável para um username, e somente após um challenge/response com uma signature é que autentica o usuário. Em MINA SSHD, o PublickeyAuthenticator é invocado duas vezes: na aceitação da key (ainda sem signature) e mais tarde depois que o cliente retorna uma signature. + +O PublickeyAuthenticator do Gitblit mutou o contexto da sessão na primeira chamada pré‑signature ao vincular o UserModel autenticado à sessão e retornar true ("key acceptable"). Quando a autenticação mais tarde caía para password, o PasswordAuthenticator confiava naquele estado de sessão mutado e atalhava o fluxo, retornando true sem validar a password. Como resultado, qualquer password (incluindo vazia) era aceita após uma "acceptance" prévia por public‑key para o mesmo usuário. + +High‑level flawed flow: + +1) Client offers username + public key (no signature yet) +2) Server recognizes the key as belonging to the user and prematurely attaches user to the session, returns true ("acceptable") +3) Client cannot sign (no private key), so auth falls back to password +4) Password auth sees a user already present in session and unconditionally returns success + +## Exploração passo a passo + +- Colete o username da vítima e uma das suas public keys: +- GitHub expõe public keys em https://github.com/.keys +- Servidores públicos frequentemente expõem authorized_keys +- Configure o OpenSSH para apresentar apenas a metade pública para que a geração da signature falhe, forçando o fallback para password enquanto ainda dispara o caminho de aceitação por public‑key no servidor. + +Exemplo SSH client config (no private key available): +```sshconfig +# ~/.ssh/config +Host gitblit-target +HostName +User +PubkeyAuthentication yes +PreferredAuthentications publickey,password +IdentitiesOnly yes +IdentityFile ~/.ssh/victim.pub # public half only (no private key present) +``` +Conecte-se e pressione Enter no password prompt (ou digite qualquer string): +```bash +ssh gitblit-target +# or Git over SSH +GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://@/ +``` +A autenticação tem sucesso porque a fase anterior de public‑key mutou a sessão para um usuário autenticado, e a autenticação por password confia incorretamente nesse estado. + +Nota: Se o ControlMaster multiplexing estiver habilitado na sua configuração SSH, comandos Git subsequentes podem reutilizar a conexão autenticada, aumentando o impacto. + +## Impact + +- Impersonação total de qualquer usuário do Gitblit com pelo menos uma SSH public key registrada +- Acesso de leitura/escrita aos repositórios conforme as permissões da vítima (exfiltração de código, pushes não autorizados, supply‑chain risks) +- Impacto administrativo potencial se o alvo for um usuário admin +- Exploração puramente de rede; no brute force ou private key requerido + +## Detection ideas + +- Revise os logs do SSH procurando sequências onde uma tentativa de publickey é seguida por uma autenticação por password bem‑sucedida com uma password vazia ou muito curta +- Procure por fluxos: método publickey oferecendo material de key não suportado/descasado seguido por sucesso imediato de password para o mesmo username + +## Mitigations + +- Atualize para Gitblit v1.10.0+ +- Até a atualização: +- Desative Git over SSH no Gitblit, ou +- Restrinja o acesso de rede ao serviço SSH, e +- Monitore por padrões suspeitos descritos acima +- Rotacione as credenciais dos usuários afetados se houver suspeita de comprometimento + +## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services) + +Pattern: Se o public‑key authenticator de um servidor muta o estado do usuário/sessão durante a fase pré‑assinatura "key acceptable" e outros authenticators (ex.: password) confiam nesse estado, você pode contornar a autenticação ao: + +- Apresentar uma public key legítima para o usuário alvo (sem private key) +- Forçar o client a falhar na assinatura para que o servidor recorra ao password +- Fornecer qualquer password enquanto o password authenticator short‑circuits em leaked state + +Dicas práticas: + +- Coleta de public keys em escala: obtenha public keys de fontes comuns como https://github.com/.keys, diretórios organizacionais, páginas de equipe, leaked authorized_keys +- Forçar falha de assinatura (client‑side): aponte IdentityFile somente para o .pub, defina IdentitiesOnly yes, mantenha PreferredAuthentications para incluir publickey e depois password +- Armadilhas de integração do MINA SSHD: +- PublickeyAuthenticator.authenticate(...) não deve anexar o estado de usuário/sessão até que o caminho de verificação pós‑assinatura confirme a assinatura +- PasswordAuthenticator.authenticate(...) não deve inferir sucesso a partir de qualquer estado mutado durante um método de autenticação anterior incompleto + +Related protocol/design notes and literature: +- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process) +- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior + +## References + +- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/) +- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0) +- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/) +- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html) +- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252) + + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index c89e81c95..6a1358fd2 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,99 +6,102 @@ ## VCS -VCS significa **Version Control System**, esses sistemas permitem que os desenvolvedores **gerenciem seu código-fonte**. O mais comum é o **git** e você geralmente encontrará empresas usando-o em uma das seguintes **plataformas**: +VCS significa **Version Control System**, estes sistemas permitem que desenvolvedores **gerenciem seu código fonte**. O mais comum é **git** e normalmente você encontrará empresas usando-o em uma das seguintes **platforms**: - Github - Gitlab - Bitbucket - Gitea -- Provedores de nuvem (eles oferecem suas próprias plataformas VCS) +- Gitblit +- Cloud providers (they offer their own VCS platforms) -## Pipelines CI/CD -As pipelines CI/CD permitem que os desenvolvedores **automatizem a execução de código** para vários propósitos, incluindo construção, teste e implantação de aplicações. Esses fluxos de trabalho automatizados são **ativados por ações específicas**, como pushes de código, pull requests ou tarefas agendadas. Eles são úteis para agilizar o processo do desenvolvimento à produção. +## CI/CD Pipelines -No entanto, esses sistemas precisam ser **executados em algum lugar** e geralmente com **credenciais privilegiadas para implantar código ou acessar informações sensíveis**. +CI/CD pipelines permitem que desenvolvedores **automatizem a execução de código** para diversos fins, incluindo build, testes e deploy de aplicações. Esses fluxos automatizados são **disparados por ações específicas**, como code pushes, pull requests, ou tarefas agendadas. Eles são úteis para otimizar o processo do desenvolvimento até a produção. -## Metodologia de Pentesting VCS +No entanto, esses sistemas precisam ser **executados em algum lugar** e geralmente com **credenciais privilegiadas para deploy do código ou acesso a informações sensíveis**. + +## VCS Pentesting Methodology > [!NOTE] -> Mesmo que algumas plataformas VCS permitam criar pipelines, nesta seção vamos analisar apenas ataques potenciais ao controle do código-fonte. +> Mesmo que algumas VCS platforms permitam criar pipelines, para esta seção vamos analisar apenas ataques potenciais ao controle do código fonte. -Plataformas que contêm o código-fonte do seu projeto contêm informações sensíveis e as pessoas precisam ter muito cuidado com as permissões concedidas dentro dessa plataforma. Estes são alguns problemas comuns em plataformas VCS que um atacante poderia explorar: +Plataformas que contêm o código fonte do seu projeto guardam informações sensíveis e é preciso ter muito cuidado com as permissões concedidas nessa plataforma. A seguir alguns problemas comuns em VCS platforms que um atacante pode abusar: -- **Leaks**: Se seu código contém leaks nos commits e o atacante pode acessar o repositório (porque é público ou porque ele tem acesso), ele poderia descobrir os leaks. -- **Acesso**: Se um atacante pode **acessar uma conta dentro da plataforma VCS**, ele poderia ganhar **mais visibilidade e permissões**. -- **Registro**: Algumas plataformas permitem apenas que usuários externos criem uma conta. -- **SSO**: Algumas plataformas não permitirão que os usuários se registrem, mas permitirão que qualquer um acesse com um SSO válido (então um atacante poderia usar sua conta do github para entrar, por exemplo). -- **Credenciais**: Nome de usuário + Senha, tokens pessoais, chaves ssh, tokens Oauth, cookies... existem vários tipos de tokens que um usuário poderia roubar para acessar de alguma forma um repositório. -- **Webhooks**: As plataformas VCS permitem gerar webhooks. Se eles **não estiverem protegidos** com segredos não visíveis, um **atacante poderia abusar deles**. -- Se nenhum segredo estiver em vigor, o atacante poderia abusar do webhook da plataforma de terceiros. -- Se o segredo estiver na URL, o mesmo acontece e o atacante também tem o segredo. -- **Comprometimento de código:** Se um ator malicioso tiver algum tipo de acesso **de escrita** sobre os repositórios, ele poderia tentar **injetar código malicioso**. Para ter sucesso, ele pode precisar **contornar as proteções de branch**. Essas ações podem ser realizadas com diferentes objetivos em mente: -- Comprometer o branch principal para **comprometer a produção**. -- Comprometer o principal (ou outros branches) para **comprometer as máquinas dos desenvolvedores** (já que eles geralmente executam testes, terraform ou outras coisas dentro do repositório em suas máquinas). -- **Comprometer a pipeline** (ver próxima seção) +- **Leaks**: Se seu código contém leaks nos commits e o atacante consegue acessar o repo (porque é público ou porque ele tem acesso), ele pode descobrir os leaks. +- **Access**: Se um atacante consegue **acessar uma conta dentro da VCS platform** ele pode obter **mais visibilidade e permissões**. +- **Register**: Algumas plataformas permitem simplesmente que usuários externos criem uma conta. +- **SSO**: Algumas plataformas não permitem registro, mas permitem que qualquer um acesse com um SSO válido (por exemplo, um atacante poderia usar sua conta do github para entrar). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... existem vários tipos de tokens que um usuário pode roubar para acessar de alguma forma um repo. +- **Webhooks**: VCS platforms permitem gerar webhooks. Se não estiverem **protegidos** com segredos não-visíveis, um **atacante poderia abusar deles**. +- Se nenhum segredo estiver em vigor, o atacante poderia abusar do webhook da plataforma terceira. +- Se o segredo estiver na URL, o mesmo acontece e o atacante também terá o segredo. +- **Code compromise:** Se um ator malicioso tem algum tipo de **write** sobre os repos, ele poderia tentar **injetar código malicioso**. Para ter sucesso pode ser necessário **bypass branch protections**. Essas ações podem ser realizadas com diferentes objetivos: + - Comprometer a main branch para **comprometer a produção**. + - Comprometer a main (ou outras branches) para **comprometer máquinas de desenvolvedores** (pois eles geralmente executam testes, terraform ou outras coisas dentro do repo em suas máquinas). +- **Compromise the pipeline** (veja a próxima seção) -## Metodologia de Pentesting de Pipelines +## Pipelines Pentesting Methodology -A maneira mais comum de definir uma pipeline é usando um **arquivo de configuração CI hospedado no repositório** que a pipeline constrói. Este arquivo descreve a ordem dos trabalhos executados, condições que afetam o fluxo e configurações do ambiente de construção.\ -Esses arquivos geralmente têm um nome e formato consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e os arquivos YAML do GitHub Actions localizados em .github/workflows. Quando acionada, a tarefa da pipeline **puxa o código** da fonte selecionada (por exemplo, commit / branch) e **executa os comandos especificados no arquivo de configuração CI** contra esse código. +A forma mais comum de definir uma pipeline é usando um **CI configuration file hospedado no repositório** que a pipeline constrói. Esse arquivo descreve a ordem dos jobs executados, condições que afetam o fluxo e as configurações do ambiente de build.\ +Esses arquivos tipicamente têm nomes e formatos consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e os YAML do GitHub Actions em .github/workflows. Quando disparado, o job da pipeline **puxa o código** da fonte selecionada (ex.: commit / branch) e **executa os comandos especificados no CI configuration file** contra esse código. -Portanto, o objetivo final do atacante é de alguma forma **comprometer esses arquivos de configuração** ou os **comandos que eles executam**. +Portanto o objetivo final do atacante é de alguma forma **comprometer esses arquivos de configuração** ou os **comandos que eles executam**. -### PPE - Execução de Pipeline Envenenado +### PPE - Poisoned Pipeline Execution -O caminho de Execução de Pipeline Envenenado (PPE) explora permissões em um repositório SCM para manipular uma pipeline CI e executar comandos prejudiciais. Usuários com as permissões necessárias podem modificar arquivos de configuração CI ou outros arquivos usados pela tarefa da pipeline para incluir comandos maliciosos. Isso "envenena" a pipeline CI, levando à execução desses comandos maliciosos. +A Poisoned Pipeline Execution (PPE) explora permissões em um SCM repository para manipular uma CI pipeline e executar comandos maliciosos. Usuários com as permissões necessárias podem modificar CI configuration files ou outros arquivos usados pelo job da pipeline para incluir comandos maliciosos. Isso "envenena" a CI pipeline, levando à execução desses comandos maliciosos. -Para que um ator malicioso tenha sucesso ao realizar um ataque PPE, ele precisa ser capaz de: +Para que um ator malicioso tenha sucesso ao realizar um ataque PPE ele precisa ser capaz de: -- Ter **acesso de escrita à plataforma VCS**, já que geralmente as pipelines são acionadas quando um push ou um pull request é realizado. (Ver a metodologia de pentesting VCS para um resumo das maneiras de obter acesso). -- Note que às vezes um **PR externo conta como "acesso de escrita"**. -- Mesmo que ele tenha permissões de escrita, ele precisa ter certeza de que pode **modificar o arquivo de configuração CI ou outros arquivos dos quais a configuração depende**. -- Para isso, ele pode precisar ser capaz de **contornar as proteções de branch**. +- Ter **write access to the VCS platform**, já que geralmente pipelines são disparadas quando um push ou um pull request é realizado. (Veja a VCS pentesting methodology para um resumo de formas de obter acesso). +- Note que às vezes um **external PR conta como "write access"**. +- Mesmo tendo permissões de escrita, ele precisa ter certeza que pode **modificar o CI config file ou outros arquivos dos quais o config depende**. +- Para isso, pode ser necessário ser capaz de **bypass branch protections**. Existem 3 sabores de PPE: -- **D-PPE**: Um ataque **Direto PPE** ocorre quando o ator **modifica o arquivo de configuração CI** que será executado. -- **I-DDE**: Um ataque **Indireto PPE** ocorre quando o ator **modifica** um **arquivo** do qual o arquivo de configuração CI que será executado **depende** (como um arquivo make ou uma configuração terraform). -- **PPE Público ou 3PE**: Em alguns casos, as pipelines podem ser **acionadas por usuários que não têm acesso de escrita no repositório** (e que podem nem mesmo fazer parte da organização) porque podem enviar um PR. -- **Injeção de Comando 3PE**: Geralmente, as pipelines CI/CD **definem variáveis de ambiente** com **informações sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um **lugar perigoso** (como executar **comandos sh**), um atacante pode **injetar comandos ali**. +- **D-PPE**: Um **Direct PPE** ocorre quando o ator **modifica o CI config** file que será executado. +- **I-DDE**: Um **Indirect PPE** ocorre quando o ator **modifica** um **file** do qual o CI config que será executado **relys on** (como um make file ou uma terraform config). +- **Public PPE or 3PE**: Em alguns casos as pipelines podem ser **disparadas por usuários que não têm write access no repo** (e que podem nem fazer parte da org) porque conseguem enviar um PR. +- **3PE Command Injection**: Normalmente, CI/CD pipelines irão **set environment variables** com **informação sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um lugar **perigoso** (por exemplo ao executar **sh commands**), um atacante pode **injetar comandos ali**. -### Benefícios da Exploração +### Exploitation Benefits -Conhecendo os 3 sabores para envenenar uma pipeline, vamos verificar o que um atacante poderia obter após uma exploração bem-sucedida: +Conhecendo os 3 sabores para envenenar uma pipeline, vejamos o que um atacante poderia obter após uma exploração bem-sucedida: -- **Segredos**: Como mencionado anteriormente, as pipelines requerem **privilégios** para suas tarefas (recuperar o código, construí-lo, implantá-lo...) e esses privilégios geralmente são **concedidos em segredos**. Esses segredos geralmente são acessíveis via **variáveis de ambiente ou arquivos dentro do sistema**. Portanto, um atacante sempre tentará exfiltrar o máximo de segredos possível. -- Dependendo da plataforma da pipeline, o atacante **pode precisar especificar os segredos na configuração**. Isso significa que se o atacante não puder modificar a configuração da pipeline CI (**I-PPE**, por exemplo), ele poderia **apenas exfiltrar os segredos que a pipeline possui**. -- **Computação**: O código é executado em algum lugar, dependendo de onde é executado, um atacante pode ser capaz de pivotar mais. -- **On-Premises**: Se as pipelines são executadas localmente, um atacante pode acabar em uma **rede interna com acesso a mais recursos**. -- **Nuvem**: O atacante poderia acessar **outras máquinas na nuvem**, mas também poderia **exfiltrar** tokens de contas de serviço/roles IAM **dela para obter** **acesso adicional dentro da nuvem**. -- **Máquina da plataforma**: Às vezes, os trabalhos serão executados dentro das **máquinas da plataforma de pipelines**, que geralmente estão dentro de uma nuvem com **nenhum acesso adicional**. -- **Selecione-a:** Às vezes, a **plataforma de pipelines terá várias máquinas configuradas** e se você puder **modificar o arquivo de configuração CI**, poderá **indicar onde deseja executar o código malicioso**. Nessa situação, um atacante provavelmente executará um shell reverso em cada máquina possível para tentar explorá-la mais. -- **Comprometer a produção**: Se você estiver dentro da pipeline e a versão final for construída e implantada a partir dela, você poderia **comprometer o código que acabará sendo executado em produção**. +- **Secrets**: Como mencionado anteriormente, pipelines requerem **privileges** para seus jobs (recuperar o código, build, deploy...) e esses privilégios geralmente são guardados em **secrets**. Esses secrets normalmente ficam acessíveis via **env variables ou arquivos dentro do sistema**. Portanto um atacante sempre tentará exfiltrar o máximo de secrets possível. +- Dependendo da plataforma da pipeline o atacante **pode precisar especificar os secrets no config**. Isso significa que se o atacante não puder modificar a CI configuration pipeline (**I-PPE** por exemplo), ele poderia **apenas exfiltrar os secrets que aquela pipeline possui**. +- **Computation**: O código é executado em algum lugar; dependendo de onde for executado, o atacante pode ser capaz de pivotar ainda mais. +- **On-Premises**: Se as pipelines são executadas on premises, um atacante pode acabar em uma **rede interna com acesso a mais recursos**. +- **Cloud**: O atacante pode acessar **outras máquinas na cloud** e também pode **exfiltrar** tokens de IAM roles/service accounts para obter **mais acesso dentro da cloud**. +- **Platforms machine**: Às vezes os jobs serão executados nas **máquinas da pipelines platform**, que normalmente estão na cloud sem muito mais acesso. +- **Select it:** Às vezes a **pipelines platform terá várias máquinas configuradas** e se você pode **modificar o CI configuration file** pode **indicar onde quer rodar o código malicioso**. Nessa situação, um atacante provavelmente executará um reverse shell em cada máquina possível para tentar explorá-la mais. +- **Compromise production**: Se você estiver dentro da pipeline e a versão final for construída e deployada a partir dela, você pode **comprometer o código que vai rodar em produção**. ## Mais informações relevantes -### Ferramentas & Benchmark CIS +### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta de código aberto para auditar sua pilha de cadeia de suprimentos de software para conformidade de segurança com base em um novo [**benchmark de Cadeia de Suprimentos de Software CIS**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria foca em todo o processo SDLC, onde pode revelar riscos desde o tempo de código até o tempo de implantação. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta open-source para auditar sua cadeia de software para conformidade de segurança baseada em um novo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria foca no processo completo de SDLC, onde pode revelar riscos desde o tempo de código até o tempo de deploy. -### Top 10 Riscos de Segurança CI/CD +### Top 10 CI/CD Security Risk -Confira este artigo interessante sobre os 10 principais riscos de CI/CD de acordo com a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Confira este artigo interessante sobre os top 10 riscos de CI/CD segundo a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- Em cada plataforma que você pode executar localmente, você encontrará como lançá-la localmente para que possa configurá-la como quiser para testá-la. -- Lab Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) +- Em cada plataforma que você puder rodar localmente você encontrará como lançá-la localmente para poder configurá-la como quiser e testar. +- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) -### Ferramentas Automáticas +### Automatic Tools -- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** é uma ferramenta de análise de código estático para infraestrutura como código. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** é uma ferramenta de análise estática para infrastructure-as-code. -## Referências +## References - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) + {{#include ../banners/hacktricks-training.md}}