Como Fortalecer a Segurança da Cadeia de Dependências em LLMs: Aprendizados do Incidente LiteLLM

Em 24 de março de 2026, o pacote Python LiteLLM, com mais de 95 milhões de downloads mensais, sofreu um comprometimento grave. As versões 1.82.7 e 1.82.8 disponibilizadas no PyPI continham um payload malicioso que exfiltrava chaves SSH, credenciais de provedores de nuvem, segredos Kubernetes, chaves de API, carteiras de criptomoedas e senhas de banco de dados para servidores controlados por atacantes.

O que aconteceu no incidente LiteLLM?

O grupo de ameaças TeamPCP obteve acesso às credenciais de publicação do mantenedor do LiteLLM no PyPI. Com isso, publicaram versões maliciosas diretamente no repositório PyPI, sem modificar o código-fonte no GitHub, que permaneceu limpo. Essa discrepância entre o código-fonte e o artefato distribuído foi o ponto crítico do ataque.

O malware explorava um arquivo .pth, um mecanismo pouco conhecido do Python que executa código automaticamente na inicialização do interpretador, mesmo sem importar explicitamente o pacote. Assim, apenas ter o LiteLLM instalado já permitia que o código malicioso coletasse credenciais, estabelecesse persistência via systemd e tentasse movimentação lateral em clusters Kubernetes.

Segundo Andrej Karpathy, a versão comprometida ficou disponível por menos de uma hora e foi descoberta devido a um bug no malware que causou a queda de uma máquina. Sem esse erro, o ataque poderia ter permanecido oculto por dias ou semanas.

Por que bibliotecas gateway de LLM são alvos críticos?

Bibliotecas gateway para LLMs (Large Language Models) armazenam as chaves de API para diversos provedores como OpenAI, Anthropic, Google, Azure e Cohere. Isso as torna alvos de alto valor, pois comprometê-las significa acesso a todos os serviços conectados na organização, ampliando o impacto do ataque.

5 Medidas Práticas para Reduzir Riscos na Cadeia de Dependências

A seguir, apresentamos práticas recomendadas baseadas no incidente LiteLLM para fortalecer sua segurança:

1. Fixe versões exatas e verifique hashes
   Evite especificadores de versão flexíveis em dependências críticas. Use versões exatas e verifique os hashes para garantir a integridade dos pacotes. Exemplo de comando:
   pip install --require-hashes -r requirements.txt
   Seu arquivo requirements.txt deve conter linhas como:
   litellm==1.82.6 --hash=sha256:<hash-conhecido>
   Os hashes podem ser obtidos diretamente no PyPI em https://pypi.org/project/litellm/1.82.6/#files clicando em “view details” ao lado do arquivo wheel.
2. Audite arquivos .pth nos ambientes Python
   Arquivos .pth podem executar código na inicialização do interpretador, apesar de sua função original ser apenas incluir diretórios ao path. Para encontrar possíveis abusos, execute:
   find $(python -c "import site; print(site.getsitepackages()[0])") -name "*.pth" -exec grep -El "import|exec" {} \;
   Qualquer arquivo que contenha comandos import ou exec pode representar risco de segurança ou impacto na performance.
3. Use o recurso de “trusted publishers” do PyPI para seus pacotes
   Se você mantém pacotes Python, evite armazenar tokens de API ou senhas para publicação no PyPI. Utilize o mecanismo “trusted publishers” baseado em OIDC, que vincula a publicação a workflows específicos do GitHub Actions, eliminando o vetor de ataque via tokens comprometidos. Saiba mais em PyPI Trusted Publishers.
4. Compare artefatos distribuídos com o código-fonte
   Nunca assuma que o pacote disponível no PyPI é idêntico ao código-fonte no GitHub. Para dependências críticas, baixe os pacotes e faça a comparação manual:
   pip download <pacote>==<versão> --no-deps -d /tmp/check
   Em seguida, descompacte o arquivo wheel e compare com o código-fonte etiquetado para detectar divergências.
5. Utilize um espelho privado de pacotes com lista de permissões
   Em ambientes de produção, configure um proxy ou espelho privado (como devpi ou Artifactory) que só forneça versões previamente auditadas, bloqueando versões comprometidas antes que cheguem à sua infraestrutura.

Como a Mozilla.ai protege suas dependências

No projeto any-llm, as publicações no PyPI são feitas exclusivamente através de workflows do GitHub Actions utilizando PyPI trusted publishers. Nenhum mantenedor possui token de API do PyPI armazenado localmente. A autenticação OIDC garante que mesmo uma conta de desenvolvedor comprometida não possa publicar versões maliciosas.

Facilidade para migrar do LiteLLM

Se você deseja se afastar do LiteLLM após o incidente, o any-llm é um substituto compatível com proxies OpenAI, com um guia de migração simples em 2 passos.

Seu gateway LLM é o ponto de maior exposição para credenciais sensíveis e deve ser tratado com o mesmo rigor de um banco de dados ou gerenciador de segredos. A lição do LiteLLM reforça a importância de auditar não só o código-fonte, mas também os pacotes distribuídos e os processos de publicação.

Links úteis

• Guia de Migração any-llm
• PyPI Trusted Publishers
• Repositório LiteLLM
• Workflow CI do any-llm
• Fonte original Mozilla AI