Você corrigiu o LiteLLM, mas conhece o raio de impacto da sua IA?

Por um breve período, um pacote de código aberto amplamente usado no ecossistema de IA foi comprometido com um malware que rouba credenciais.

LiteLLM, um gateway de modelos usado para encaminhar solicitações a mais de 100 provedores de LLM, era baixado milhões de vezes por dia. Nesse curto período, é provável que as versões maliciosas tenham sido baixadas dezenas de milhares de vezes antes de serem detectadas.

Em teoria, isso deveria ser tranquilizador: o projeto tinha certificações de conformidade, contava com ferramentas de segurança e o problema foi descoberto e corrigido rapidamente. Mas esse é justamente o problema.

Porque esse incidente não foi apenas sobre uma dependência comprometida. Foi um lembrete de como os sistemas modernos de IA realmente falham: não na superfície, mas nas camadas que não conseguimos enxergar por completo.

Um dos primeiros sinais desse impacto já está surgindo. A startup de recrutamento com IA Mercor confirmou que foi “uma entre milhares” de vítimas afetadas pelo ataque à cadeia de suprimentos do LiteLLM. Nesse caso, o comprometimento não parou em um pacote vulnerável; segundo relatos, levou à exfiltração de dados em grande escala, incluindo código-fonte, após o uso de credenciais roubadas para acessar sistemas internos.

É isso que a maioria das equipes não percebe. O risco não está na dependência em si, mas no que ela pode acessar durante a execução. Quando algo como o LiteLLM fica no caminho de execução entre sua aplicação e os provedores de modelos, ele se torna um canal para tudo o que está por trás: APIs, ferramentas, fluxos de trabalho de agentes e dados confidenciais.

Mercor e outras empresas não sofreram uma violação simplesmente porque “usavam o LiteLLM”. Foram comprometidas por causa das conexões do LiteLLM.

No comprometimento original do LiteLLM, o malware em si era relativamente pouco sofisticado. Fazia muito barulho, travava máquinas e foi detectado. Uma versão mais sutil, projetada para exfiltrar silenciosamente credenciais de provedores de modelos, APIs e fluxos de trabalho de agentes, poderia ter passado despercebida por semanas.

E, se isso tivesse acontecido, a maioria das equipes não saberia o que estava realmente em risco. Saberiam que usavam o LiteLLM.

Mas não saberiam:

• Quais modelos eram encaminhados por ele

• Quais provedores estavam envolvidos

• A quais ferramentas e sistemas esses modelos podiam acessar

• Como esse risco se propagava pelas aplicações

Essa é a lacuna. E é por isso que incidentes como esse já não são apenas problemas de cadeia de suprimentos: no fim das contas, são uma questão de visibilidade dos sistemas de IA.

Quando o comprometimento do LiteLLM veio à tona, a maioria das equipes fez exatamente o que se esperava. Verificou as dependências, identificou as versões vulneráveis e agiu rapidamente para aplicar uma correção ou fixar uma versão segura. Do ponto de vista tradicional da segurança de aplicações, trabalho bem-feito.

Mas isso levanta uma pergunta mais interessante, que a maioria das equipes não para para fazer: O que você realmente corrigiu?

É preciso ir além de descobrir onde o LiteLLM era usado e entender o que ele fazia dentro do seu sistema, a que estava conectado e que riscos introduzia para além do próprio pacote. Porque, nas aplicações de IA, é aí que as coisas se complicam.

Onde a visibilidade tradicional deixa a desejar

O LiteLLM não é apenas mais uma biblioteca quietinha no código. Ele fica diretamente no caminho de execução entre sua aplicação e os modelos dos quais ela depende. Encaminha solicitações, abstrai provedores e, em última análise, influencia o comportamento do sistema durante a execução.

Isso significa que, quando o LiteLLM é comprometido, o impacto não se limita aos repositórios que incluem o pacote. Ele se estende aos modelos acionados por meio dele, aos provedores envolvidos, às ferramentas que esses modelos podem acessar e aos fluxos de trabalho de agentes que dependem dele.

É aqui que a maioria das equipes perde a visibilidade. Uma única linha de código que especifica um modelo pode parecer insignificante, mas registra uma série de decisões sobre provedores, recursos e acessos que não aparecem em nenhum gráfico de dependências.

Quando isso se multiplica entre repositórios, equipes e fluxos de trabalho de agentes em constante evolução, o problema deixa de ser apenas uma questão de dependências. O resultado é um sistema difícil de enxergar e entender por completo.

A lacuna que Evo AI-SPM foi criado para fechar

Em vez de se concentrar apenas nas dependências existentes, Evo se concentra em como a IA está sendo usada. No caso do LiteLLM, isso significa identificá-lo como um gateway de modelos, mapear quais provedores e modelos passam por ele, descobrir as ferramentas e APIs com as quais esses modelos interagem e conectar tudo isso aos fluxos de trabalho de agentes que definem o comportamento do sistema.

O resultado é um AI-BOM: um mapa dinâmico do próprio sistema de IA, não apenas dos componentes que o compõem.

Por que o contexto muda tudo

Esse contexto adicional muda profundamente a forma como as equipes respondem a incidentes. Se você sabe apenas que o LiteLLM foi comprometido, o próximo passo é simples: corrigi-lo. Mas, quando você entende como ele é usado, a resposta fica mais criteriosa.

Você pode começar perguntando se o tráfego está sendo encaminhado a provedores de modelos não aprovados, quais agentes dependem desse caminho, quais sistemas externos ficam expostos por ele e se alguma política rege essas interações. Essa é a diferença entre reagir a uma vulnerabilidade e entender sua exposição real.

É assim que as aplicações de IA já são construídas

Isso reflete a quantidade de aplicações com IA que já estão sendo desenvolvidas. Um desenvolvedor pode usar uma estrutura para orquestrar um agente, contar com o LiteLLM para abstrair o acesso aos modelos e conectar esse agente a ferramentas externas ou APIs para executar tarefas. Do ponto de vista tradicional, isso aparece como uma dependência vulnerável. Do ponto de vista do sistema, representa uma cadeia de decisões, integrações e comportamentos que vai muito além do próprio pacote.

A IA que você nem sabe que tem

O que muitas vezes surpreende as equipes é a quantidade de IA que já existe em seus ambientes. Muitas acreditam que ainda estão no início da adoção de IA, até descobrirem usos dispersos de gateways de modelos, estruturas de orquestração e padrões emergentes de agentes em seus códigos.

Nada disso está centralizado, boa parte não é governada e, ainda assim, já faz parte dos sistemas de produção. Incidentes como o comprometimento do LiteLLM não criam essa complexidade: eles a revelam.

Você ainda precisa de SCA (mas não só de SCA)

Isso não é uma falha da análise de composição de software (SCA). Ferramentas como Snyk Open Source sinalizam versões comprometidas do LiteLLM, mostram onde elas aparecem nos repositórios — inclusive como dependências transitivas —, alertam as equipes rapidamente e oferecem orientações claras para corrigir o problema.

Esse sinal é fundamental; sem ele, as equipes nem saberiam que há um problema. Mas a SCA foi criada para responder a uma pergunta bem específica: “Esta dependência está vulnerável?” O desafio é que os sistemas modernos de IA não se limitam às dependências.

Uma reação comum a incidentes como esse é dizer: “A SCA já detectou o problema”. E isso é verdade, mas pressupõe que a dependência é o sistema. Na realidade, ela é apenas o ponto de entrada. O sistema inclui tudo o que essa dependência possibilita: acesso a modelos, execução de ferramentas, orquestração de agentes e tomada de decisões dinâmica. Se você não consegue enxergar essa camada, não entende por completo onde está o risco.

O comprometimento do LiteLLM é apenas um exemplo, mas deixa clara a mudança: se você olha apenas para as dependências, não está enxergando o sistema. A SCA mostra que há algo errado; Evo ajuda você a entender o que isso significa no contexto do seu sistema de IA e permite controlá-lo.

Como usar Evo AI-SPM

Com Evo AI-SPM, é simples e rápido visualizar isso no seu próprio ambiente. Em poucos minutos, você pode:

• Identificar onde o LiteLLM (e gateways de modelos semelhantes) aparece nos seus repositórios

• Ver quais provedores e modelos estão sendo acessados por meio deles

• Descobrir ferramentas, APIs, agentes e fluxos de trabalho conectados

• Descobrir a “IA invisível” que as ferramentas de segurança tradicionais não detectam

• Aplicar políticas para controlar o que será permitido daqui para frente

A maioria das equipes se surpreende com o que encontra na primeira análise, porque a realidade é esta: se você desenvolve com IA, já tem uma cadeia de suprimentos de IA. Talvez só ainda não consiga enxergá-la.

Snyk Open Source ajuda você a encontrar vulnerabilidades.

Evo AI-SPM mostra o sistema e ajuda você a protegê-lo.

Comece por aí.