Ataques a la cadena de suministro en la inteligencia artificial: lo que revelan los incidentes recientes sobre la seguridad de la infraestructura de inteligencia artificial

El 24 de marzo de 2026, un investigador de FutureSearch estaba realizando una tarea rutinaria. La tarea consistía en instalar un paquete de Python para un proyecto. En cuestión de minutos, la estación de trabajo comenzó a comportarse de forma errática.

El uso de memoria creció considerablemente. Aparecieron procesos no reconocidos. El sistema se bloqueó. El investigador había lanzado, sin saberlo, uno de los ataques a la cadena de suministro de software más sofisticados jamás lanzados contra el ecosistema de la IA. Este ataque había estado activo durante meses e infectó miles de entornos de desarrolladores antes de que nadie reconociera públicamente su presencia.

Este artículo examinará los eventos que tuvieron lugar y explicará cómo las herramientas de inteligencia artificial son particularmente vulnerables a este tipo de ataque. También analizará cómo los equipos de ingeniería pueden protegerse.

Qué pasó: un ataque a la cadena de suministro a tres pasos de profundidad

El grupo de actores de amenazas identificado como «TeamPCP», que ha estado activo al menos desde diciembre de 2025 y que los investigadores de Wiz han rastreado las nueve fases de este ataque en curso, no tenía como objetivo directo su objetivo final. Por el contrario, este grupo de actores de amenazas llevó a cabo una operación cuidadosa, ataque a la cadena de suministro en varias etapas.

Paso 1: El 19 de marzo, TeamPCP puso en peligro Trivy, un escáner de seguridad de código abierto ampliamente utilizado e integrado en las canalizaciones de CI/CD de muchos proyectos.

Paso 2: Con ese punto de apoyo, obtuvieron las credenciales de publicación de PyPI de un responsable de una popular biblioteca proxy de LLM que se descargaba aproximadamente 3,4 millones de veces al día.

Paso 3: El 24 de marzo, subieron dos versiones maliciosas del paquete a PyPI. Las versiones comprometidas estuvieron activas durante aproximadamente tres horas antes de que PyPI las pusiera en cuarentena.

Esta es la característica que define a los ataques modernos a la cadena de suministro: el atacante nunca tiene que violarte directamente. Violan a alguien en quien tus herramientas confían y dejan que esa confianza las lleve el resto del camino.

Dentro de la carga útil: tres etapas de compromiso

El paquete malicioso ejecutó una sofisticada carga útil de tres etapas que los investigadores de seguridad de Snyk han documentado en detalle.

Etapa 1: Recopilación de información. La carga útil recopiló silenciosamente todo lo que pudo encontrar: claves privadas SSH, credenciales de acceso a AWS y GCP, principios de servicio de Azure, configuraciones de Kubernetes, archivos.env, credenciales de git, contraseñas de bases de datos, historial de shell, secretos de CI/CD y frases iniciales de monederos de criptomonedas.

Etapa 2: Cifrado y exfiltración. Los datos recopilados se cifraron y se transmitieron a un servidor controlado por un atacante. Durante este proceso, se crearon archivos temporales (session.key, payload.enc, tpcp.tar.gz) en el directorio temporal del sistema.

Etapa 3: Persistencia y movimiento lateral. La carga útil instaló un script de Python de puerta trasera disfrazado de un servicio de systemd llamado «Servicio de telemetría del sistema». Este script de persistencia consultaba una URL controlada por un atacante cada cinco minutos en busca de nuevos comandos, y era capaz de extenderse por todo el clúster de Kubernetes mediante la implementación de pods privilegiados en todos los nodos de kube-system.

Lo que lo hacía especialmente peligroso era el mecanismo de entrega: un archivo.pth. Los archivos de configuración de rutas de Python se ejecutan automáticamente cada vez que se inicia cualquier proceso de Python, incluido el propio pip, los pasos de construcción de CI/CD y los ejecutores de pruebas. No tenías que ejecutar la aplicación. Solo tenías que haber instalado el paquete y la carga útil se ejecutó.

Por qué la infraestructura de IA es un objetivo especial

El paquete afectado no se eligió al azar. Una de las posiciones más privilegiadas en la gama de software moderna es la de los proxies y pasarelas de IA de los modelos de lenguaje grande (LLM). Cuando instalas y configuras una puerta de enlace de LLM, la colocas en posición de estar directamente entre las aplicaciones y los proveedores de servicios de IA que se utilizan. Tiene acceso a las claves de API de OpenAI, a las credenciales de Anthropic y a las cuentas de servicio de Azure y Google Cloud Platform. Tiene acceso a las variables de entorno y, en muchos casos, al administrador de secretos. Esto es por diseño y es necesario para enrutar las solicitudes, hacer cumplir los límites de velocidad y registrar el uso. Este es el comportamiento previsto.

Esto también significa que si la puerta de enlace LLM y/o cualquiera de sus dependencias se ven comprometidas, el atacante tiene una visibilidad total de la infraestructura de IA. Los investigadores de Sonatype escribieron en su informe sobre este incidente: «Dado que LitELLM normalmente se encuentra directamente entre las aplicaciones y varios proveedores de servicios de IA, suele tener acceso a las claves de API, las variables de entorno y otros datos de configuración confidenciales. Poner en peligro un paquete en esta posición permite a los atacantes interceptar y filtrar valiosos secretos sin necesidad de acceder directamente a los sistemas principales».

Por qué los marcos de cumplimiento no lo detectaron

El paquete implicado tenía las certificaciones SOC 2 tipo 1 e ISO 27001. Vale la pena examinarlo no para criticar esos marcos (son importantes y los equipos que los persiguen están haciendo lo correcto), sino porque ilustran una brecha estructural.

Los marcos de cumplimiento auditan lo que está haciendo comparándolo con una lista de verificación. Abarcan los controles de acceso, el manejo de datos y la respuesta a los incidentes. Por lo general, no examinan si un agente de amenazas ha puesto en peligro el escáner de seguridad de su proceso de CI/CD y, a continuación, ha optado por robarle sus credenciales de publicación de PyPI.

Incluso la verificación estándar de pip hash no habría detectado este ataque. El archivo.pth malicioso de la versión comprometida se declaró correctamente en el archivo RECORD del paquete con un hash coincidente. El paquete pasó todas las comprobaciones de integridad que proporciona PyPI. Era un paquete válido que resultó estar armado.

Este es el seguridad de la cadena de suministro brecha que el ecosistema de IA necesita cerrar específicamente: la pregunta no es simplemente «¿son seguros nuestros sistemas?» La pregunta es: «¿son seguras las herramientas que utilizamos para crear y proteger nuestros sistemas?»

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

Evaluating an AI Gateway?

A practical guide used by platform & infra teams

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Cómo piensa TrueFoundry sobre este problema

En TrueFoundry, seguridad de la cadena de suministro es una preocupación de primera clase en la forma en que diseñamos nuestra plataforma mLOps, no una idea de último momento.

Cuando las empresas implementan modelos y Puertas de enlace LLM a través de TrueFoundry, nos hacemos una pregunta diferente: no solo «¿es seguro este punto final?» pero «¿cuál es el radio de explosión si algún componente de esta pila se ve comprometido?»

Algunos principios dan forma a la forma en que construimos:

La infraestructura se ejecuta en su VPC. Cuando su infraestructura de IA se ejecuta dentro de los límites de su propia nube, los secretos nunca viajan a sistemas externos. Incluso si una dependencia de alguna parte del ecosistema se viera comprometida, no se podría acceder al punto final de la exfiltración desde el perímetro de la red.

Las dependencias se fijan y auditan. En lugar de extraer silenciosamente las últimas versiones de cada compilación, TrueFoundry mantiene las dependencias ancladas y revisadas en toda la pila de la plataforma. Esto elimina toda una clase de vectores de cadena de suministro.

El aislamiento de los componentes limita el radio de explosión. Un compromiso en una capa de la pila no otorga automáticamente el acceso a otra. Principio de mínimo privilegio, que se aplica a nivel de infraestructura.

Nada de esto es ingeniería exótica. Es la disciplina aplicada a un modelo de amenazas que las herramientas de inteligencia artificial, como industria, no se han tomado suficientemente en serio: la amenaza no llega a través de su firewall. Viene a través de tu requirements.txt.

Qué debe hacer su equipo ahora mismo

Si utilizas herramientas de IA basadas en Python, como lo hacen casi todos los equipos que crean LLM, vale la pena priorizar de inmediato las siguientes acciones.

1. Compruebe las versiones de los paquetes instalados. Ejecute pip show litellm | versión grep. Si el resultado es 1.82.7 o 1.82.8, considera que el sistema está en peligro y no lo actualice sin más. Es posible que la carga útil ya se haya ejecutado. Reconstruya desde un estado limpio en un equipo que se sepa que está limpio.

2. Audite los archivos.pth en máquinas y ejecutores de CI.

find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \
  -name "*.pth" -exec grep -l "base64\|subprocess\|exec" {} \;

3. Compruebe si hay artefactos de persistencia.

ls -la ~/.config/sysmon/sysmon.py 2>/dev/null && echo "BACKDOOR FOUND"
systemctl --user status sysmon.service 2>/dev/null
ls /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc 2>/dev/null

4. Rote las credenciales de forma agresiva. Si alguna máquina afectada tenía acceso a credenciales en la nube, claves SSH, claves de API, tokens de cuentas de servicio de Kubernetes o contraseñas de bases de datos, cámbielas todas ahora. No evalúe, rote. La carga útil estaba dirigida específicamente a los secretos de los clústeres de AWS Secrets Manager, SSM Parameter Store y Kubernetes en todos los espacios de nombres.

5. Comprueba si hay pods maliciosos en Kubernetes.

kubectl get pods -A | grep "node-setup-"

Los pods llamados node-setup- {node_name} en el espacio de nombres del sistema kube son un indicador conocido de que esta campaña está comprometida.

6. Avance hacia un registro de paquetes privado. PyPI no es la única opción para la resolución de dependencias. Una réplica de paquetes privada con hashes anclados y un flujo de trabajo de aprobación eliminan toda esta clase de vectores de ataque. Herramientas como Artifactory, AWS CodeArtifact o Google Artifact Registry pueden actuar como intermediarias.

7. Trate su cadena de suministro de CI/CD como una superficie de ataque. El compromiso inicial de la campaña de TeamPCP no estaba en la biblioteca objetivo, sino en el escáner de seguridad utilizado en el proceso de CI de esa biblioteca. Tu infraestructura de compilación, tus GitHub Actions y tus integraciones con terceros forman parte de tu superficie de ataque. Auditalas en consecuencia.

El patrón más amplio: esto no es aislado

Lo que hace que este caso sea particularmente interesante es que no fue un ataque oportunista. Más bien, TeamPCP ha estado llevando a cabo esta ardua campaña al menos desde diciembre de 2025. Antes de atacar Litellm, TeamPCP puso en peligro el escáner de seguridad Trivy de Aqua (19 de marzo), las extensiones VS Code y GitHub Actions de CheckMarx (23 de marzo) y varios paquetes de NPM que contenían un gusano que se autopropagaba.

Tenga en cuenta que el par de claves RSA utilizado es idéntico al utilizado en todos los demás ataques, al igual que el nombre del paquete tpcp.tar.gz y los repositorios de GitHub con el prefijo tpcp-docs. Esto sugiere que TeamPCP es un actor de amenazas profesional que ejecuta su campaña de forma metódica.

La implicación aquí es que los equipos que se han visto comprometidos por esta campaña no fueron negligentes. Más bien, se basaron en las mejores prácticas: aprovechar un software de código abierto muy popular y bien revisado.

Lo que hace que esto sea interesante es que TeamPCP no ha identificado ninguna debilidad en las defensas de ninguna organización. Más bien, TeamPCP ha identificado una debilidad en la forma en que el ecosistema de IA en general ha abordado la confianza dentro de su cadena de dependencia.

El problema de confianza que la infraestructura de IA debe resolver

El ecosistema de IA ha creado algo extraordinario en muy poco tiempo. La rapidez y la apertura que lo hicieron posible —la cultura de instalar y compartir pip, de aprovechar el trabajo de los demás— son realmente valiosas y vale la pena preservarlas.

Pero velocidad sin seguridad de la cadena de suministro crea deuda. La superficie de ataque de una IA moderna ya no son solo los puntos finales a los que expones. Todos los paquetes de tu árbol de dependencias, todas las herramientas de tu proceso de CI/CD y cada componente de código abierto tienen acceso a tus secretos durante la compilación o el tiempo de ejecución.

Cerrar esta brecha requiere más que una mejor respuesta a los incidentes por parte de los equipos afectados. Es necesario que todo el ecosistema de infraestructuras de IA (responsables del mantenimiento, proveedores de plataformas, empresas y equipos de seguridad) consideren la procedencia de la cadena de suministro como un problema de ingeniería de primera clase.

El investigador cuya máquina se estrelló probablemente no pensó que estaba a punto de exponer una campaña de meses dirigida a la infraestructura de inteligencia artificial. Tampoco lo hizo ninguno de los desarrolladores que ejecutaron una instalación rutinaria de pip. Esa es la naturaleza de ataques a la cadena de suministro de software. Para cuando los ves, el daño a menudo ya está hecho.

La industria de la IA puede construir mejor. Tiene que hacerlo.

Preguntas frecuentes

¿Qué es un ataque a la cadena de suministro de software?

Un ataque a la cadena de suministro de software se produce cuando un actor de amenazas compromete un componente confiable antes del objetivo final (como una herramienta de desarrollo, una biblioteca de código abierto o una canalización de CI/CD) y lo usa para distribuir código malintencionado a todos los usuarios intermedios de ese componente. En lugar de atacar directamente a una organización, los atacantes se aprovechan de la confianza implícita que los desarrolladores depositan en los paquetes y herramientas más utilizados.

¿Cómo pueden los equipos de IA y ML proteger su infraestructura de los ataques a la cadena de suministro?

Proteger la infraestructura de IA y ML de los ataques a la cadena de suministro requiere varias medidas complementarias. Los equipos deben utilizar un registro de paquetes privado (como AWS CodeArtifact, Google Artifact Registry o Artifactory) con hashes de dependencia anclados en lugar de extraerlos directamente de una PyPI pública. Al auditar con regularidad los archivos.pth de los directorios de paquetes de sitios de Python, se pueden detectar pronto adiciones malintencionadas. La ejecución de una infraestructura de IA (incluidas las pasarelas de LLM y los componentes de servicio de modelos) dentro de una VPC privada limita la capacidad de un atacante de filtrar las credenciales a servidores externos, incluso si una dependencia se ve comprometida. Mantener una lista de materiales de software (SBOM) para su paquete de aprendizaje automático permite identificar más rápidamente la exposición cuando se descubre un nuevo incidente. Por último, las propias canalizaciones de CI/CD deben tratarse como una superficie de ataque: las herramientas que se utilizan para crear y proteger el software (incluidos los escáneres de seguridad y las GitHub Actions) pueden verse comprometidas, y lo han hecho, en el marco de campañas más amplias de la cadena de suministro.

¿Cuáles son los factores que los equipos deben tener en cuenta al evaluar la puerta de enlace segura de LLM para mitigar los riesgos de los ataques a la cadena de suministro?

La puerta de enlace LLM debe funcionar en la VPC de la organización. De esta forma, si las dependencias se ven comprometidas, no hay rutas de exfiltración. Las dependencias deben fijarse y auditarse en lugar de resolverse en el momento de la instalación mediante registros públicos. Las credenciales no se deben administrar mediante variables de entorno, sino que se deben administrar mediante el administrador de secretos nativo del proveedor de la nube. También se debe llevar a cabo un registro de auditoría de todas las invocaciones del modelo, el uso de las claves y los cambios de configuración. De esta forma, cualquier comportamiento anormal se puede identificar fácilmente. TrueFoundry tiene todas estas configuraciones configuradas de forma predeterminada, lo que reduce la superficie de ataque en comparación con las herramientas de código abierto autogestionadas.