A cadeia de fornecimento de software em jaque: imagens de Trivy comprometidas e credenciais expostas

A segurança do desenvolvimento de software tornou-se o centro de atenção após uma nova onda de ataques direcionados à cadeia de fornecimento: versões troceadas do scanner de vulnerabilidades Trivy, distribuídas por Docker Hub, serviram como vetor para filtrar credenciais e propagar malware além do ambiente original. O alcance não se limita a uma simples imagem comprometida: os efeitos foram sentidos em repositórios, ações do GitHub e pacotes de ecossistemas de código aberto.

Segundo os pesquisadores que analisaram a campanha, as últimas versões públicas confiáveis de Trivy em Docker Hub datavam da etiqueta 0.69.3; imediatamente depois apareceram imagens rotuladas como 0.69.4, 0.69.5 e 0.69.6 que foram detectadas como maliciosas e retiradas. Você pode rever as legendas históricas na página oficial do repositório de imagens aquasec/trivy em Docker Hub.

O padrão de ataque descrito pelos analistas aponta para uma escalada em cadeia: um ator malicioso explodiu credenciais comprometidas para subir versões de Trivy com um ladrão de credenciais embebido, e também conseguiu injetar mudanças em duas ações do GitHub vinculadas ao projeto – as que facilitam a integração de Trivy em pipelines – o que multiplicou a superfície de infecção em ambientes de CI/CD. O detalhe técnico e os indicadores de compromisso foram documentados pela equipe de Socket Security neste relatório sobre as imagens de Trivy comprometidas.

Esta intrusão não ficou isolada: com as credenciais exfiltradas os atacantes conseguiram comprometer pacotes no registro npm e distribuir uma ameaça autorreplicante conhecida como CanisterWorm. Pesquisadores independentes que rastreiam a campanha atribuem as ações a um ator apodado TeamPCP, que já havia mostrado interesse por infraestruturas cloud e componentes nativos como APIs de Docker, clusters de Kubernetes e serviços expostos.

O impacto também atingiu a organização do Aqua Security. Segundo o rastreamento forense publicado pela equipe OpenSourceMalware, 44 repositórios internos da organização aquasec-com no GitHub Foram renomeados e expostos publicamente em um intervalo de tempo muito curto, sugerindo uma exploração automatizada por meio de um token comprometido de uma conta de serviço. A análise técnica disponível em seu blog explica como um token persistente (do serviço "Argon-DevOps-Mgt") serviu como chave para escrever em várias organizações, amplificando o dano em cadeia: análise do compromisso.

Os relatórios técnicos também documentaram a evolução das capacidades do grupo atacante: além do roubo de credenciais e da distribuição de worms, foram identificados payloads projetados para sabotar ambientes. Pesquisadores da assinatura Aikido descrevem um componente que, segundo as regras incluídas no seu programa, exibe DaemonSets privilegiados em cada nodo de Kubernetes e, em sistemas com detecções geográficas orientadas para o Irã, executa rotinas de remoção maciça e reinício forçado. O artigo técnico de Aikido ahonda em como se comporta essa carga e na separação de ações segundo a localização do objetivo: análise sobre o payload e seu impacto em K8s.

Se houver uma lição clara deste incidente, é que um único elo fraco na cadeia de abastecimento (por exemplo, uma conta de serviço com um token de longa duração) pode ter consequências em cascata. As credenciais persistentes e as permissões demasiado amplas são precisamente o que os atacantes procuram explorar para se mover lateralmente e envenenar fluxos de trabalho automatizados.

Para equipes que utilizam Trivy em suas pipelines, as recomendações imediatas são evidentes: evitar as versões afetadas, auditar execuções recentes e assumir compromisso se essas imagens ou ações foram usadas em processos críticos. O repositório de Trivy no GitHub e seus mantenedores publicaram informações oficiais sobre a pesquisa e versões seguras, pelo que convém contrastar com a fonte primária: Repositório de Trivy no GitHub.

Para além de substituir ou bloquear imagens, a resposta deve incluir medidas de higiene de credenciais: revogar tokens e chaves suspeitas, reduzir o tempo de vida de tokens de serviço, rever permissões atribuídas a contas automatizadas e aplicar princípios de menor privilégio em integrações entre organizações. Além disso, é aconselhável reforçar o controlo do acesso à APIs do Docker (por exemplo, evitar expor o porto 2375 sem autenticação) e aplicar a segmentação de rede que impeça um servidor comprometido propague agentes a sub-redes locais.

No plano organizacional, convém complementar essas ações com detecção e resposta: revisar logs de CI/CD em busca de execuções anómalas, verificar a integridade de artefatos implantados e usar assinaturas e verificação de procedência para imagens em produção. As autoridades e equipamentos de segurança pública publicaram guias para mitigar riscos na cadeia de fornecimento do software; sua consulta pode ajudar a formalizar políticas de controle e resposta a incidentes, por exemplo no repositório de recursos da CISA sobre gestão do risco na cadeia de fornecimento de software ( CISA – Software Supply Chain Risk Management).

É importante lembrar que em ataques deste tipo nem sempre há uma única vítima visível: a organização proprietária do projeto afetado pode se tornar plataforma involuntária para comprometer dezenas ou centenas de consumidores de seu software. A confiança em componentes e ações de terceiros deve ser validada de forma contínua, não assumida por vida.

Enquanto as equipas forenses e responsáveis pelas plataformas continuam a corrigir vetores e a publicar indicadores de compromisso, as empresas e os desenvolvedores devem tomar medidas imediatas para conter o impacto e evitar que pequenas falhas locais se tornem lacunas em massa. A cadeia de fornecimento do software é tão forte quanto o elo mais fraco: minimizar esses pontos fracos é agora uma prioridade ineludível.