Exposição de Credenciais em CI/CD: O que os Atacantes Roubam dos Pipelines e o que Rotacionar

A exposição de credenciais de CI/CD é o vazamento de segredos mantidos em pipelines, incluindo chaves de nuvem, tokens de acesso e materiais de assinatura, para partes fora do limite de confiança da compilação. A exposição de credenciais de CI/CD ocorre por meio dos próprios builds: dependências, logs, artefatos, arquivos de fluxo de trabalho e as plataformas que os executam. A exposição difere do roubo confirmado, e essa diferença orienta a resposta, já que uma credencial vazada exige rotação, independentemente de o uso indevido ter sido comprovado ou não.

A escala não é teórica. Relatório de violação da cadeia de suprimentos de IA da CloudSEK reconstruiu o ataque à cadeia de suprimentos do LiteLLM em março de 2026, atribuído ao grupo de ameaças TeamPCP, que potencialmente expôs mais de 2.500 organizações e cerca de 434.000 pipelines de CI/CD, incluindo um conjunto verificado de empresas indianas. Versões envenenadas do LiteLLM, ativas no PyPI por cerca de 40 minutos, permitiram que invasores capturassem chaves SSH, chaves de nuvem, tokens de repositório, tokens do Kubernetes e chaves de provedores de IA diretamente dos executores de build. Esse incidente ancora a exposição que este artigo analisa: o que os pipelines contêm, como vazam e o que rotacionar primeiro.

Os pipelines concentram privilégios por design. Um job de implantação precisa legitimamente das chaves para código, nuvem, registros e produção ao mesmo tempo, portanto, a automação que entrega software funciona também como um depósito de credenciais. Os invasores tratam o sistema exatamente dessa forma.

Onde as credenciais residem dentro de um pipeline

Um pipeline mantém segredos em 5 locais, e cada um falha de maneira diferente. Armazenamentos de segredos, arquivos de configuração, memória de processo, logs e artefatos, e caches merecem uma linha no inventário de exposição.

• Armazenamentos de segredos da plataforma e variáveis de ambiente: Criptografados em repouso dentro da plataforma de CI, descriptografados no ambiente do job em tempo de execução. Qualquer código executado dentro do job os lê em texto simples.
• Arquivos de fluxo de trabalho e configuração: Tokens codificados (hardcoded) em YAML, scripts e arquivos .env enviados para repositórios. O histórico de versões preserva um segredo muito tempo depois que um commit de limpeza o remove. Os arquivos de configuração do MCP (Model Context Protocol) juntaram-se a este local em 2025, vazando 24.008 segredos únicos no GitHub público, segundo a contagem da GitGuardian.
• Memória do processo do executor (runner): Credenciais ativas mantidas por processos de build durante a duração de um job. A varredura de memória recupera valores que nunca tocam um log ou arquivo. No incidente do LiteLLM, o malware do TeamPCP extraiu segredos diretamente da memória do processo em /proc/<pid>/mem, incluindo os valores que o GitHub Actions tenta mascarar.
• Logs de build e artefatos: Segredos impressos por saídas de depuração, despejos de erro ou etapas mal configuradas, e então armazenados onde quer que logs e artefatos persistam. As configurações de retenção decidem por quanto tempo um erro pontual permanece legível.
• Caches e imagens de executor: Caches de dependência, camadas de contêiner e snapshots de máquinas virtuais que carregam credenciais além do job que os criou. Um pull de cache lê os segredos de ontem hoje.

Um inventário que cobre apenas o armazenamento de segredos ignora os outros quatro locais. Planos de rotação baseados em inventários parciais rotacionam parcialmente.

O que os atacantes roubam dos pipelines

Os atacantes roubam 7 classes principais de credenciais dos pipelines: tokens de plataforma, chaves de nuvem, credenciais de sistemas de controle de versão (VCS), materiais de assinatura, tokens de registro, tokens do Kubernetes e chaves de provedores de SaaS (software como serviço) e IA. A tabela mapeia cada classe ao acesso que ela concede e à onda de rotação à qual pertence.

As prioridades interagem porque as classes de credenciais estão encadeadas. Um token de VCS reescreve um fluxo de trabalho, o fluxo de trabalho lê o cofre de segredos e o cofre contém todas as outras classes da tabela. A ordem de rotação existe para quebrar essas cadeias antes que os atacantes as percorram. O incidente do LiteLLM começou exatamente desta forma: um token de automação vazado, rotacionado, mas não totalmente revogado, deu ao atacante uma janela de aproximadamente 20 dias para enviar código malicioso sobre as tags de versão publicadas do scanner Trivy.

Como as credenciais de pipeline vazam

As credenciais de pipeline vazam por 6 caminhos, e um incidente documentado comprova cada um deles. Um ataque à cadeia de suprimentos fornece o mecanismo de entrega em três dos seis.

Dependências maliciosas e código em tempo de instalação

Um pacote envenenado é executado durante a instalação dentro do executor e herda todos os segredos que o trabalho possui. O campanha TeamPCP de março de 2026 executou essa estratégia em escala. Um scanner de segurança Trivy comprometido, instalado sem fixação de versão no próprio pipeline de CI do LiteLLM, envenenou a compilação do LiteLLM, que então publicou as versões maliciosas 1.82.7 e 1.82.8 no PyPI. 

O payload foi executado a partir de um arquivo .pth malicioso que é iniciado na inicialização do interpretador Python, portanto, a instalação por si só o acionou, sem necessidade de importação, e a proteção ignore-scripts na qual as equipes confiam nunca foi aplicada. Nenhuma vulnerabilidade é necessária, apenas a presença na árvore de dependências. As chaves de nuvem foram lidas diretamente do serviço de metadados da instância e os tokens do Kubernetes de caminhos de conta de serviço montados, usando apenas o acesso que cada executor já possuía.

Injeção de fluxo de trabalho e ações comprometidas

Atacantes com acesso ao repositório modificam arquivos de fluxo de trabalho para enviar segredos para fora ou comprometem uma ação compartilhada consumida por milhares de compilações. A campanha GhostAction de setembro de 2025 roubou 3.325 segredos em 817 repositórios por meio de arquivos de fluxo de trabalho injetados, e o comprometimento do tj-actions de março de 2025 despejou segredos em logs de compilação públicos.

Logs e artefatos

Os segredos ecoam na saída da compilação por meio de sinalizadores de depuração, erros detalhados e instruções de impressão descuidadas, e então persistem onde quer que os logs sejam armazenados. O Travis CI expôs cerca de 73.000 tokens e credenciais por meio de logs de compilação que a plataforma mantinha acessíveis por design. A retenção transformou uma decisão de registro em uma violação permanente.

Comprometimento da plataforma de CI

Uma violação do próprio provedor de CI expõe todos os segredos dos clientes que a plataforma armazena. O incidente do CircleCI de janeiro de 2023 começou com o laptop de um engenheiro infectado por malware e um cookie de sessão roubado, e terminou com os clientes rotacionando todos os segredos que já haviam armazenado na plataforma.

Tokens com escopo excessivo e pull requests bifurcados

Tokens de longa duração com escopo amplo transformam um pequeno ponto de apoio em acesso amplo, e pipelines que passam segredos para pull requests bifurcados os entregam a estranhos. A vulnerabilidade CVE-2024-9164 do GitLab permitiu que usuários não autorizados acionassem pipelines em branches arbitrários, alcançando segredos configurados para os protegidos.

Worms autopropagáveis

Malware que rouba os tokens de um desenvolvedor e os usa para envenenar outros pacotes desse desenvolvedor se multiplica por todo o ecossistema. O worm Shai-Hulud npm de 2025 coletou tokens de acesso pessoal e executou um scanner de segredos de código aberto de forma ofensiva dentro dos ambientes das vítimas para encontrar mais.

Por que a detecção fica atrás do roubo

O roubo de credenciais em pipelines evita a detecção porque o roubo é uma compilação. A etapa maliciosa é executada dentro de um job agendado, em um runner esperado para executar código, com credenciais que o job recebeu legitimamente. Nenhum alarme diferencia a leitura de um segredo para implantação da leitura de um segredo para roubo.

A ocultação de logs (masking) aprofunda a falsa sensação de segurança. A ocultação remove segredos da saída da compilação, mas não faz nada em relação à memória do processo, onde os valores permanecem em texto simples durante a execução. O malware LiteLLM provou isso, extraindo valores ocultos do GitHub Actions diretamente de /proc/<pid>/mem. Ladrões leem a memória, não os logs.

Três sinais, no entanto, cortam o ruído: uso de tokens a partir de infraestrutura que a equipe nunca provisionou, alterações em arquivos de workflow que nenhum engenheiro reconhece e repositórios ou identidades que surgiram sem um chamado. Cada um deles pode ser verificado hoje nos logs de auditoria. O último sinal não é hipotético: onde a exfiltração falhou, o malware LiteLLM criou um repositório público dentro da própria conta do GitHub da vítima, com nomes como tpcp-docs ou docs-tpcp, e enviou os dados roubados para lá como um ativo de release.

A varredura cobre o caminho errado para este problema. Scanners de segredos observam o caminho de escrita, sinalizando credenciais à medida que chegam ao código e aos logs, enquanto o roubo acontece no caminho de leitura dentro de um job em execução. Ambos importam; apenas um possui ferramentas por padrão.

O tempo completa o disfarce. Tokens roubados geram chamadas de API (interface de programação de aplicações) em vez de logins, portanto, nenhum sinal de falha de autenticação é disparado, e os atacantes geralmente validam as credenciais silenciosamente semanas após o vazamento. O alerta de julho de 2026 do FBI FLASH sobre o TeamPCP (FLASH-20260702-01) alertou que atores afiliados provavelmente usarão as credenciais coletadas muito tempo após a intrusão original. Equipes que limitam a revisão do incidente ao dia da exposição perdem a janela em que o uso indevido realmente ocorre.

O que rotacionar após a exposição do pipeline: ordem de prioridade

Após a exposição do pipeline, as equipes rotacionam as credenciais em 5 ondas: tokens de plataforma, chaves de nuvem, credenciais de VCS, material de assinatura e chaves de serviços downstream. Cinco verbos ordenam o trabalho: revogar, rotacionar, substituir, reemitir, atualizar. As ondas classificam a urgência em vez de uma ordem serial estrita, permitindo que diferentes responsáveis cuidem das ondas posteriores em paralelo assim que a onda 1 for concluída.

A ordem não é arbitrária. Em cada runner comprometido no incidente do LiteLLM, o ladrão do TeamPCP escalou privilégios para root e varreu chaves SSH, credenciais AWS, GCP e Azure, tokens Kubernetes, arquivos .env, segredos de CI/CD e chaves de provedores de IA, e cada uma dessas classes mapeia para uma das ondas abaixo. A sequência de rotação define quais delas um atacante mantém após a limpeza.

Revogue sessões e tokens de plataforma primeiro

Revogue todos os tokens de API da plataforma de CI, permissões de aplicativos OAuth, tokens de registro de runner e sessões ativas antes de reconstruir qualquer coisa. A revogação corta o acesso ativo do atacante; a substituição por si só deixa o valor antigo funcionando até a expiração. A cadeia do LiteLLM começou com um token que foi rotacionado, mas não totalmente revogado. Os logs de auditoria da plataforma obtidos nesta onda definem a janela de exposição da qual todas as ondas subsequentes dependem.

Rotacione chaves de acesso à nuvem e busque novas identidades 

Rotacione todas as chaves de nuvem legíveis pelo pipeline e, em seguida, audite o IAM (gerenciamento de identidade e acesso) em busca de usuários, funções e chaves criadas durante a janela de exposição. Atacantes plantam novas identidades para que a rotação da chave roubada não altere nada.

Substitua credenciais de VCS e audite repositórios

Substitua tokens de acesso pessoal, chaves de implantação, chaves SSH e segredos de webhook, e revise commits, alterações de workflow e novos repositórios no mesmo período. Um único token de repositório sobrevivente reinicia todo o incidente.

Reemita chaves e certificados de assinatura

Trate o material de assinatura como a onda lenta e de alta consequência: revogue certificados, reemita chaves e assine novamente os artefatos atuais para que os consumidores rejeitem qualquer coisa assinada pelo atacante. Os consumidores precisam das novas âncoras de confiança antes que as antigas expirem, portanto, a sequência supera a velocidade aqui.

Atualize credenciais de serviços e downstream

Finalize com tokens de registro, tokens de conta de serviço do Kubernetes, integrações SaaS, chaves de provedores de IA e variáveis de ambiente recriadas. As chaves de IA merecem uma verificação própria, já que chaves de API de IA vazadas raramente disparam alertas de login quando reutilizadas. Sistemas downstream aceitam valores antigos até que cada um seja substituído individualmente.

O inventário precede todas as 5 ondas, já que as equipes só rotacionam o que sabem que existe. O aviso de rotação do CircleCI estabeleceu o modelo, guiando os clientes através de tokens, variáveis, contextos, chaves SSH e tokens de runner, um local de cada vez, combinado com a revisão de logs desde o primeiro dia da invasão. O roubo de tokens do Salesloft Drift em 2025 forçou o mesmo procedimento em centenas de instâncias conectadas do Salesforce, o que demonstra como um modelo de rotação é transferível. Os retestes do GitGuardian mostram por que essa disciplina é importante: 64% das credenciais vazadas em 2022 ainda funcionavam em janeiro de 2026.

Blindagem: Torne as Credenciais Roubadas Inúteis

A blindagem baseia-se em 5 controles que reduzem o valor de uma credencial roubada. A prevenção aqui significa desvalorização, não apenas proteção.

Substitua Segredos Estáticos por Identidade de Curta Duração

Emita credenciais de pipeline por meio de federação OIDC (OpenID Connect) para que cada job receba um token com escopo próprio que expira em minutos. Um token roubado que expira antes da validação é um nada roubado. Vincule as declarações de assunto (subject claims) de cada token ao repositório, branch e ambiente que ele atende, e um token criado para um job falhará em qualquer outro lugar.

Limite o Escopo de Cada Token a um Único Job

Conceda a cada token a função, o repositório e o ambiente mínimos que seu job exige, e separe as etapas de implantação privilegiadas das etapas de build não privilegiadas. O escopo converte um comprometimento total em um parcial. Ambientes protegidos e regras de branch colocam as credenciais de implantação atrás de condições que uma etapa de build sequestrada não consegue cumprir.

Isole Segredos de Etapas Não Confiáveis

Não forneça segredos para pull requests de forks, ações de terceiros e qualquer etapa que instale código não revisado. Fixe dependências e ações compartilhadas em hashes verificados, já que o pipeline do LiteLLM baixou seu scanner comprometido sem fixação e herdou o código malicioso automaticamente. 

Exija portões de aprovação antes que fluxos de trabalho de colaboradores externos acessem contextos que contêm segredos. Gatilhos de fluxo de trabalho que executam contribuições externas com permissões elevadas merecem uma revisão rigorosa, já que entregam um contexto privilegiado ao código de um fork.

Instale Honeytokens em Repositórios de Pipeline

Injete nos repositórios de segredos credenciais falsas que disparam alertas no momento em que algo as utiliza. A chave AWS falsa de um cliente revelou a violação do CircleCI antes mesmo que a própria plataforma detectasse a invasão. 

Evidências de campo raramente favorecem um controle tão claramente. Coloque iscas ao lado de credenciais reais em repositórios, variáveis e arquivos de configuração, e direcione seus alertas para um canal que alguém monitore.

Digitalize Repositórios, Logs e Artefatos Continuamente

Execute a varredura de segredos em commits, histórico do git, logs de build e artefatos publicados, já que commits de limpeza não apagam nada do histórico. Equipes que rastreiam credenciais vazadas em códigos públicos e sites de compartilhamento de texto detectam exposições que scanners internos nunca veem. Combine a varredura com proteção de push para que um segredo detectado bloqueie o commit em vez de apenas documentá-lo.

Onde a CloudSEK Vê Credenciais de Pipeline Ressurgirem

A rotação fecha o ciclo interno, mas deixa uma pergunta em aberto: se a rotação superou o invasor. As respostas para essa pergunta estão fora do pipeline, porque credenciais roubadas ressurgem em logs de malwares, mercados da dark web, sites de compartilhamento de texto e repositórios públicos. O incidente do LiteLLM provou isso literalmente, com as próprias contas do GitHub das vítimas hospedando seus segredos roubados em repositórios públicos criados pelos invasores.

CloudSEK XVigil monitora essa superfície externa, detectando credenciais vazadas de uma organização em fontes da dark web, plataformas de código e mercados clandestinos, transformando a rotação de um ato de fé em um resultado verificável. CloudSEK Threat Intelligence rastreia as campanhas por trás dos vazamentos, incluindo o TeamPCP, para que uma credencial encontrada chegue acompanhada do contexto do atacante. Especificamente para a camada de IA, CloudSEK AIVigil monitora a superfície de ataque de IA onde essas credenciais se concentram, incluindo infraestrutura de IA exposta, servidores MCP e chaves de provedores de IA vazadas.

O XVigil complementa o endurecimento de pipelines em vez de substituí-lo. OIDC, escopo e varredura reduzem o que vaza; o monitoramento externo responde à pergunta que esses controles deixam em aberto: o que vazou mesmo assim e quem está com isso agora.

Conclusão

A exposição de credenciais em CI/CD transforma uma compilação confiável em um depósito de chaves de nuvem, código, registro e produção. O incidente do LiteLLM mostrou quão curto é o pavio: um token não revogado tornou-se um lançamento envenenado, uma janela de pacote medida em minutos tornou-se um conjunto de exposição medido em centenas de milhares de pipelines, e o FBI avalia que as credenciais roubadas sobreviverão ao malware que as capturou.

A premissa de trabalho que sobrevive ao contato com incidentes reais é simples: trate qualquer credencial acessível a partir de um pipeline comprometido como já exposta, revogue antes de rotacionar, ordene as ondas pelo raio de impacto e monitore fontes externas para aquelas que vazaram mesmo assim.