.png)
Ataques à cadeia de software em CI/CD estão explorando ferramentas confiáveis para roubar credenciais, tokens e segredos usados em pipelines corporativos.
O alerta recente envolvendo Bitwarden CLI e Checkmarx KICS mostra uma mudança importante no cenário de segurança. O problema não está apenas no servidor exposto, no endpoint desatualizado ou na senha fraca. O problema também está nas ferramentas que a própria equipe de TI usa para desenvolver, testar, publicar e automatizar sistemas.
Segundo a Socket, a versão @bitwarden/cli@2026.4.0 foi comprometida em uma campanha ligada ao Checkmarx, com código malicioso publicado no arquivo bw1.js e indícios de abuso de GitHub Actions no pipeline de CI/CD. O payload foi descrito como capaz de coletar tokens do GitHub, credenciais de AWS, Azure e Google Cloud, arquivos .npmrc, chaves SSH, variáveis de ambiente e configurações relacionadas a Claude/MCP.
O caso do Checkmarx KICS também reforça o risco. A Docker informou que imagens maliciosas foram publicadas no repositório checkmarx/kics, com tags conhecidas sobrescritas e um binário adulterado que mantinha a função de scanner, mas adicionava coleta e exfiltração silenciosa de dados. Como o KICS analisa arquivos Terraform, CloudFormation e Kubernetes, o risco envolve credenciais, nomes de recursos de nuvem e topologia interna.
O que é um ataque à cadeia de software
Um ataque à cadeia de software é uma campanha maliciosa que compromete componentes usados para criar, testar, distribuir ou executar software.
Um ataque à cadeia de software pode atingir bibliotecas open source, imagens de container, plugins de IDE, ferramentas de segurança, scripts de automação, runners de CI/CD, pacotes npm, repositórios Git e credenciais de publicação.
O ataque à cadeia de software é perigoso porque o código malicioso pode chegar ao ambiente corporativo por um caminho aparentemente legítimo. A equipe de TI instala uma ferramenta conhecida, o pipeline executa uma dependência confiável e o processo de build segue funcionando. Enquanto isso, tokens, segredos e credenciais podem ser coletados sem gerar sinais óbvios para quem olha apenas o resultado final da aplicação.
Por que CI/CD virou alvo dos atacantes
Pipelines CI/CD concentram credenciais, permissões e automações críticas para desenvolvimento e operação.
Um pipeline CI/CD pode ter acesso a repositórios de código, registries de pacotes, imagens Docker, ambientes cloud, clusters Kubernetes, chaves SSH, variáveis de ambiente e tokens de publicação. Quando um pipeline CI/CD executa uma ferramenta comprometida, o impacto pode ultrapassar o time de desenvolvimento e alcançar infraestrutura, segurança, operação e governança.
O NIST Secure Software Development Framework, conhecido como SSDF, recomenda práticas de desenvolvimento seguro que podem ser incorporadas ao ciclo de vida de software para reduzir vulnerabilidades, mitigar impacto de exploração e tratar causas raiz de falhas recorrentes. Essa visão reforça que segurança de software não termina no código da aplicação. Segurança de software também envolve processo, cadeia de fornecedores, build, entrega e operação.
O que os casos Bitwarden CLI e Checkmarx KICS ensinam
Os casos Bitwarden CLI e Checkmarx KICS ensinam que uma ferramenta confiável pode se tornar uma dependência privilegiada e perigosa quando roda dentro de pipelines automatizados.
No caso do Bitwarden CLI, o problema relatado não foi simplesmente o uso de um pacote desconhecido. O alerta envolveu uma ferramenta conhecida, usada por equipes técnicas, distribuída por um canal legítimo e executada em contextos onde credenciais costumam estar disponíveis.
No caso do Checkmarx KICS, a Docker relatou que credenciais válidas de publisher foram usadas para publicar imagens maliciosas por fluxos legítimos. A própria Docker destacou que a infraestrutura da Docker não foi comprometida, mas usuários que puxaram as tags afetadas tiveram a cadeia de software exposta por uma janela de tempo.
A lição prática para empresas brasileiras é direta: ferramentas de DevOps, scanners de segurança e dependências de pipeline precisam ser tratadas como ativos críticos. Um scanner que roda com acesso a segredos de produção não é “só uma ferramenta”. Um scanner que roda com acesso a segredos de produção é uma identidade privilegiada automatizada. Porque aparentemente até robô de build precisa de governança, quem diria.
Principais riscos para empresas com pipelines CI/CD
Roubo de tokens de acesso
O roubo de tokens de acesso permite que um atacante use permissões legítimas para consultar repositórios, publicar pacotes, acessar cloud, modificar workflows ou coletar artefatos.
Tokens de GitHub, npm, AWS, Azure, GCP e outros serviços devem ser tratados como credenciais sensíveis. Tokens usados em pipelines CI/CD precisam ter escopo mínimo, validade curta e trilhas de auditoria.
Exfiltração de segredos de pipeline
A exfiltração de segredos de pipeline ocorre quando uma ferramenta maliciosa lê variáveis de ambiente, arquivos .env, chaves SSH, arquivos .npmrc, histórico de shell ou credenciais disponíveis no runner.
A exfiltração de segredos de pipeline é difícil de perceber quando a ferramenta comprometida continua executando sua função normal. O build passa, o deploy acontece e o alerta não aparece no painel que ninguém configurou direito, uma obra-prima da confiança cega.
Propagação para outros pacotes e repositórios
A propagação em ataques à cadeia de software acontece quando credenciais roubadas permitem modificar outros repositórios, publicar versões maliciosas ou inserir workflows em projetos adicionais.
A Socket relatou que o payload associado ao caso Bitwarden CLI incluía roubo de tokens npm para identificar pacotes graváveis e republicar pacotes com hooks maliciosos, além de injeção de workflows no GitHub Actions para capturar segredos de repositórios.
Falta de visibilidade sobre runners e endpoints técnicos
Runners de CI/CD, máquinas de desenvolvedores e servidores de build costumam ser tratados como bastidores técnicos. Na prática, runners de CI/CD, máquinas de desenvolvedores e servidores de build podem carregar credenciais mais sensíveis do que muitos servidores de aplicação.
A falta de inventário, logs centralizados e monitoramento de comportamento impede que a equipe de segurança identifique conexões externas suspeitas, alterações em workflows, uso anômalo de tokens e execução de binários incomuns.
Exemplos práticos de sinais de alerta
Uma empresa deve investigar pipelines CI/CD quando houver execução incomum de ferramentas de build, scanners ou CLIs em runners com acesso a segredos.
Uma empresa deve investigar repositórios Git quando surgirem workflows inesperados em .github/workflows, branches temporárias sem justificativa, artefatos desconhecidos, commits de automação fora do padrão ou criação de repositórios públicos sem aprovação.
Uma empresa deve investigar endpoints técnicos quando houver acesso anormal a arquivos .npmrc, .env, .git-credentials, diretórios de cloud credentials, chaves SSH ou comandos como gh auth token, gcloud, az e azd fora do fluxo esperado.
Uma empresa deve investigar ambientes cloud quando houver emissão incomum de tokens, uso de credenciais fora do horário esperado, criação de recursos sem change formal ou movimentação lateral a partir de identidades técnicas.
Como reduzir o risco de ataques à cadeia de software em CI/CD
1. Reduzir privilégios de tokens e credenciais
A redução de privilégios limita o impacto de uma ferramenta comprometida em pipelines CI/CD.
Tokens de pipeline devem ter escopo mínimo, expiração curta, segregação por projeto e rotação periódica. Uma credencial usada para scan de infraestrutura como código não deve ter permissão ampla para publicar pacotes, alterar repositórios ou acessar segredos de produção.
2. Fixar versões, digests e origens confiáveis
A fixação de versões e digests reduz o risco de uma tag sobrescrita executar código diferente do esperado.
A Docker recomendou que usuários afetados pelo caso KICS repuxassem checkmarx/kics por digest, não apenas por tag, e fixassem o CI no digest para evitar que uma futura sobrescrita de tag afetasse silenciosamente o ambiente.
3. Monitorar logs de CI/CD, endpoints e cloud
O monitoramento de logs permite identificar comportamento suspeito antes que o incidente se transforme em comprometimento amplo.
A empresa deve centralizar logs de runners, GitHub Actions, registries, cloud, endpoints técnicos, firewalls, Active Directory, Microsoft 365, servidores e ferramentas de segurança. O objetivo do monitoramento é correlacionar eventos que isoladamente parecem normais, mas juntos indicam roubo de credenciais ou abuso de automação.
4. Auditar mudanças em workflows
A auditoria de workflows ajuda a detectar alterações maliciosas em automações de build, teste e deploy.
Workflows de CI/CD devem exigir revisão, controle de branch, aprovação para mudanças sensíveis e alertas quando arquivos em .github/workflows ou estruturas equivalentes forem alterados. Uma mudança pequena em YAML pode ser suficiente para expor segredos que deveriam permanecer invisíveis.
5. Proteger endpoints técnicos e máquinas de desenvolvimento
A proteção de endpoints técnicos reduz a chance de um pacote malicioso coletar credenciais locais.
Máquinas de desenvolvedores, estações administrativas, servidores de build e runners persistentes devem ter inventário de software, correções aplicadas, controle de aplicações, DLP, auditoria de software de alto risco e políticas de segurança consistentes.
Como Log360, Endpoint Central e gestão de privilégios ajudam nesse contexto
Log360: visibilidade e correlação de eventos
O ManageEngine Log360 é uma solução SIEM que consolida logs de múltiplas fontes, como Active Directory, Microsoft 365, firewalls e servidores, além de oferecer detecção de ameaças, UEBA, alertas em tempo real, resposta a incidentes e relatórios de conformidade.
O Log360 ajuda empresas a monitorar sinais de ataque à cadeia de software ao correlacionar eventos de autenticação, alterações em identidades, acessos anômalos, movimentações suspeitas e atividades fora do padrão em ambientes híbridos.
O Log360 não substitui controles de DevSecOps, mas o Log360 fortalece a investigação quando tokens, credenciais e identidades técnicas passam a ser usados de forma suspeita.
Endpoint Central: segurança de endpoints técnicos
O ManageEngine Endpoint Central é uma solução UEM para gerenciar e proteger servidores, desktops, laptops e dispositivos móveis. A solução inclui gestão unificada, segurança avançada, patch management, implantação de software, troubleshooting remoto e recursos de proteção contra ameaças.
O Endpoint Central ajuda empresas a reduzir riscos em máquinas de desenvolvedores, servidores de build e endpoints administrativos ao manter sistemas atualizados, controlar softwares instalados, aplicar configurações de segurança e monitorar ativos.
O Endpoint Central é especialmente relevante quando o ataque começa em uma ferramenta instalada localmente ou em um runner que executa pacotes, CLIs e scripts de automação.
Gestão de privilégios: controle de credenciais sensíveis
A gestão de privilégios reduz o impacto de credenciais comprometidas em pipelines, contas técnicas e ambientes cloud.
O ManageEngine PAM360 centraliza credenciais privilegiadas, aplica controle granular de acesso, monitora sessões, automatiza rotação de senhas, oferece acesso just-in-time e se integra a Active Directory, SIEMs, sistemas de ticketing e plataformas como AWS e Azure.
A gestão de privilégios ajuda empresas a evitar que tokens e contas técnicas tenham permissões permanentes e excessivas. Em ataques à cadeia de software, o menor privilégio não impede todos os ataques, mas reduz o alcance do dano quando uma ferramenta confiável é comprometida.