Pular para o conteúdo
CyberArmorPlataforma para consultoria de segurança
ataque cadeia de suprimentos softwaresegurança da esteira ci/cdgithub actions fixar hash committrocar segredos ci depois de incidente

Ataque à cadeia de suprimentos: como proteger a esteira de CI/CD

Um ataque à cadeia de suprimentos acontece quando o criminoso adultera uma ferramenta ou biblioteca em que sua empresa já confia. O código malicioso entra pela própria esteira de entrega e leva senhas e chaves de nuvem. A defesa combina versões fixadas por hash, segredos com permissão mínima, inventário de dependências e troca de segredos depois de um incidente.

Por Equipe CyberArmor

O que é um ataque à cadeia de suprimentos de software?

Sua empresa escreve só uma parte do software que coloca no ar. O resto vem de bibliotecas abertas, imagens de contêiner e ferramentas que rodam na esteira de entrega. Essa esteira é o CI/CD (integração e entrega contínuas): o conjunto de etapas automáticas que testa, empacota e publica o código a cada alteração.

No ataque à cadeia de suprimentos, o criminoso deixa a sua empresa de lado e invade um fornecedor desse software. Ele publica uma versão adulterada de uma peça confiável. A sua esteira baixa essa versão sozinha, porque foi configurada para confiar nela. O código malicioso então roda com o mesmo acesso da esteira: chaves de nuvem, senhas de banco de dados, tokens de publicação.

A consequência para o negócio é direta. Quem rouba esses segredos consegue entrar na sua nuvem, alterar o que você publica para os seus clientes ou vender o acesso para outro grupo.

O que aconteceu com o Trivy e o LiteLLM em 2026?

O Trivy é um scanner de vulnerabilidades muito usado dentro de esteiras de CI/CD. Segundo o comunicado oficial da Aqua Security (GHSA-69fq-xp46-6x23), em 19 de março de 2026 um atacante com credenciais roubadas publicou a versão maliciosa 0.69.4 do Trivy e reescreveu as tags das ações trivy-action e setup-trivy no GitHub. Quem usava essas ações por tag passou a rodar um ladrão de credenciais antes da varredura normal. O mesmo comunicado registra imagens maliciosas 0.69.5 e 0.69.6 no Docker Hub em 22 de março. O código lia a memória do executor do GitHub e procurava chaves SSH, credenciais de nuvem, tokens do Kubernetes e arquivos .env.

O estrago não parou no Trivy. A equipe do LiteLLM, biblioteca Python usada para conectar sistemas a modelos de IA, informou em seu aviso de segurança que as versões 1.82.7 e 1.82.8 publicadas no PyPI em 24 de março de 2026 estavam comprometidas. A própria equipe afirma acreditar que a origem foi o Trivy usado na sua esteira de varredura de segurança. Ou seja: a ferramenta que devia proteger a esteira entregou o token que permitiu publicar o pacote falso.

A agência americana CISA incluiu a falha, registrada como CVE-2026-33634, no seu catálogo de vulnerabilidades exploradas em 26 de março de 2026, como relatou a Security Affairs em 27/03/2026.

O caso também não foi o primeiro. Em março de 2025, a CISA publicou alerta sobre a ação tj-actions/changed-files, adulterada para expor chaves de acesso, tokens do GitHub e do npm. O padrão se repete, e a defesa também.

Por que fixar GitHub Actions por hash de commit?

Uma tag como v1 ou 0.34.0 parece uma versão fixa, mas quem controla o repositório pode movê-la para outro código. Foi exatamente isso que aconteceu com o trivy-action. A documentação de uso seguro do GitHub Actions avisa que uma tag pode ser movida ou apagada por quem invadir o repositório da ação. A recomendação do GitHub é apontar cada ação para o hash completo do commit, um identificador que não pode ser trocado sem que o conteúdo mude.

O comunicado da Aqua Security diz o mesmo: quem estava fixado em um commit seguro ficou protegido. Na prática, sua equipe deve:

  1. Trocar uses: fornecedor/acao@v1 pelo hash completo do commit, com a versão anotada em comentário ao lado.
  2. Conferir que o hash pertence ao repositório oficial da ação.
  3. Usar uma ferramenta de atualização de dependências que proponha novos hashes por pull request, para que cada troca passe por revisão.
  4. Aplicar a mesma lógica a imagens de contêiner (referência por digest) e a bibliotecas (arquivo de travamento de versões, o lockfile).

O GitHub também recomenda que o GITHUB_TOKEN tenha, por padrão, só leitura do conteúdo do repositório. Cada job recebe mais permissão apenas quando precisa. Assim, se uma ação for adulterada, ela encontra menos coisa para levar.

O que fazer com os segredos do CI depois de um incidente?

Quando uma ferramenta da esteira é comprometida, trate como roubado todo segredo que ela podia ler. O comunicado da Aqua Security manda considerar expostos e trocar imediatamente todos os segredos acessíveis às esteiras afetadas. A CISA deu a mesma orientação no caso tj-actions. Apagar a versão maliciosa não basta: a chave copiada continua válida até ser revogada.

A sequência que sua equipe segue:

  1. Descobrir quais esteiras rodaram a versão afetada na janela informada pelo fabricante, olhando os logs de execução.
  2. Revogar e recriar as chaves de nuvem, tokens de publicação (npm, PyPI, registro de contêiner), senhas de banco e chaves SSH que essas esteiras usavam.
  3. Procurar sinais deixados pelo atacante. No caso Trivy, o fabricante indica buscar repositórios com nome iniciado por tpcp-docs- na organização do GitHub.
  4. Revisar o que foi publicado nesse período, porque um token de publicação roubado permite lançar versões falsas em seu nome.

Para reduzir o estrago da próxima vez, prefira segredos de curta duração e com escopo mínimo. Uma chave que expira logo e só publica um pacote vale pouco para o criminoso.

O que é SBOM e por que sua empresa precisa de um inventário de dependências?

SBOM é a sigla em inglês para lista de materiais de software. A CISA define o SBOM como um inventário dos componentes que formam um software, como a lista de ingredientes de um produto.

No dia em que sai um aviso como o do LiteLLM, a primeira pergunta é simples: usamos essa biblioteca, em qual versão e em qual sistema? Sem inventário, a resposta leva dias de busca manual. Com um SBOM gerado a cada build, a equipe consulta e responde em minutos. O inventário deve incluir também as ferramentas da própria esteira, como scanners e ações do GitHub, porque foram elas o alvo neste caso.

Por onde começar na sua empresa?

Comece pela esteira que publica o sistema mais importante. Liste as ações e ferramentas que ela usa, fixe cada uma por hash, corte as permissões do token e gere o primeiro SBOM. Depois, escreva o roteiro de troca de segredos antes de precisar dele.

Os analistas da CyberArmor fazem esse levantamento no Raio-X do código, um projeto de 2 a 3 semanas que inclui a esteira e as dependências. Para manter as correções em dia, a Esteira segura acompanhada revisa a configuração de forma recorrente. Para conversar sobre o seu caso, fale com um especialista.

Fontes