Trivy tem versão oficial comprometida por infostealer e expõe credenciais sensíveis
Os mantenedores do Trivy, popular scanner de vulnerabilidades da Aqua Security amplamente usado em pipelines de CI/CD e ambientes cloud-native, confirmaram que uma versão oficial da ferramenta foi distribuída com um malware do tipo infostealer. O incidente afeta especificamente a versão 0.69.4, publicada em 19 de março, e divulgada pelos canais legítimos da própria empresa.
Essa versão maliciosa estava disponível nos mesmos repositórios que os usuários confiam diariamente: imagens no Docker Hub, instaladores via get.trivy.dev e integrações relacionadas, como as releases do trivy-action e do setup-trivy usadas em fluxos de trabalho de automação. Ou seja, não se tratava de um pacote falso ou clonado em repositórios paralelos: o binário comprometido estava, de fato, nos canais oficiais.
Enquanto executava normalmente suas funções de scanner de vulnerabilidades, o Trivy adulterado atuava silenciosamente em segundo plano coletando dados sensíveis dos ambientes em que era executado. Isso torna o ataque particularmente perigoso: administradores e equipes de segurança não tinham nenhum sinal evidente de comportamento anômalo, e a ferramenta continuava entregando os resultados esperados de varredura.
De acordo com análise da Wiz, os invasores conseguiram roubar chaves GPG e credenciais usadas pela Aqua Security para acessar diversos serviços, incluindo Docker Hub, a rede social X e Slack. Essas credenciais comprometidas teriam sido um dos vetores que possibilitaram a publicação da versão maliciosa como se fosse uma release legítima.
A Aqua Security esclareceu que esse incidente é parte de uma cadeia de ataques iniciada ainda no fim de fevereiro. Após detectar e divulgar um primeiro comprometimento em 1º de março, a empresa iniciou um processo de rotação de credenciais. No entanto, nem todos os segredos foram revogados ao mesmo tempo. Essa janela de rotação – o intervalo entre a troca de algumas credenciais e a revogação completa de todas – permitiu que os atacantes mantivessem acesso a partes do ambiente e explorassem brechas remanescentes.
A CrowdStrike analisou o comportamento do malware embutido no Trivy comprometido e descreveu um infostealer com foco claro em infraestrutura e nuvem. Entre os dados coletados estavam:
– chaves privadas SSH, frequentemente usadas para acesso administrativo a servidores e repositórios de código;
– credenciais de provedores de nuvem, incluindo AWS, Google Cloud e Microsoft Azure;
– arquivos de configuração e credenciais de clusters Kubernetes;
– tokens de serviço utilizados por aplicações e pipelines de CI/CD;
– credenciais de bancos de dados como MySQL, PostgreSQL, MongoDB e Redis;
– arquivos .env contendo variáveis de ambiente sensíveis;
– chaves de API de diversos serviços conectados ao ambiente.
Em outras palavras, qualquer organização que tenha executado versões comprometidas do Trivy ou de suas ações integradas corre o risco de ter exposto praticamente todo o “esqueleto” da sua infraestrutura: desde acesso a código-fonte e bancos de dados até chaves que permitem controlar recursos em provedores de nuvem.
As empresas afetadas foram orientadas a agir como se todas as credenciais acessíveis a partir dos pipelines onde o Trivy foi executado tivessem sido comprometidas. A recomendação é clara e rígida: substituir imediatamente todos os segredos, tokens, chaves e credenciais que possam ter ficado ao alcance do binário adulterado. Isso inclui não apenas credenciais diretamente utilizadas pelo Trivy, mas qualquer segredo armazenado ou acessado no mesmo ambiente, seja em variáveis de ambiente, arquivos de configuração, cofres de segredos integrados à pipeline ou serviços vinculados.
Além da troca de segredos, é essencial revisar logs de acesso e uso de credenciais em nuvem, bancos de dados, clusters Kubernetes e ferramentas de colaboração. Um atacante com posse dessas informações pode movimentar-se lateralmente pela infraestrutura, criar chaves alternativas, estabelecer backdoors e até preparar ataques futuros, mesmo após a rotação de credenciais.
O caso expõe um ponto sensível da cadeia de suprimentos de software: ferramentas de segurança, justamente escolhidas para reduzir riscos, podem se transformar em vetor de ataque quando a integridade do processo de build e distribuição é comprometida. O fato de o Trivy ser amplamente utilizado em pipelines automatizados aumenta o impacto potencial, já que muitas empresas integram o scanner a fluxos de compilação e deploy sem supervisão manual constante.
Para organizações que utilizam o Trivy, algumas medidas práticas se tornam urgentes:
1. Identificar com precisão se a versão 0.69.4 foi baixada ou executada em qualquer ambiente, seja em estações de desenvolvimento, servidores de CI/CD, contêineres de build ou clusters Kubernetes.
2. Verificar scripts, pipelines e workflows (por exemplo, arquivos de configuração de automação) que possam ter referenciado automaticamente essa versão ou as ações comprometidas.
3. Realizar uma rotação completa de segredos potencialmente expostos: credenciais de cloud, chaves SSH, segredos de bancos de dados, tokens de automação e qualquer chave de API acessível a partir dos ambientes afetados.
4. Monitorar ativamente por tentativas suspeitas de autenticação, criação atípica de recursos na nuvem, conexões incomuns a bancos de dados e acessos fora de padrão em repositórios de código.
5. Revisar políticas de gerenciamento de segredos e a forma como variáveis sensíveis são expostas a ferramentas de terceiros e pipelines.
Outro ponto que esse incidente reforça é a fragilidade da percepção de “confiabilidade automática” quando o assunto é Cloud e SaaS. Muitas organizações assumem, de forma equivocada, que provedores de serviços em nuvem garantem backup, integridade e proteção total dos dados. Na prática, a responsabilidade é compartilhada: o provedor protege a infraestrutura, mas a segurança das credenciais, o controle de acessos e a avaliação das ferramentas integradas ao ambiente permanecem sob responsabilidade do cliente.
Ataques de supply chain como esse demonstram que, mesmo utilizando soluções consolidadas e mantidas por empresas especializadas em segurança, ainda é necessário implementar camadas adicionais de proteção. Entre elas: assinaturas de código, validação de integridade dos binários, verificação de checksums, uso de repositórios internos para “congelar” versões consideradas seguras e processos de aprovação antes de atualizar ferramentas críticas em pipelines sensíveis.
Também é recomendável que equipes de segurança estabeleçam procedimentos formais para lidar com incidentes envolvendo ferramentas de terceiros. Isso inclui playbooks para:
– resposta rápida à descoberta de software comprometido;
– comunicação interna clara com times de desenvolvimento, DevOps e gestão;
– definição de critérios objetivos para descontinuar ou suspender temporariamente o uso de componentes suspeitos;
– testes de impacto para medir o quanto um binário malicioso pode ter alcançado dentro da organização.
Mesmo após corrigido o problema e removida a versão 0.69.4 dos canais oficiais, o rastro do incidente ainda pode perdurar. Ferramentas maliciosas podem ter exfiltrado segredos que, uma vez vazados, podem ser comercializados em mercados clandestinos ou reutilizados em ataques direcionados no futuro. Por isso, a resposta não deve se limitar à simples atualização do Trivy para uma versão limpa: é imprescindível tratar o episódio como uma potencial violação de credenciais em larga escala.
Para os profissionais de segurança, o caso do Trivy serve como um alerta adicional sobre a importância de observar atentamente a cadeia de ferramentas usada no ciclo de desenvolvimento. Ferramentas de análise de vulnerabilidades, scanners de contêineres, agentes de monitoramento e demais componentes que rodam com privilégios amplos ou acesso a segredos críticos precisam ser avaliados com o mesmo rigor aplicado a sistemas de produção.
Em síntese, a versão oficial infectada do Trivy evidencia como um único ponto de comprometimento em um projeto amplamente adotado pode abrir portas para ataques profundos em ambientes de nuvem, pipelines de CI/CD e aplicações conectadas. A resposta adequada passa por três pilares: transparência dos fornecedores ao divulgar incidentes, rapidez das organizações na rotação de credenciais e fortalecimento das práticas de segurança em toda a cadeia de desenvolvimento e operação.