La Trampa de las Dependencias: Riesgos en la Cadena de Suministro del Código Generado por IA (Parte 4)

Publicado el mayo 8, 2026 por Simon Roses

Serie Vibe Coding Security

  1. ¿Qué es Vibe Coding Security? Guía de Campo para 2026
  2. El OWASP Top 10 para Aplicaciones Vibe-Coded
  3. Anatomía de una Brecha de Vibe Coding: Lecciones de los Peores Incidentes de 2026
  4. La Trampa de las Dependencias: Riesgos en la Cadena de Suministro del Código Generado por IA (estás aquí)
  5. Autenticación y Secretos: Lo que la IA Siempre Hace Mal
  6. [Escaneando Aplicaciones Vibe-Coded: Por Qué el SAST/DAST Tradicional Se Queda Corto] (https://simonroses.com/es/2026/05/escaneando-aplicaciones-vibe-coded-por-que-el-sast-dast-tradicional-se-queda-corto-parte-6/)
  7. Prompt Engineering para Código Seguro (próximamente)
  8. El Checklist de Seguridad del Fundador (próximamente)
  9. Securizando el Pipeline de Codificación con IA (próximamente)
  10. El Futuro de Vibe Coding Security (próximamente)

Tiempo de lectura: 15 minutos

TL;DR

Cada vez que una herramienta de codificación con IA escribe una sentencia import o añade un paquete a tu package.json, está tomando una decisión de cadena de suministro en tu nombre. Los números son preocupantes: el 80% de las dependencias sugeridas por IA contienen riesgos conocidos, el 34% ni siquiera existen en los registros de paquetes, y casi la mitad de las que sí existen contienen vulnerabilidades conocidas. Este artículo cubre ambas caras de la trampa de dependencias. Por un lado, los vibe coders que instalan a ciegas lo que la IA sugiere — incluyendo paquetes que la IA se inventó. Por otro, los atacantes que han descubierto que el código generado por IA es el vector perfecto para ataques a la cadena de suministro, construyendo gusanos autopropagantes y secuestrando sistemas de compilación para recopilar credenciales de desarrolladores. Tres casos, una conclusión: si no auditas tus dependencias, otra persona las está eligiendo por ti — y sus intenciones no son buenas.

Los Números que Deberían Quitarte el Sueño

Antes de entrar en los casos, quiero enmarcar la escala de este problema con datos del informe State of Dependency Management 2025 de Endor Labs. Analizaron 10.663 repositorios en GitHub que implementan servidores MCP — una de las categorías de proyectos vibe-coded de más rápido crecimiento — y probaron las recomendaciones de dependencias de herramientas de codificación con IA en PyPI, npm, Maven y NuGet. Los resultados:

El 80% de las dependencias sugeridas por IA contienen riesgos. Solo uno de cada cinco paquetes recomendados por herramientas de codificación con IA es realmente seguro — libre de vulnerabilidades conocidas, activamente mantenido, correctamente licenciado.

El 34% de las dependencias sugeridas son alucinaciones. No existen en ningún registro de paquetes. La IA se las inventó. Son nombres de paquetes que cualquiera podría registrar — y como veremos en el Caso 1, los atacantes ya lo han descubierto.

El 44–49% de las versiones de dependencias importadas por IA tienen vulnerabilidades conocidas. No son problemas oscuros o teóricos — son CVEs conocidos con exploits publicados. La IA no comprueba si una versión de un paquete está parcheada. Sugiere lo que aprendió de sus datos de entrenamiento, lo que frecuentemente significa fijar versiones obsoletas y vulnerables.

Un estudio académico independiente que analizó 117.062 cambios de dependencias encontró que los agentes de IA seleccionan versiones vulnerables a una tasa del 2,46% frente al 1,64% de los humanos — y cuando lo hacen, las selecciones vulnerables requieren actualizaciones de versión mayor el 36,8% de las veces (comparado con el 12,9% para elecciones humanas). En conjunto, el desarrollo dirigido por agentes produjo un aumento neto de 98 nuevas vulnerabilidades, mientras que los cambios de autoría humana produjeron una reducción neta de 1.316.

Ese es el marco. Ahora los casos.

Caso 1: Slopsquatting — Cuando las Alucinaciones de la IA se Convierten en Vectores de Ataque

El Descubrimiento

En abril de 2025, Seth Larson — Developer-in-Residence de la Python Software Foundation — acuñó un término para algo que los investigadores de seguridad venían observando con creciente alarma: slopsquatting. El concepto es simple. Las herramientas de codificación con IA alucinan nombres de paquetes que no existen. Los atacantes registran esos mismos nombres con payloads maliciosos. Cuando el siguiente desarrollador acepta la sugerencia de la IA sin verificar, instala el paquete del atacante.

Es el sucesor del typosquatting, perfectamente adaptado a la era de la IA. El typosquatting requería que los atacantes adivinaran qué paquetes los desarrolladores escribirían mal. El slopsquatting les da algo mejor: una lista predecible de nombres de paquetes que millones de desarrolladores recibirán como recomendación de su asistente de IA.

La Escala

La confirmación académica llegó en mayo de 2025, cuando los investigadores publicaron «We Have a Package for You!» en USENIX Security 2025. Probaron 16 LLMs diferentes en 756.000 muestras de generación de código y encontraron:

Tasa media de alucinación del 19,6%. Aproximadamente una de cada cinco recomendaciones de paquetes de herramientas de codificación con IA apunta a algo que no existe. Los modelos comerciales (GPT-4, Claude) obtuvieron mejores resultados con alrededor del 5% de alucinación. Los modelos de código abierto alcanzaron el 21% o más.

205.474 nombres de paquetes inexistentes únicos alucinados a través de todos los modelos y prompts. Eso son más de doscientos mil objetivos potenciales de slopsquatting.

El 43% de los nombres alucinados se repiten cuando haces preguntas similares. Pregunta «cómo parseo YAML en Python» diez veces, y el mismo nombre de paquete alucinado aparece el 58% de las veces. Esto significa que los atacantes no necesitan registrar nombres aleatorios — pueden predecir qué paquetes falsos recomendará la IA y registrar esos específicamente.

Los patrones de alucinación se dividen en tres categorías: el 38% son conflaciones — la IA fusiona dos nombres reales de paquetes (como «express-mongoose» combinando Express y Mongoose). El 13% son variantes tipográficas de paquetes reales. Y el 51% son fabricaciones puras — nombres que el modelo generó de la nada.

La Prueba de Concepto

Bar Lanyado de Lasso Security no esperó al paper académico. A principios de 2024, ejecutó el experimento. Pidió a herramientas de IA que generaran código Python para diversas tareas, anotó cada nombre de paquete alucinado, y registró uno: huggingface-cli. No malicioso — solo un paquete vacío con seguimiento analítico. En tres meses, había acumulado más de 30.000 descargas. De un solo nombre alucinado. En un solo registro.

Treinta mil instalaciones a ciegas de un paquete que nadie eligió deliberadamente. Nadie lo buscó en PyPI. Nadie leyó su descripción. Nadie revisó su código fuente. Escribieron lo que la IA les dijo que escribieran, pulsaron enter, y siguieron adelante.

Para un vibe coder — alguien que acepta sugerencias de la IA por defecto, que no lee las sentencias import, que trata pip install como un trámite entre prompts — esto es lo normal. La IA dice instálalo, lo instalas. Si Lanyado hubiera puesto un reverse shell en ese paquete en vez de analíticas, habría comprometido 30.000 máquinas de desarrollo.

Por Qué el Vibe Coding Amplifica Esto

Los desarrolladores tradicionales tienen una defensa contra el slopsquatting. Saben qué paquetes pretenden usar. Cuando escriben import requests, es porque eligieron deliberadamente la librería requests. Notarían si su código de repente importara requestz o python-requests-lib.

Los vibe coders no tienen esa defensa. Están aceptando bloques enteros de código generados por la IA. Las sentencias import se difuminan en la salida. Cuando Claude o Copilot escribe from azure_ml_utils import ModelClient, el vibe coder no se detiene a verificar si azure_ml_utils existe en PyPI. Suena legítimo. El código funciona localmente (quizás el import falla silenciosamente, o quizás ni siquiera se prueba). El nombre del paquete va a requirements.txt y se sube a producción.

Por eso el slopsquatting es un problema de seguridad de vibe coding, no solo un problema de IA. El vector de ataque requiere un desarrollador que instale paquetes sin verificación. El vibe coding crea exactamente ese desarrollador a escala.

Caso 2: Shai-Hulud — El Gusano que npm Nunca Esperó

Primer Contacto

El 14 de septiembre de 2025, un paquete legítimo y bien mantenido — @ctrl/tinycolor con más de 2 millones de descargas semanales — fue comprometido. Pero esto no era un típico secuestro de cuenta ni una publicación maliciosa puntual. Lo que los investigadores de seguridad de Unit 42 de Palo Alto descubrieron fue el primer gusano autopropagante en la historia de npm.

Lo llamaron Shai-Hulud, como los gusanos de arena de Dune. El nombre es apropiado: al igual que esos gusanos crecen consumiendo todo a su paso, este malware crecía consumiendo las cuentas npm de cada desarrollador que infectaba.

Cómo se Propagó

El mecanismo era elegante y aterrador. Una vez que Shai-Hulud comprometía la cuenta npm de un mantenedor — empezando por el mantenedor de @ctrl/tinycolor — no se limitaba a inyectar código malicioso en ese paquete. Recorría cada paquete que el mantenedor controlaba e inyectaba un script post-install en todos ellos. Cada paquete infectado, al ser instalado por otros desarrolladores:

  1. Recopilaba tokens de npm, tokens de GitHub, credenciales de AWS/GCP/Azure usando TruffleHog
  2. Buscaba workflows de GitHub Actions en los repositorios del desarrollador
  3. Inyectaba puertas traseras en esos workflows, dando al atacante acceso persistente
  4. Usaba los tokens de npm robados para publicar versiones infectadas de los propios paquetes del desarrollador

Los paquetes de cada nuevo mantenedor comprometido infectarían a sus consumidores descendentes, que comprometerían sus paquetes, que infectarían a sus consumidores. Crecimiento exponencial. Una reacción en cadena.

Para el 16 de septiembre — solo dos días después del primer contacto — más de 500 paquetes npm estaban infectados. El gusano había saltado de mantenedor en mantenedor, cada salto ampliando su alcance en órdenes de magnitud.

La Evolución

Esa ola inicial de 500 paquetes fue solo el comienzo. A principios de noviembre de 2025, Unit 42 informó de una segunda evolución — Shai-Hulud 2.0 — que había generado más de 25.000 repositorios maliciosos en aproximadamente 350 cuentas únicas de GitHub, impactando más de 10.000 repositorios. El gusano había aprendido. Diversificó sus métodos de propagación, usó payloads ofuscados y apuntó a tipos de credenciales que maximizarían el movimiento lateral.

CISA emitió una alerta en septiembre de 2025 advirtiendo de «compromiso generalizado de la cadena de suministro impactando el ecosistema npm». No es un lenguaje que CISA use a la ligera. No era un incidente localizado. Era contaminación a nivel de ecosistema.

La Conexión con Vibe Coding

¿Y quién se llevó la peor parte? Los desarrolladores más vulnerables a Shai-Hulud fueron los que:

  • Instalaban paquetes sin revisar changelogs ni diffs de versiones
  • Ejecutaban npm install sin auditar scripts post-install
  • No usaban lockfiles ni fijaban versiones exactas
  • Aceptaban actualizaciones de dependencias sugeridas por IA sin revisión

En otras palabras: vibe coders. Cuando tu asistente de IA sugiere actualizar @ctrl/tinycolor a la última versión, no te lo piensas dos veces. Es una librería de utilidades de color. ¿Qué puede salir mal? Aceptas la sugerencia, ejecutas el install, y el script post-install silenciosamente recopila tu token de npm. Ahora tus paquetes están comprometidos. Tus consumidores están comprometidos. El gusano crece.

Los datos de Endor Labs lo respaldan. Cuando las herramientas de IA sugieren versiones de dependencias, el 44–49% contienen vulnerabilidades conocidas. Pero el problema inverso es igualmente peligroso: cuando la IA sugiere la versión «latest», puede estar sugiriendo la versión comprometida. La IA no tiene forma de saber que la versión 4.2.1 de un paquete fue publicada por un gusano en lugar del mantenedor legítimo.

Lo que Esto Enseña

Shai-Hulud demuestra que los ataques a la cadena de suministro han evolucionado más allá del punto donde «no instales paquetes sospechosos» es un consejo adecuado. Los paquetes comprometidos eran legítimos. Tenían millones de descargas semanales. Tenían mantenedores reales y bases de código reales. El ataque no explotó malas prácticas de los consumidores de paquetes — explotó la infraestructura de confianza en sí misma.

Para los vibe coders, la lección es dura: incluso si solo instalas paquetes conocidos y populares, no estás a salvo. El paquete que instalaste ayer podría estar comprometido hoy. Sin fijación de versiones, verificación de lockfiles y auditoría de scripts post-install, estás a un npm install de participar en la cadena de propagación de un gusano.

Caso 3: s1ngularity — Cuando Tu Sistema de Compilación se Vuelve en Tu Contra

El Ataque

El 26 de agosto de 2025, desarrolladores en miles de proyectos recibieron una sorpresa desagradable. El sistema de compilación Nx — usado por grandes empresas y proyectos open-source para gestión de monorepos — había sido comprometido. No mediante un salto en la cadena de suministro ni un ataque de confusión de dependencias, sino mediante un exploit directo de su pipeline de CI/CD en GitHub Actions.

El atacante encontró una vulnerabilidad de inyección en el workflow pull_request_target — un trigger de GitHub Actions notoriamente peligroso que se ejecuta con privilegios elevados. Creando un título de pull request malicioso, el atacante obtuvo acceso a los tokens de publicación npm de Nx y publicó versiones comprometidas de paquetes core de Nx (versiones 20.9.0 a 21.8.0).

El ataque estuvo activo aproximadamente cuatro horas antes de que GitGuardian detectara la anomalía y npm revocara los tokens. Cuatro horas. En esa ventana:

  • 2.349 secretos distintos se filtraron de máquinas de desarrolladores
  • 1.346 repositorios fueron detectados con filtración de credenciales
  • Los secretos recopilados incluían tokens de GitHub, tokens de publicación npm, claves privadas SSH, claves API y credenciales de carteras de criptomonedas

El Payload Post-Install

Los paquetes maliciosos de Nx contenían un script post-install que se activaba inmediatamente con npm install. El payload:

  1. Escaneaba el sistema de archivos del desarrollador buscando archivos de credenciales (.npmrc, .ssh/, .env, archivos de credenciales AWS, configuración de GitHub CLI)
  2. Buscaba variables de entorno con tokens y claves API
  3. Exfiltraba todo a un repositorio público de GitHub usando la herramienta CLI gh (autenticándose con el propio token de GitHub del desarrollador)
  4. Apuntaba específicamente a credenciales de herramientas de IA — escaneando claves API de Claude y Gemini

Ese último punto es crítico. El atacante apuntó específicamente a credenciales de herramientas de codificación con IA. No es coincidencia. Los desarrolladores que usan herramientas de IA a menudo almacenan claves API localmente, y esas claves dan acceso a servicios de pago. Tokens de herramientas de IA comprometidos pueden usarse para generar contenido, ejecutar inferencia o acceder a recursos cloud asociados.

El Ángulo del Vibe Coding

Conecta esto con el vibe coding. Considera la configuración típica: estás construyendo un monorepo, tu asistente de IA sugiere usar Nx para la gestión del workspace. Aceptas. La IA genera un package.json con Nx como dependencia de desarrollo. Ejecutas npm install. El script post-install se ejecuta. Tus credenciales desaparecen.

En ningún momento de este flujo un vibe coder tiene razón para sospechar. Nx es una herramienta legítima y ampliamente usada. La recomendación de la IA era correcta. El paquete fue publicado en el registro oficial de npm bajo el scope oficial de Nx. No hubo alucinación, ni typosquat, ni señal de alarma obvia. El compromiso ocurrió upstream, y el flujo de trabajo del vibe coder — aceptar sugerencia de la IA, instalar, seguir prompting — proporcionó fricción cero para prevenirlo.

Pero el problema más profundo es lo que ocurre después de que las credenciales de un desarrollador son comprometidas. Si ese desarrollador es mantenedor de paquetes — y muchos desarrolladores activos lo son — el atacante ahora tiene acceso de publicación a sus paquetes. La misma cascada que alimentó a Shai-Hulud. Un sistema de compilación comprometido lleva a miles de máquinas de desarrolladores comprometidas, cada una potencialmente un punto de apoyo para publicar más ataques.

Lo que Conecta los Casos

El informe de amenazas de mediados de 2025 de Socket puso un número a la tendencia más amplia: 454.648 paquetes maliciosos fueron publicados en registros de paquetes solo en 2025. Más del 99% del malware open-source apuntó específicamente a npm. La campaña IndonesianFoods sola generó más de 100.000 paquetes en el Q4 de 2025 — uno cada siete segundos, casi con certeza automatizado con IA.

Esa es la otra cara de esta moneda. No es solo que las herramientas de IA sugieran malas dependencias. Es que los atacantes están usando IA para crear malas dependencias a escala. La cadena de suministro está siendo atacada desde ambas direcciones simultáneamente — la IA alucinando nombres de paquetes que los atacantes registran, y la IA generando paquetes maliciosos más rápido de lo que los humanos pueden revisar.

El Amplificador del Vibe Coding

Alejémonos de los casos individuales y el patrón se hace claro. Los ataques a la cadena de suministro existían antes del vibe coding. El malware npm existía antes de las herramientas de IA. Lo que hace el vibe coding es eliminar cada punto de control humano que podría haber detectado el ataque.

Flujo tradicional: El desarrollador quiere parsear fechas → busca en npm librerías de fechas → lee el README, comprueba descargas, mira el historial de mantenimiento → selecciona date-fns → lo añade al package.json → la revisión de código detecta si aparece algo inesperado.

Flujo de vibe coding: El desarrollador prompta «añade formateo de fechas a este componente» → la IA escribe código importando date-format-utils → el desarrollador acepta el bloque → se ejecuta npm install → hecho. Nadie preguntó qué es date-format-utils. Nadie comprobó si existe. Nadie verificó quién lo publica o cuándo se actualizó por última vez.

Las cinco decisiones humanas que constituían la defensa de la cadena de suministro — elegir un paquete, verificar su legitimidad, comprobar su estado de mantenimiento, revisar el import en revisión de código, monitorizar cambios inesperados — colapsan en una sola acción: aceptar la sugerencia de la IA.

Esto no es una preocupación teórica. Los números lo demuestran. Endor Labs encontró que los agentes de IA producen un aumento neto de 98 vulnerabilidades a través de sus elecciones de dependencias, mientras los humanos producen una disminución neta de 1.316. El proceso de curación humano — imperfecto como es — realmente reduce el riesgo de cadena de suministro. Elimínalo, y el riesgo se acumula sin control.

Defendiéndose de la Trampa de Dependencias

El problema es estructural, pero las soluciones son prácticas. Esto es lo que funciona:

Para Desarrolladores Individuales

Verifica antes de instalar. Cuando tu IA sugiera un paquete, dedica diez segundos a comprobar: ¿existe en el registro? ¿Quién lo mantiene? ¿Cuándo se actualizó por última vez? ¿Cuántas descargas tiene? Este simple paso derrota completamente al slopsquatting.

Usa lockfiles religiosamente. package-lock.json, yarn.lock, poetry.lock — estos fijan versiones exactas y hashes de integridad. Si una versión comprometida se publica, tu lockfile previene la adopción automática hasta que actualices explícitamente.

Audita scripts post-install. Ejecuta npm install --ignore-scripts primero, luego revisa qué scripts post-install existen antes de permitir su ejecución. Herramientas como Socket marcan paquetes con scripts de instalación sospechosos.

Fija tus dependencias. No uses rangos ^ o ~ en producción. Fija versiones exactas. Actualiza deliberadamente, no automáticamente.

Personalmente, siempre que realizo una revisión de seguridad en VULNEX, el package.json es una de las primeras cosas que abro. Paso cada dependencia por npmscan y la contrasto con la base de datos de vulnerabilidades de Snyk. Lleva cinco minutos y he perdido la cuenta de las veces que ha detectado paquetes que no tenían nada que hacer en una aplicación en producción — obsoletos, sin mantenimiento, o con CVEs críticos conocidos que el desarrollador nunca vio porque la IA eligió la dependencia, no él.

Para Equipos

Implementa una lista de dependencias permitidas. Aprueba paquetes y versiones específicos. Bloquea todo lo que no haya sido verificado. Esto añade fricción — ese es el punto.

Ejecuta SCA en CI/CD. Las herramientas de Software Composition Analysis (Snyk, Socket, Endor Labs) detectan vulnerabilidades conocidas y paquetes sospechosos antes de que lleguen a producción. Haz que la build falle si una dependencia no ha sido aprobada.

Monitoriza anomalías en la cadena de suministro. Vigila paquetes que cambian de mantenedor repentinamente, que añaden scripts post-install donde antes no existían, o que muestran patrones de publicación inusuales. Herramientas como la detección de anomalías de Socket las marcan automáticamente.

Trata las elecciones de dependencias generadas por IA igual que el código generado por IA: revísalas antes de aceptarlas.

Para el Ecosistema

La solución más amplia requiere cambios a nivel de registro — controles de publicación más estrictos, 2FA obligatorio, firma de paquetes y verificación de procedencia. npm ha avanzado en algunos de estos. Pero hasta que sean universales, la responsabilidad de defensa recae en los consumidores.

Lo que Deberías Llevarte de Esto

Si eres un fundador haciendo vibe-coding de tu MVP: tu asistente de IA acaba de añadir quince paquetes a tu package.json. ¿Cuántos de esos elegiste tú? ¿Cuántos siquiera miraste? Ejecuta npm audit ahora mismo. Comprueba si cada paquete en tu lockfile realmente existe en el registro y tiene un mantenedor activo. Uno de esos paquetes podría ser una alucinación que nadie ha registrado todavía — o que un atacante registró la semana pasada.

Si eres desarrollador: el slopsquatting significa que las recomendaciones de paquetes de la IA son una superficie de ataque, no una comodidad. Construye el hábito de verificar imports de la misma forma que verificas la lógica del código. Y revisa tus scripts post-install — npm install no es una operación segura solo porque el nombre del paquete suena familiar.

Si estás en seguridad: el modelo de amenazas de cadena de suministro tiene un nuevo punto de entrada. Las herramientas de codificación con IA están efectivamente tomando decisiones de dependencias en nombre de desarrolladores que carecen del contexto para verificarlas. Actualiza tus herramientas de SCA para marcar específicamente nombres de paquetes alucinados por IA. Incluye la revisión de selección de dependencias en tu proceso de revisión de código. Y si estás evaluando una aplicación vibe-coded, lo primero que debes auditar es su package.json — te garantizo que encontrarás paquetes que no deberían estar ahí.

La trampa de dependencias funciona porque explota la confianza en todos los niveles. Los desarrolladores confían en las recomendaciones de la IA. Los consumidores confían en paquetes populares. Los mantenedores confían en sus pipelines de CI/CD. Los atacantes han encontrado formas de explotar las tres relaciones de confianza simultáneamente. La única defensa es la verificación — y la verificación es exactamente lo que el flujo de «acepto y sigo» del vibe coding elimina.

En el siguiente artículo, cubriré otro patrón donde la IA falla consistentemente: la gestión de autenticación y secretos. Controles de autenticación del lado del cliente, claves API hardcodeadas y falta de RBAC — lo que convierte cada app vibe-coded en un objetivo.

Como siempre: no te fíes de nada, verifica todo.

Lecturas Adicionales

Referencias

Esta entrada fue publicada en AI, IA, Seguridad, Tecnologia y etiquetada , , , , . Guarda el enlace permanente.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.