¿Aplicaste el parche a LiteLLM? Pero ¿conoces todo el alcance del riesgo de la IA?

Durante un breve periodo, un paquete open source muy utilizado en el ecosistema de IA fue comprometido con malware que robaba credenciales.

LiteLLM, una puerta de enlace de modelos que se usa para dirigir solicitudes a más de 100 proveedores de LLM, se ha descargado millones de veces al día. Durante ese breve periodo, es probable que las versiones maliciosas se descargaran decenas de miles de veces antes de que se detectara el problema.

En teoría, esto debería haber sido tranquilizador: el proyecto contaba con certificaciones de cumplimiento, tenía herramientas de seguridad implementadas y el problema se detectó y corrigió rápidamente. Pero ese es precisamente el problema.

Porque este incidente no se trató solo de una dependencia comprometida. Fue un recordatorio de cómo fallan realmente los sistemas de IA modernos: no en la superficie, sino en las capas que no vemos por completo.

Ya empieza a surgir una de las primeras señales del impacto. La startup de reclutamiento con IA Mercor confirmó que fue “una de miles” de víctimas posteriores afectadas por el ataque a la cadena de suministro de LiteLLM. En su caso, el compromiso no se limitó a un paquete vulnerable; según los informes, provocó una exfiltración de datos a gran escala, incluido código fuente, después de que se usaran credenciales robadas para acceder a sistemas internos.

Eso es lo que la mayoría de los equipos no ve. El riesgo no está en la dependencia en sí, sino en aquello a lo que puede acceder durante la ejecución. Cuando algo como LiteLLM se encuentra en la ruta de ejecución entre tu aplicación y los proveedores de modelos, se convierte en un conducto hacia todo lo que hay detrás: API, herramientas, flujos de trabajo de agentes y datos confidenciales.

Mercor y otros no sufrieron una brecha simplemente porque “usaban LiteLLM”. La sufrieron por las conexiones que tenía LiteLLM.

En el compromiso original de LiteLLM, el malware era relativamente poco sofisticado. Hacía mucho ruido, bloqueaba máquinas y lo detectaron. Una versión más sutil, diseñada para exfiltrar credenciales en silencio de distintos proveedores de modelos, API y flujos de trabajo de agentes, podría haber pasado desapercibida durante semanas.

Y, de haber ocurrido, la mayoría de los equipos no habría sabido qué estaba realmente en riesgo. Habrían sabido que usaban LiteLLM.

No habrían sabido:

• Qué modelos se estaban usando a través de esa plataforma

• Qué proveedores estaban involucrados

• A qué herramientas y sistemas podían acceder esos modelos

• Cómo se propagaba ese riesgo por sus aplicaciones

Esa es la brecha. Y por eso, estos incidentes ya no son solo problemas de la cadena de suministro: en última instancia, se trata de la visibilidad de los sistemas de IA.

Cuando ocurrió el compromiso de LiteLLM, la mayoría de los equipos hizo lo que cabía esperar. Revisaron sus dependencias, identificaron las versiones vulnerables y se apresuraron a aplicar un parche o fijar una versión segura. Desde la perspectiva de la seguridad de aplicaciones tradicional, hicieron un buen trabajo.

Pero esto plantea una pregunta más interesante, una que la mayoría de los equipos no se detiene a hacer: ¿Qué solucionaste realmente?

Ir más allá de identificar dónde se usaba LiteLLM y averiguar qué hacía dentro de tu sistema, a qué estaba conectado y qué riesgos introducía más allá del paquete. Porque en las aplicaciones de IA es ahí donde las cosas se complican.

Dónde falla la visibilidad tradicional

LiteLLM no es una biblioteca más que pasa desapercibida en una base de código. Está directamente en la ruta de ejecución entre tu aplicación y los modelos de los que depende. Dirige solicitudes, abstrae proveedores y, en última instancia, determina el comportamiento de tu sistema durante la ejecución.

Eso significa que, cuando LiteLLM se ve comprometido, el impacto no se limita a los repositorios que incluyen el paquete. Se extiende a los modelos a los que se llama a través de él, los proveedores involucrados, las herramientas a las que pueden acceder esos modelos y los flujos de trabajo de agentes que dependen de él.

Aquí es donde la mayoría de los equipos pierde visibilidad. Una sola línea de código que especifica un modelo puede parecer insignificante, pero encierra una serie de decisiones sobre proveedores, capacidades y accesos que no quedan registradas en ningún gráfico de dependencias.

Al multiplicar esto entre repositorios, equipos y flujos de trabajo de agentes en constante evolución, lo que surge no es solo un problema de dependencias. Es un sistema difícil de ver o comprender por completo.

La brecha que Evo AI-SPM está diseñado para cerrar

En lugar de centrarse únicamente en las dependencias existentes, Evo se centra en cómo se usa la IA. En el caso de LiteLLM, esto significa identificarlo como una puerta de enlace de modelos, mapear qué proveedores y modelos se usan a través de ella, descubrir las herramientas y API con las que interactúan esos modelos y vincular todo con los flujos de trabajo de agentes que determinan el comportamiento del sistema.

El resultado es un AI-BOM: un mapa dinámico del sistema de IA en sí, no solo de los componentes que lo conforman.

Por qué el contexto lo cambia todo

Ese contexto adicional cambia radicalmente la forma en que los equipos responden a los incidentes. Si lo único que sabes es que LiteLLM está comprometido, el siguiente paso es obvio: corregirlo. Pero cuando entiendes cómo se usa, la respuesta se vuelve más matizada.

Puedes empezar por preguntar si se está dirigiendo el tráfico a proveedores de modelos no aprobados, qué agentes dependen de esa ruta, qué sistemas externos están expuestos a través de ella y si existen políticas que rijan esas interacciones. Esa es la diferencia entre reaccionar ante una vulnerabilidad y comprender tu exposición real.

Así se crean ya las aplicaciones de IA

Esto refleja la cantidad de aplicaciones con IA que ya se están creando. Un desarrollador puede usar un framework para orquestar un agente, recurrir a LiteLLM para abstraer el acceso a modelos y conectar ese agente con herramientas o API externas para completar tareas. Desde una perspectiva tradicional, esto aparece como una dependencia vulnerable. Desde la perspectiva del sistema, representa una cadena de decisiones, integraciones y comportamientos que van mucho más allá del paquete.

La IA que no sabes que tienes

A los equipos suele sorprenderles la cantidad de IA que ya existe en sus entornos. Muchos creen que apenas están empezando a adoptar la IA, hasta que descubren que en sus bases de código hay usos dispersos de puertas de enlace de modelos, frameworks de orquestación y nuevos patrones de agentes.

Nada de esto está centralizado, gran parte no está gobernada y, aun así, ya forma parte de los sistemas de producción. Incidentes como el compromiso de LiteLLM no crean esta complejidad; la dejan al descubierto.

Sigues necesitando SCA (pero no solo SCA)

Esto no es un fallo del análisis de composición de software (SCA). Herramientas como Snyk Open Source detectan versiones comprometidas de LiteLLM, muestran en qué partes de los repositorios existen esas versiones —incluidas las dependencias transitivas—, alertan rápidamente a los equipos y ofrecen indicaciones claras para corregir el problema.

Esa señal es fundamental y, sin ella, los equipos ni siquiera sabrían que hay un problema. Pero SCA está diseñado para responder una pregunta muy específica: “¿Es vulnerable esta dependencia?” El reto es que los sistemas modernos de IA no se limitan a las dependencias.

Una reacción común ante incidentes como este es decir: “SCA ya lo detectó”. Y es cierto, pero eso presupone que la dependencia es el sistema. En realidad, es solo el punto de entrada. El sistema abarca todo lo que esa dependencia hace posible: acceso a modelos, ejecución de herramientas, orquestación de agentes y toma de decisiones dinámica. Si no puedes ver esa capa, no comprendes del todo dónde está tu riesgo.

El compromiso de LiteLLM es solo un ejemplo, pero deja clara la transición: si solo observas las dependencias, no ves el sistema. SCA te indica que algo anda mal; Evo te ayuda a entender qué significa en el contexto de tu sistema de IA y te permite controlarlo.

Cómo usar Evo AI-SPM

La forma más rápida de verlo en tu propio entorno es usar Evo AI-SPM. En cuestión de minutos, puedes:

• Identificar dónde se encuentra LiteLLM (y otras puertas de enlace de modelos similares) en tus repositorios

• Ver qué proveedores y modelos se usan a través de esas puertas de enlace

• Descubrir herramientas, API, agentes y flujos de trabajo conectados

• Detectar la “IA en la sombra” que no es visible con las herramientas de seguridad tradicionales

• Aplicar políticas para controlar qué se permitirá en adelante

A la mayoría de los equipos les sorprende lo que encuentran en el primer análisis, porque la realidad es esta: si desarrollas con IA, ya tienes una cadena de suministro de IA. Puede que todavía no puedas verla.

Snyk Open Source te ayuda a encontrar vulnerabilidades.

Evo AI-SPM te muestra el sistema y te ayuda a protegerlo.

Empieza por ahí.