CI/CD sob ataque: como uma credencial exposta chega até seus dados na nuvem

Uma pipeline de CI/CD comprometida raramente é o ataque final. É a porta de entrada. Uma pesquisa recente da FortiGuard Labs mostrou, com detalhes técnicos, como uma cadeia de comprometimento associada ao malware Shai Hulud partiu de credenciais expostas em um servidor Jenkins, escalou privilégios dentro da AWS e terminou em atividade suspeita sobre um data warehouse Redshift. O caso é um retrato preciso de um problema que já é realidade em empresas brasileiras: o pipeline de desenvolvimento se tornou um dos ativos mais críticos e menos monitorados da infraestrutura de segurança.

Por que o CI/CD virou alvo prioritário

Ferramentas de integração e entrega contínua como Jenkins, GitLab CI, GitHub Actions e Azure DevOps concentram um poder enorme: credenciais de nuvem, chaves de API, tokens de acesso a repositórios, segredos de banco de dados e, muitas vezes, permissões administrativas amplas para automatizar deploys. Esse poder é exatamente o que torna o CI/CD atraente para atacantes.

Diferente de um servidor de produção isolado, um pipeline comprometido oferece:

• Persistência silenciosa. Jobs automatizados rodam com frequência e passam despercebidos em logs volumosos.
• Credenciais de alto valor. Tokens usados para deploy costumam ter permissões que vão muito além do necessário.
• Caminho direto para a nuvem. Um pipeline que faz deploy na AWS, Azure ou GCP já possui, por definição, acesso a recursos de produção.
• Baixa visibilidade de segurança. Muitas equipes de DevOps tratam segredos de CI/CD como configuração, não como superfície de ataque.

No caso analisado pela FortiGuard Labs, o comprometimento inicial explorou uma credencial exposta em um servidor Jenkins mal configurado. A partir daí, o atacante conseguiu localizar chaves de acesso à AWS armazenadas no ambiente, escalar privilégios dentro da conta e, por fim, alcançar recursos do Redshift, indicando tentativa de exfiltração de dados analíticos sensíveis.

A anatomia de um ataque em cadeia

O que torna esse tipo de incidente particularmente perigoso é a velocidade com que ele se move entre camadas que normalmente pertencem a equipes diferentes: desenvolvimento, infraestrutura de nuvem e dados. Um modelo simplificado do caminho seguido nesse tipo de campanha costuma ser:

1. Comprometimento inicial, geralmente por credencial exposta, dependência maliciosa ou pacote de código aberto comprometido (padrão observado em campanhas relacionadas ao Shai Hulud, que historicamente se propaga via pacotes npm).
2. Reconhecimento no ambiente de CI/CD, buscando variáveis de ambiente, arquivos de configuração e segredos armazenados em texto claro ou em cofres mal protegidos.
3. Escalonamento de privilégios na nuvem, usando as credenciais encontradas para assumir papéis (roles) com permissões mais amplas do que o necessário para o pipeline.
4. Movimento lateral entre serviços, alcançando bancos de dados, buckets de armazenamento ou data warehouses.
5. Exfiltração ou persistência, com o atacante buscando dados de valor ou mantendo acesso de longo prazo.

Essa cadeia raramente é detectada por uma única ferramenta. Ela exige correlação entre eventos de código-fonte, atividade de identidade na nuvem e comportamento anômalo em serviços de dados, exatamente o tipo de visão que soluções pontuais e desconectadas não entregam.

O erro estrutural: tratar CI/CD como infraestrutura interna

Muitas organizações ainda aplicam a mentalidade de "rede interna é confiável" aos ambientes de CI/CD. Na prática, isso significa:

• Tokens de longa duração em vez de credenciais temporárias.
• Permissões de deploy amplas, sem segregação por ambiente ou serviço.
• Segredos versionados acidentalmente em repositórios, às vezes por anos, sem rotação.
• Ausência de testes de segurança específicos para a cadeia de build e deploy.

Esse ponto conecta diretamente com a prática de pentest e red team. Testes de invasão tradicionais, focados apenas em aplicações web ou perímetro de rede, deixam de simular justamente o vetor que mais tem crescido: o comprometimento da cadeia de desenvolvimento e sua conexão com a nuvem. Um exercício de Pentest e Red Team bem desenhado hoje precisa incluir cenários de credenciais expostas em pipelines, escalonamento de privilégios em IAM e movimento lateral até serviços de dados, replicando exatamente o tipo de cadeia documentada pela FortiGuard Labs.

Gestão de vulnerabilidades não pode parar no código

Outro ponto crítico é que a superfície de risco do CI/CD não se limita a vulnerabilidades de software. Ela inclui configurações de IAM, políticas de acesso a segredos, permissões de service accounts e a postura geral de segurança na nuvem. Um programa de gestão de vulnerabilidades que trata apenas CVEs de aplicações fica cego para esse tipo de exposição.

É aqui que entra a importância de um VOC (Vulnerability Operations Center) capaz de correlacionar achados técnicos com o contexto de negócio e priorizar o que realmente importa. O ISA Insight foi desenhado justamente para isso: consolidar vulnerabilidades vindas de múltiplas fontes, incluindo configurações de nuvem e pipelines, e transformar esse volume em um plano de correção priorizado, em vez de uma lista infinita de alertas que ninguém consegue tratar.

Detecção precisa quando o ataque já está em movimento

Quando a prevenção falha, a detecção precisa ser rápida e contextual. Um ataque que sai do CI/CD e chega ao Redshift envolve múltiplos sinais fracos espalhados em diferentes camadas: autenticação anômala na AWS, uso de credenciais fora do padrão, consultas inusuais a um data warehouse. Isolados, esses sinais parecem ruído. Correlacionados, contam uma história clara de comprometimento.

Esse é exatamente o tipo de cenário em que um SOC e MDR operando 24/7, com IA para correlação de eventos entre identidade, nuvem e dados, faz diferença real no tempo de resposta. A plataforma ISA Cyber foi construída para atuar exatamente nesse tipo de análise multicamada, reduzindo o tempo entre o comprometimento inicial e a contenção.

Recomendações práticas para reduzir esse risco

Algumas medidas concretas ajudam a fechar essa rota de ataque:

• Migrar para credenciais temporárias e de curta duração em pipelines, evitando chaves estáticas.
• Aplic