A maioria das equipes imagina uma vulnerabilidade de escalonamento de privilégios como um bug no kernel ou um uso indevido de um recurso. sudo em um servidor de produção. Em 2026, a versão mais perigosa estará em outro lugar: no pipeline que compila e envia seu código. Um CI/CD O job normalmente detém acesso de escrita aos seus repositórios, tokens para seus registros de pacotes e credenciais para sua nuvem. Um invasor que consiga executar código dentro desse job não precisa escalar muito. pipeline já fez isso por eles.
Este guia explica como é uma vulnerabilidade de escalonamento de privilégios em CI/CD pipelineEste guia aborda os caminhos mais comuns usados por atacantes, incluindo contêineres, e mostra como fechar cada um deles.
Resumo: vulnerabilidade de escalonamento de privilégios em CI/CD pipelines
Em um artigo do pipeline, o atacante geralmente não precisa escalar privilégios. pipeline já os tem. Uma vulnerabilidade de escalonamento de privilégios em CI/CD Geralmente, trata-se de uma permissão mais ampla do que a necessária para a tarefa, permitindo a execução de código não confiável dentro dela.
- PipelineSão privilegiados por natureza. Eles leem o código-fonte, detêm segredos, publicam artefatos e implantam em produção, o que os torna um dos alvos de escalonamento mais valiosos em sua organização.
- A maioria das vias de escalonamento são configurações incorretas, não explorações de vulnerabilidades. Tokens padrão amplos,
pull_request_targetFluxos de trabalho que executam código bifurcado e chaves de nuvem de longa duração causam mais danos do que qualquer vulnerabilidade zero-day. - A escalação de privilégios de contêiner transforma uma tarefa em todo o processo. Contêineres privilegiados, usuários root e um socket Docker montado transformam o contêiner de construção em uma porta de entrada, não em uma barreira.
- Isso já acontece em grande escala. O worm CHAINDROP utilizava acesso privilegiado nos executores do GitHub Actions para ler as credenciais diretamente da memória do executor.
- A solução é o princípio do menor privilégio, aplicado continuamente. Analise o escopo de cada token, reforce a segurança de cada contêiner e detecte desvios de permissão antes que um invasor os encontre.
O que é uma vulnerabilidade?
Uma vulnerabilidade de escalonamento de privilégios é qualquer fraqueza que permita a um usuário, processo ou trecho de código obter permissões além daquelas para as quais foi projetado. O MITRE ATT&CK monitora esse tipo de vulnerabilidade como uma tática específica. TA0004: Escalada de PrivilégiosPorque é o passo que transforma um pequeno ponto de apoio em um dano real.
Existem duas formas clássicas:
- Escalada vertical: subir de nível, por exemplo, de um usuário comum para root, ou de um token somente leitura para um que possa escrever.
- Escalada horizontal: movimentação lateral, por exemplo, usando o acesso de uma tarefa para alcançar o repositório, os segredos ou o ambiente de outra equipe.
Os atacantes exploram uma vulnerabilidade de escalonamento de privilégios por meio de três tipos de fraquezas: bugs de software, configurações incorretas e permissões excessivas. Em servidores, os bugs recebem a maior atenção. CI/CD pipelineConfigurações incorretas e permissões excessivas são praticamente as únicas responsáveis pelo problema.
Por que é tão perigoso em CI/CD pipelines
A pipeline Não é apenas uma ferramenta de construção. É uma identidade automatizada com um dos maiores níveis de acesso em sua empresa. Uma tarefa típica pode:
- Confira e modifique o código-fonte.
- Leia segredos de variáveis de ambiente, cofres e serviços de metadados na nuvem.
- Publicar pacotes, imagens e artefatos de lançamento
- Implantação em ambientes de teste e produção.
O Top 10 OWASP CI/CD Riscos de segurança nomeia esse problema diretamente. Seu risco CICD-SEC-5: Insuficiente PipelineControles de acesso baseados em descreve como os atacantes que executam código malicioso em um pipeline abusar das permissões concedidas para se mover lateralmente, dentro ou fora do CI/CD sistema.
Isso não é teórico. Durante a campanha CHAINDROP em agosto de 2026, o malware Credenciais temporárias extraídas da memória do executor do GitHub Actions e usaram tokens de publicação roubados para infectar mais pacotes. Em executores Linux, o payload executou seu coletor através de sudo para ler a memória do processo executor. Isso é escalonamento de privilégios em CI/CD pipelineEm sua forma mais pura: uma dependência perniciosa, acesso privilegiado ao informante e a todos os segredos que o trabalho possa alcançar. É o mesmo padrão que observamos em nossas descobertas semanais sobre pacotes npm maliciosos.
Onde se esconde uma vulnerabilidade de escalonamento de privilégios em um pipeline?
Seis caminhos comuns, o que cada um deles desbloqueia para um atacante e o controle que os fecha.
| Caminho de escalada | Como isso acontece | O que o atacante obtém | Como fechar |
|---|---|---|---|
| Privilegiado demais pipeline token digital único, | Os fluxos de trabalho são executados com escopos de token padrão amplos porque não permissions bloco está configurado | Autorização de escrita para acessar o código, as versões e outros fluxos de trabalho. | Defina as configurações padrão de somente leitura e conceda acesso de gravação por tarefa, somente quando necessário. |
| Envenenado pipeline execução | pull_request_target ou gatilhos semelhantes verificam e executam código de um fork não confiável. | Segredos do repositório e um token de gravação, a partir de um único pull request | Nunca execute código fork em um contexto privilegiado; separe tarefas confiáveis de tarefas não confiáveis. |
| escalonamento de privilégios de contêiner | Os contêineres de construção são executados como root, em modo privilegiado ou com o socket do Docker montado. | Acesso root no host do executor e acesso a todos os trabalhos que ele executa. | Executar como usuário não root, descartar recursos e bloquear a escalação de privilégios na especificação do contêiner. |
| Credenciais de nuvem de longa duração | Chaves estáticas na nuvem armazenadas como segredos ou variáveis de ambiente. | Acesso persistente a contas na nuvem, mesmo depois do término do trabalho. | Use credenciais federadas de curta duração e revogar segredos expostos automaticamente |
| Corredores persistentes que se hospedam por conta própria | Os executores são reutilizados em diferentes trabalhos e repositórios sem serem reconstruídos. | Persistência e a capacidade de interferir nas estratégias de outras equipes. | Use corredores efêmeros e isole-os por nível de confiança. |
| relatos humanos privilegiados | Administradores inativos, colaboradores externos e alterações de permissão não revisadas se acumulam. | Uma conta válida que pode ser alterada. pipelines e proteções de filial | Monitore o acesso continuamente e receba alertas sobre alterações anômalas nas permissões. |
Elevação de privilégios do contêiner: quando o contêiner de compilação não é um limite.
Os contêineres dão a sensação de isolamento, por isso as equipes costumam tratá-los como uma barreira de segurança. CI/CD, frequentemente não são. A escalação de privilégios de contêiner ocorre quando o código dentro de um contêiner de compilação ganha controle do host e, com ele, de todos os outros trabalhos que são executados nele.
Na maioria dos casos, existem três configurações principais:
- Executando como root. Se o processo dentro do contêiner for root, qualquer tentativa de fuga começará a partir da posição mais forte possível.
- Modo privilegiado. Um contêiner privilegiado tem praticamente o mesmo nível de acesso ao host que um processo executado diretamente nele.
- Um socket Docker montado. Montagem
/var/run/docker.sockAo criar um trabalho para que ele possa construir imagens, ele efetivamente concede privilégios de root ao host, pois pode iniciar novos contêineres privilegiados.
Pesquisadores de segurança demonstraram como isso se desenrola em sistemas de CI reais. Em um caso bem documentado, os pesquisadores passaram de scripts de compilação executados dentro de um contêiner de CI para um Escape completo do contêiner nos hosts de compilação do Cloudflare Pagesprecisporque o contêiner estava sendo tratado como limite de segurança.
Eis como se parece uma especificação de tarefa Kubernetes reforçada. A configuração principal é allowPrivilegeEscalation: false, o qual impede que um processo adquira mais privilégios do que seu processo pai., por exemplo, através de binários setuid.
# Pod de compilação reforçado: bloqueia os caminhos de escalonamento de privilégios mais comuns em contêineres apiVersão: v1 tipo: Vagem metadados: nome: ci-build especulação: contexto de segurança: executarComoNãoRoot: verdadeiro executarComoUsuário: 10001 perfil seccomp: tipo: RuntimeDefault containers: - nome: construir imagem: registry.example.com/build-image@sha256: contexto de segurança: permitirEscalaçãoDePrivilégios: falso privilegiado: falso sistema de arquivos raiz somente leitura: verdadeiro capacidades:
O mesmo princípio se aplica ao próprio Dockerfile. Adicione um usuário não root e alterne para ele antes do ponto de entrada:
# Execute o contêiner como um usuário sem privilégios de root A PARTIR DE nó:22-slim CORRE useradd --uid 10001 --criar-casa construtor DIRTRABALHO / aplicativo CÓPIA --chown=construtor:construtor . . USUÁRIO construtor CMD ["nós", "index.js"]
A documentação do Kubernetes sobre configurando um contexto de segurança Aborda cada uma dessas configurações em detalhes.
GitHub Actions: uma vulnerabilidade de escalonamento escondida à vista de todos.
O GitHub Actions é onde muitas equipes se deparam pela primeira vez com a escalada de privilégios. CI/CD pipelines, porque os padrões perigosos parecem completamente comuns. Dois deles valem a pena verificar em todos os repositórios hoje em dia.
Escopo do token. Cada fluxo de trabalho recebe um GITHUB_TOKENAs próprias orientações do GitHub sobre autenticação automática por token É claro: uma ação pode alcançar esse token mesmo que você não o passe explicitamente, portanto, você deve sempre limitar suas permissões ao mínimo. Definir permissões somente leitura no início do fluxo de trabalho e conceder acesso de gravação por tarefa remove o caminho de escalonamento mais comum em uma única etapa:
nome: construir on: [empurrar] # Padrão para todas as tarefas: somente leitura permissões: conteúdo: ler empregos: teste: corre em: ubuntu-latest passos: # Fixar ações de terceiros em um local fixo commit SHA, não é uma tag mutável - utiliza: ações/finalizar compra@commit-sha> - corrida: npm ci && npm test liberar: Cria: teste corre em: ubuntu-latest # Somente este trabalho pode escrever, e somente o que ele precisa permissões: conteúdo: escrever passos: - utiliza: ações/finalizar compra@commit-sha> - corrida: ./scripts/release.sh
Gatilhos não confiáveis. Fluxos de trabalho acionados por pull_request_target executar com os segredos do repositório de destino e um token com permissão de gravação, mesmo quando o pull request vem de um fork. Se esse fluxo de trabalho for verificado e executar o código do fork, qualquer pessoa poderá abrir um pull request e executar código com seus privilégios. Essa é uma vulnerabilidade de escalonamento de privilégios que não precisa de exploração alguma, apenas de um pull requestMantenha as etapas privilegiadas em código confiável e execute código não confiável em um fluxo de trabalho separado, sem segredos.
Se você quiser observar esses padrões em um local seguro, o xygeni-cabra repositório coleta dados deliberadamente inseguros pipeline e IaC configurações para treinamento. Para uma análise mais abrangente da sua configuração do GitHub, consulte nosso guia sobre Como saber se um aplicativo ou repositório do GitHub é seguro?.
Como prevenir uma vulnerabilidade de escalonamento de privilégios em CI/CD pipelines
Encerramento da escalação de privilégios em CI/CD pipelineTudo se resume a um princípio: o do menor privilégio, aplicado em todas as camadas e verificado continuamente, em vez de apenas uma vez. Uma lista de verificação prática:
- Defina o escopo de cada token. Por padrão, somente leitura, acesso de gravação por tarefa e sem tokens para toda a organização em fluxos de trabalho do repositório.
- Separe o código confiável do código não confiável. Nunca execute código de forks ou de colaboradores externos em um trabalho que contenha segredos.
- Reforce a segurança de todos os contêineres de compilação. Usuários sem privilégios de root, sem modo privilegiado, sem socket Docker, recursos descartados.
allowPrivilegeEscalation: false. - Substitua segredos antigos. Dê preferência a credenciais federadas de curta duração e revogue imediatamente qualquer credencial exposta.
- Fixe o que você executar. Referência a ações e imagens de terceiros por commit SHA ou resumo, para que uma tag comprometida não possa alterar seu pipeline.
- Fique atento à deriva. As permissões se ampliam com o tempo. Alerta sobre novos administradores, proteções de ramificação enfraquecidas e mudanças inesperadas no fluxo de trabalho.
- Portão o pipeline. Interrompa a compilação quando uma configuração incorreta crítica for detectada, antes que ela seja mesclada.
A parte difícil não é conhecer essas regras. É aplicá-las em centenas de repositórios e fluxos de trabalho que mudam todos os dias.
Como o Xygeni impede uma vulnerabilidade de escalonamento de privilégios em CI/CD?
Cada caminho de escalonamento é associado à funcionalidade do Xygeni que o detecta ou bloqueia.
| Gestão de | O que a Xygeni faz |
|---|---|
| Pipeline configurações erradas | Detectores de configuração incorreta Analisar definições de tarefas de CI, scripts de compilação e arquivos de configuração no GitHub, GitLab, Azure DevOps, Bitbucket, CircleCI e Jenkins, e sinalizar permissões mais amplas do que as permitidas pelas melhores práticas. |
| escalonamento de privilégios de contêiner | IaC e verificações de contêineres Abrange Dockerfiles, arquivos docker-compose, manifestos do Kubernetes e gráficos Helm, incluindo contêineres executados como root. |
| Usuários com privilégios excessivos e inativos | A análise de privilégio mínimo identifica usuários inativos e usuários com privilégios excessivos, e o Health Check transforma cada descoberta em um bilhete |
| Desvio de permissão | Alertas de detecção de anomalias sobre alterações incomuns de permissões, fusões anômalas e instalações inesperadas de plugins. |
| Credenciais expostas | A detecção de segredos abrange o código, pipelinee imagens de contêiner, com revogação automática para tipos de segredo suportados |
| Código malicioso no pipeline | Bloqueia shells reversos e downloads de malware em pipelineem tempo real, e o MEW detecta pacotes maliciosos antes mesmo que uma assinatura exista. |
| execução | Pre-commit hooks e CI guardrails Interrompa a compilação em caso de problemas críticos, com políticas YAML personalizadas para suas próprias regras. |
As verificações estão alinhadas com o Top 10 OWASP CI/CD Riscos de segurança e standards tais como CIS, NIST e OpenSSFCada descoberta contribui para Xygeni ASPM, onde é priorizado juntamente com as descobertas de código, dependências e segredos, de modo que a vulnerabilidade de escalonamento de privilégios que de fato chega à produção seja corrigida primeiro.
A maioria das escaladas de privilégios em CI/CD pipelineO arquivo s já está presente nos seus arquivos de fluxo de trabalho, aguardando a execução de código não confiável.
Perguntas frequentes
O que é uma vulnerabilidade de escalonamento de privilégios em [inserir aqui o nome da plataforma/sistema]? CI/CD?
É qualquer vulnerabilidade que permita que o código em execução em um pipeline Obter mais acesso do que o necessário para a tarefa, como um token com privilégios excessivos, um fluxo de trabalho que executa código não confiável com segredos ou um contêiner de compilação que pode acessar o host.
O que é escalonamento de privilégios em contêineres?
A escalada de privilégios em contêineres ocorre quando um processo dentro de um contêiner adquire privilégios mais elevados, geralmente privilégios de root no host. Causas comuns incluem execução como root, modo privilegiado e um socket Docker montado.
Será que allowPrivilegeEscalation: false Como impedir o escape de contêineres?
Ele bloqueia um caminho importante: um processo que obtém mais privilégios do que seu processo pai, por exemplo, através de binários setuid. Funciona melhor em combinação com um usuário não root, recursos descartados e sem modo privilegiado.
Is pull_request_target sempre perigoso?
Não por si só. Torna-se uma vulnerabilidade de escalonamento de privilégios quando o fluxo de trabalho é verificado e executa código a partir do pull request, porque esse código é executado com seus segredos e um token com permissão de escrita.
Como posso encontrar caminhos de escalonamento de privilégios em vários repositórios?
As avaliações manuais não são escaláveis. Uma avaliação automatizada... CI/CD A ferramenta de segurança analisa continuamente todos os fluxos de trabalho, especificações de contêineres e conjuntos de permissões, e envia alertas quando algo se torna inacessível.
