O popular scanner de segurança Trivy tornou-se, ironicamente, o vetor de um ataque sofisticado que explorou uma falha na cadeia de suprimentos envolvendo o GitHub Actions. O incidente mostra que nem mesmo ferramentas de segurança estão imunes quando há brechas na forma como dependências são distribuídas e executadas.
Neste artigo, vamos analisar como ocorreu a violação associada à Aqua Security, o papel do grupo TeamPCP e como o malware CanisterWorm surgiu como uma evolução desse ataque. O caso expõe uma realidade preocupante, a fragilidade estrutural das pipelines modernas de CI/CD.
O que aconteceu: a cronologia da invasão
O ataque começou com o comprometimento da versão v0.69.4 do Trivy, amplamente utilizada em pipelines automatizadas dentro do GitHub Actions.
O ponto central da invasão foi a modificação do arquivo entrypoint.sh, responsável pela execução da action. Os invasores inseriram código malicioso nesse script, transformando uma ferramenta legítima em um vetor silencioso de exfiltração de dados.
A sofisticação aumentou com a manipulação das tags do repositório. Em vez de criar uma nova versão suspeita, os atacantes alteraram referências já existentes para apontar para commits maliciosos. Isso fez com que workflows confiáveis continuassem sendo executados normalmente, porém com código comprometido.
Na prática, qualquer pipeline que utilizasse a action afetada acabava executando o código do invasor sem perceber.
Como o ataque à cadeia de suprimentos do Trivy funcionou
O grupo TeamPCP utilizou uma estratégia clássica de infostealer, mas adaptada para ambientes de integração contínua.
O objetivo não era apenas infectar máquinas, mas capturar credenciais críticas usadas em automações e deploys.
Coleta de dados e exfiltração
Uma vez dentro do ambiente do GitHub Actions, o código malicioso iniciava a coleta de informações sensíveis, incluindo:
- Credenciais de serviços cloud como AWS e GCP
- Chaves SSH usadas em deploys
- Tokens e secrets do próprio GitHub Actions
- Arquivos
.envcom variáveis sensíveis
Esses dados eram enviados para servidores controlados pelos atacantes, permitindo acesso posterior às infraestruturas comprometidas.
Táticas de persistência
Embora o ambiente de CI seja temporário, o ataque buscou persistência fora dele.
O payload incluía scripts em Python capazes de estabelecer comunicação remota e manter acesso contínuo. Em alguns cenários, houve tentativa de criação de serviços via systemd, especialmente quando o código era reutilizado fora do pipeline.
Isso ampliou significativamente o impacto do ataque.
CanisterWorm: a evolução do ataque via npm
O incidente evoluiu com o surgimento do CanisterWorm, um malware projetado para se espalhar através do ecossistema npm.
Após obter credenciais, os invasores passaram a comprometer pacotes e dependências, aumentando o alcance do ataque para além do Trivy.
Um detalhe crítico foi o uso de infraestrutura descentralizada baseada no ICP, dificultando a derrubada da operação maliciosa.
Na prática, o ataque deixou de ser pontual e passou a se comportar como um worm moderno, com capacidade de propagação automatizada entre projetos e pipelines.
O que fazer agora para se proteger
Diante da gravidade do ataque envolvendo o Trivy e o GitHub Actions, algumas medidas devem ser adotadas imediatamente.
A primeira ação é rotacionar todas as credenciais potencialmente expostas, incluindo tokens, chaves SSH e acessos a provedores cloud.
Também é essencial revisar os logs do GitHub Actions em busca de execuções suspeitas ou acessos incomuns.
Outro ponto crítico é evitar o uso de tags dinâmicas em actions. O ideal é utilizar hashes imutáveis (commit SHA), garantindo a integridade do código executado.
Além disso, revise todas as dependências e pipelines que utilizam o Trivy, garantindo que versões seguras estejam em uso.
Boas práticas adicionais incluem:
- Aplicar o princípio do menor privilégio
- Isolar ambientes de execução
- Monitorar continuamente pipelines
- Validar integridade de dependências
Conclusão e impacto para o ecossistema
O comprometimento do Trivy reforça um alerta importante, ataques à cadeia de suprimentos estão se tornando cada vez mais sofisticados e difíceis de detectar.
Mesmo ferramentas de segurança podem se tornar vetores de ataque quando há confiança excessiva em automações e dependências externas. A responsabilidade não é apenas da Aqua Security, mas de todo o ecossistema que depende de CI/CD.
Esse caso mostra que segurança não pode ser tratada como etapa final, mas como um processo contínuo.
