A Pipeline Como Linha de Defesa: o Que os Casos OVHcloud e LiteLLM Ensinam

Entre 19 e 21 de Outubro de 2026, duas ferramentas usadas diariamente em pipelines de construção e implantação foram substituídas por versões que roubam credenciais. Uma era a interface de linha de comandos de um fornecedor europeu de cloud. A outra, uma biblioteca de código aberto com mais de 20 milhões de descargas por semana, segundo a Datadog Security Labs.

Nenhum dos dois casos começou numa falha da pipeline de quem usava as ferramentas. Mas em ambos, a pipeline de quem as usava era o sítio certo para travar a entrada.

19 de Outubro: a interface de linha de comandos da OVHcloud

Durante 94 minutos, das 14:47 às 16:21 (hora de Paris), os binários oficiais do ovhcloud-cli publicados no GitHub, versões 0.11.0 a 0.15.0, foram substituídos por versões adulteradas, preparadas para recolher segredos guardados no disco. Segundo a IT-Connect, o ficheiro de somas de verificação também foi reescrito: quem comparasse a descarga com o valor publicado na própria página da versão obtinha uma correspondência perfeita.

O fundador da OVHcloud, Octave Klaba, explicou a causa publicamente: a opção de imutabilidade das versões no GitHub estava desactivada, o que permitiu a uma conta com privilégios suficientes alterar versões já publicadas sem passar pela pipeline de construção. A pipeline da própria OVHcloud não foi comprometida. A opção foi activada e a versão 0.16.0 saiu assinada e imutável.

O detalhe mais útil está na detecção. Segundo a IT-Connect, quem deu o alerta foi a pipeline de integração contínua de um cliente, que tinha registada a impressão digital SHA-256 do ficheiro. A impressão mudou sem aviso, a construção falhou, e o cliente abriu uma questão pública no repositório.

21 de Outubro: o fluxo de publicação da LiteLLM

Dois dias depois, a versão 1.107.0 da LiteLLM foi publicada no PyPI e em imagens Docker com código que recolhe credenciais e abre a porta à execução remota. O relatório oficial do projecto descreve uma sequência que passou por várias barreiras.

A protecção de ramos do GitHub rejeitou a primeira tentativa de alterar o fluxo privado de publicação. Uma credencial de uma conta de programador com privilégios sobrepôs-se a essa protecção e aplicou a alteração. O fluxo alterado passou a construir a partir de um repositório com um nome quase igual ao oficial. A aprovação de produção foi satisfeita com a credencial de uma segunda conta. E uma terceira conta apagou os registos das execuções.

A versão esteve disponível cerca de duas horas antes de ser retirada. A etiqueta de código oficial no GitHub não continha os ficheiros maliciosos. As imagens comprometidas, segundo o próprio relatório, tinham uma assinatura válida, feita com a chave anterior do projecto. O relatório avisa que partes da análise ainda estão em revisão.

O projecto já tinha reforçado o processo depois de um incidente em Março: publicação a partir de um repositório privado, publicadores de confiança, etiquetas Docker imutáveis e imagens assinadas. Como o relatório resume, o atacante teve de comprometer vários controlos independentes para ter sucesso.

O que os dois casos têm em comum

Três pontos atravessam os dois incidentes.

1. A prova vinha do mesmo sítio que o artefacto. Na OVHcloud, a soma de verificação foi reescrita com o binário. Na LiteLLM, a assinatura era válida. Verificar contra uma prova publicada pelo mesmo canal que foi comprometido não prova nada.
2. A defesa que funcionou estava do lado de quem consome. Uma pipeline que fixa versões e impressões digitais trava a mudança silenciosa, porque compara com um valor registado antes do ataque.
3. As credenciais com poder sobre a publicação foram o ponto de entrada. Em ambos os casos, contas legítimas fizeram o que a pipeline de construção existia para controlar.

A escala do problema

A automação que corre em pipelines cresceu mais depressa do que a atenção que lhe é dada. Segundo o Octoverse 2026 do GitHub, foram executados 45 mil milhões de trabalhos de GitHub Actions nos doze meses até Setembro de 2026, contra 14 mil milhões no período anterior.

Cada trabalho que descarrega uma ferramenta, uma imagem ou uma biblioteca é uma entrada. A pergunta deixa de ser se a pipeline é rápida. Passa a ser o que ela aceita sem perguntar.

Quatro práticas que não exigem ferramenta nova

1. Fixar versões e impressões digitais. Ferramentas de construção, imagens base e dependências entram na pipeline com versão exacta e soma de verificação registada no próprio repositório. Uma mudança silenciosa passa a partir a construção, como aconteceu ao cliente da OVHcloud.
2. Verificar na origem, não na mesma página. Preferir versões imutáveis e atestações de proveniência verificadas com a ferramenta do fornecedor, em vez da soma de verificação publicada ao lado do ficheiro.
3. Separar quem altera o fluxo de quem aprova a produção. Alterações ao próprio fluxo de publicação devem passar por revisão, e a aprovação de produção não deve depender de uma única conta. Registos de execução protegidos contra apagamento.
4. Inventariar as credenciais da pipeline. Saber que segredos cada fluxo usa, com que permissões, quem os pode ler e quando são rodados. No caso da OVHcloud, a recomendação a quem foi afectado foi mudar todos os segredos do disco: é mais fácil quando se sabe quais são.

Nenhuma das quatro elimina o risco. Juntas, reduzem a janela em que uma ferramenta adulterada consegue entrar sem que ninguém repare.

Conclusão

Os dois incidentes duraram horas, não dias, e ainda assim tiveram alcance global, porque as ferramentas entram automaticamente em milhares de pipelines. Em ambos, o fornecedor reagiu depressa e explicou publicamente o que aconteceu. A lição para quem consome é outra: a pipeline não é só o caminho por onde o código sai para produção. É também o primeiro sítio onde se pode verificar o que entra.

O enquadramento de quando faz sentido reforçar a equipa interna está em DevOps as a Service, quando faz sentido, e o caminho até produção foi tratado em configurar um pipeline de CI/CD em duas horas. Para rever o que a pipeline aceita hoje sem verificar, é possível agendar uma Sessão de Esclarecimento, sem compromisso.