El software moderno no se escribe, se ensambla. Una aplicación típica arrastra cientos de dependencias de terceros, y cada una es una puerta. Los atacantes lo saben, y la industria también: en su actualización de 2025, el propio OWASP elevó los fallos de la cadena de suministro de software al tercer puesto de su lista de riesgos más críticos, con la mitad de los expertos consultados votándolo como su principal preocupación.
Y esa preocupación se ha visto confirmada con creces. Solo en 2025 se identificaron más de 450.000 paquetes maliciosos nuevos, npm sufrió el primer gusano autopropagable de su historia, y grupos vinculados a estados comprometieron librerías con más de 100 millones de descargas semanales. En este artículo te explico las tres familias de ataque que dominan este terreno (typosquatting, confusión de dependencias y slopsquatting), de dónde viene la técnica, los casos reales más relevantes de los últimos años y cómo blindar tu pipeline. Porque el escáner de vulnerabilidades clásico, por sí solo, no te va a salvar de esto.
En esta guía
- Por qué la cadena de suministro es el objetivo perfecto
- El origen: de la investigación a la industrialización
- Las tres familias de ataque
- Anatomía técnica de un ataque de confusión de dependencias
- Casos reales de 2022 a 2026
- Por qué tu escáner no te salva
- Cómo blindar tu pipeline
- Qué significa para tu carrera en seguridad ofensiva
- Por dónde empezar
- Preguntas frecuentes
Por qué la cadena de suministro es el objetivo perfecto
Más del 85% de las empresas usa software de código abierto, y un proyecto cualquiera puede tirar de cientos de paquetes que, a su vez, tiran de otros. Esa confianza implícita es la grieta. Si un atacante logra colar código en una dependencia popular (o en una que se parezca lo suficiente), ese código se ejecuta en miles de máquinas durante una instalación rutinaria.
Y lo más incómodo: el paquete malicioso puede estar firmado con una clave válida, publicado por una cuenta legítima y distribuido por HTTPS. La verificación de firma tradicional no lo detecta, porque el problema no es que el paquete se manipule en tránsito, sino que la fuente misma es hostil, o que el propio proceso de publicación (una cuenta de mantenedor, una pipeline de CI/CD) ha sido secuestrado. Es exactamente el motivo por el que OWASP separó en 2025 los fallos de cadena de suministro (categoría A03) de los fallos de integridad de software y datos (categoría A08): uno es un problema de qué código entra en tu proyecto, el otro es un problema de si ese código se altera después de entrar.
El origen: de la investigación a la industrialización
La confusión de dependencias no nació como un ataque salvaje: nació como investigación de seguridad. En febrero de 2021, tras un proyecto de investigación de ocho meses, se publicó un informe que documentaba cómo era posible ejecutar código dentro de la infraestructura de más de 35 grandes empresas (entre ellas Apple, Microsoft, PayPal, Shopify, Netflix, Tesla, Uber y Yelp) simplemente publicando paquetes públicos con el mismo nombre que paquetes internos privados de esas compañías. La investigación recibió más de 130.000 dólares en recompensas de bug bounty por el hallazgo.
El mecanismo es simple una vez lo entiendes: muchos sistemas de build consultan varios índices de paquetes a la vez (uno privado, con las dependencias internas de la empresa, y el público, npm o PyPI). Si el atacante publica en el índice público un paquete con el mismo nombre y una versión más alta que la interna, el gestor de paquetes, siguiendo su lógica normal de "instala la versión más reciente", elige la versión maliciosa. Sin phishing, sin ingeniería social y sin explotar ninguna vulnerabilidad de código: solo un nombre adivinado y un número de versión.
El hallazgo desató una oleada de investigación sobre el tema y llevó a npm y a otros gestores de paquetes a introducir mecanismos de mitigación, como los paquetes con espacio de nombres (o "scope") mapeados de forma explícita a un registro concreto. Pero la teoría tardó menos de dos años en convertirse en un ataque real fuera del laboratorio, como vas a ver en la sección de casos reales.
Las tres familias de ataque
Sobre esa base técnica se han construido tres variantes que, aunque comparten objetivo (que instales algo que no querías instalar), explotan puntos de fallo distintos: la vista de un humano, la configuración de un gestor de paquetes, o el propio modelo de lenguaje que te sugiere qué instalar.
1. Typosquatting (ocupación por errata)
El atacante publica paquetes con nombres a un carácter de distancia de los populares, apostando a la prisa y a los dedos torpes. Se han visto variantes de requests, boto3 o numpy con erratas mínimas. El patrón del payload es consistente: un script que se ejecuta en el momento de la instalación (un hook postinstall en npm, o código a nivel de módulo que se dispara al hacer import en Python), que exfiltra variables de entorno y claves SSH, y a veces deja un mecanismo de persistencia.
El typosquatting clásico depende de un error humano, pero su variante cada vez más común (el secuestro de una cuenta de mantenedor legítima mediante phishing) ni siquiera necesita eso. En 2025, una campaña de phishing que suplantaba a npm y pedía "actualizar" la configuración de doble factor fue, según los investigadores que documentaron el caso, el punto de entrada probable de varios de los ataques más graves del año: el nombre del paquete no cambia, pero quien lo publica ya no es quien crees.
2. Confusión de dependencias (dependency confusion)
Ya has visto de dónde viene esta técnica. En la práctica, sigue siendo relevante porque muchas empresas tienen paquetes internos (por ejemplo miempresa-utils) sin reservar el nombre equivalente en el registro público. Si un atacante publica ese mismo nombre en npm o PyPI con una versión más alta, el gestor de paquetes mal configurado puede preferir el público. En 2026 los ataques dirigidos rastrean ofertas de empleo, repositorios de GitHub, mensajes de error en issues públicos y metadatos de capas de Docker para descubrir esos nombres internos antes de registrarlos ellos mismos.
3. Slopsquatting (paquetes alucinados)
La variante de la era de la IA. Los asistentes de código generativo alucinan (inventan) nombres de paquetes que no existen, con una frecuencia mayor de lo que cabría esperar: un estudio académico presentado en USENIX Security 2025, que analizó 576.000 muestras de código generadas por 16 modelos distintos, encontró que el 19,7% de los paquetes recomendados no existían. Los modelos de código abierto alucinaban más (21,7% de media) que los modelos comerciales cerrados (5,2%), y en conjunto se identificaron más de 205.000 nombres de paquetes alucinados distintos.
Lo que convierte esto en un vector de ataque, y no solo en un fallo gracioso, es que las alucinaciones se repiten: más de la mitad de los nombres inventados reaparecían en ejecuciones distintas del mismo modelo. El término se acuñó en abril de 2025 desde la Python Software Foundation y se popularizó rápidamente en la comunidad de seguridad. Ya había un precedente que demostraba el problema en la práctica: en 2023 se observó que varios modelos recomendaban de forma insistente un paquete de Python llamado huggingface-cli, que no existe (el comando real se instala como parte de huggingface_hub[cli]). Como prueba, se publicó un paquete vacío con ese nombre solo para medir el interés real, y en tres meses acumuló más de 30.000 descargas.
El typosquatting ya no busca solo confundir al humano: ahora también busca confundir al modelo, y el modelo, a diferencia de un desarrollador con prisa, no tiene ningún instinto de sospecha ante un nombre que "suena bien".
# Las tres formas de que acabes instalando codigo malicioso Typosquatting requets (en vez de "requests": una errata) Confusion de dep. miempresa-utils (tu paquete interno, clonado en el repo publico) Slopsquatting auto-fetch-lib (un nombre que la IA se invento y un atacante registro)
| Vector | A quién engaña | Qué explota | Defensa principal |
|---|---|---|---|
| Typosquatting | Al desarrollador (errata) o a su cuenta (phishing) | Errores de escritura o credenciales de mantenedor robadas | MFA con clave física o TOTP, revisión de nombres |
| Confusión de dependencias | Al gestor de paquetes | La lógica de "gana la versión más alta" al resolver un nombre en varios índices | Reservar el namespace público, un único índice con prioridades explícitas |
| Slopsquatting | Al modelo de IA (y, a través de él, al desarrollador) | La tasa de alucinación de nombres de paquete en los LLM | Verificar cada paquete sugerido antes de instalarlo |
Anatomía técnica de un ataque de confusión de dependencias
Para entender por qué esta familia de ataques funciona, ayuda ver la secuencia completa, tal y como se describió en la investigación original y como se repitió después en el mundo real:
- La empresa tiene un paquete interno, por ejemplo
@miempresa/auth-utils, alojado en un registro privado (Artifactory, Nexus, un feed de Azure DevOps). - El pipeline de build está configurado para consultar tanto el registro privado como el público, a veces sin que nadie lo haya decidido de forma explícita: viene así por defecto o por comodidad.
- El atacante averigua el nombre exacto del paquete interno (un
package.jsonfiltrado en GitHub, una oferta de empleo que menciona la librería, un error de Docker, o simplemente probando nombres comunes) y publica un paquete público con ese mismo nombre y una versión superior. - La próxima vez que alguien ejecuta
npm installopip install, el gestor de paquetes resuelve el nombre consultando ambos índices y se queda con la versión más alta: la del atacante. - El código del atacante se ejecuta con los mismos privilegios que el proceso de build, típicamente dentro de un pipeline de CI/CD con acceso a secretos, tokens y credenciales de despliegue.
# Configuracion insegura en pip: consulta ambos indices sin distinguir el origen $ pip install libreria-interna --extra-index-url https://pypi.org/simple/ ← pip trata ambos indices por igual y puede preferir el publico # Configuracion segura en npm: el scope de la organizacion se sirve SIEMPRE # desde el registro privado, nunca desde el publico (fichero .npmrc) @miempresa:registry=https://npm.miempresa.internal/ //npm.miempresa.internal/:_authToken=${NPM_TOKEN} ← cualquier paquete bajo @miempresa/* solo puede venir de ese registro
--extra-index-url de pip es, tal y como está diseñado, inherentemente inseguro: hace exactamente lo que promete (buscar en más de un índice), pero no en el orden en que la mayoría de desarrolladores asume.Casos reales de 2022 a 2026
El origen académico de la técnica no le ha quitado nada de peligro real. Estos son los casos que marcan su evolución desde el primer compromiso documentado hasta hoy.
torchtriton (diciembre de 2022): el salto del laboratorio al mundo real
Entre el 25 y el 30 de diciembre de 2022, alguien publicó en PyPI un paquete llamado torchtriton: el mismo nombre que una dependencia que PyTorch distribuía únicamente desde su propio índice de compilaciones nightly. Como PyPI tiene precedencia en la resolución de pip, cualquiera que instalara PyTorch nightly en Linux durante esos días recibía la versión maliciosa en lugar de la legítima.
El paquete falso exfiltraba variables de entorno, el nombre de host, claves SSH y el contenido de los primeros archivos del directorio personal, todo vía DNS hacia un dominio registrado pocos días antes del ataque. Se descargó varios miles de veces antes de ser retirado. La persona detrás del paquete afirmó después que se trataba de una investigación de seguridad que se le fue de las manos, pero el equipo de PyTorch lo trató como lo que fue: un compromiso real. Renombraron la dependencia legítima a pytorch-triton y registraron un paquete señuelo en PyPI para que el mismo nombre no pudiera volver a secuestrarse.
Shai-Hulud (septiembre y noviembre de 2025): el primer gusano autopropagable de npm
El 15 de septiembre de 2025, investigadores detectaron el primer gusano autopropagable de la historia de npm. Se cree que el punto de entrada fue una campaña de phishing que suplantaba a npm y pedía a los mantenedores "actualizar" su configuración de doble factor; quien mordió el anzuelo entregó sus credenciales. El paquete rxnt-authentication, publicado el 14 de septiembre desde la cuenta techsupportrxnt (el "paciente cero" de la campaña), fue el punto de partida.
A partir de ahí, el malware (bautizado Shai-Hulud, en referencia a los gusanos de arena de Dune) hizo algo que ningún ataque anterior a gran escala en npm había hecho: propagarse solo. Cuando se instalaba un paquete infectado, el script robaba tokens de npm y GitHub, credenciales de AWS y GCP, y usaba TruffleHog para rastrear secretos adicionales en el sistema. Con el token de npm robado, el malware se autenticaba como el mantenedor legítimo, inyectaba su propio código en cualquier otro paquete que esa persona pudiera publicar, y republicaba versiones troyanizadas sin intervención humana. También creaba un repositorio público en GitHub llamado "Shai-Hulud" con los secretos robados codificados en Base64.
La primera oleada afectó a más de 500 paquetes, entre ellos @ctrl/tinycolor (más de dos millones de descargas semanales) y varios paquetes propiedad de CrowdStrike. Dos meses después, el 24 de noviembre de 2025, apareció una variante mucho más agresiva conocida como Shai-Hulud 2.0: ejecutaba su carga durante la fase de preinstalación (antes de que termine la instalación, ampliando la ventana de impacto), añadía un mecanismo destructivo que podía borrar el directorio personal del usuario si no conseguía robar credenciales, y llegó a generar más de 25.000 repositorios maliciosos en GitHub repartidos entre unos 350 usuarios distintos.
axios (marzo de 2026): cuando un grupo estatal ataca tu cliente HTTP
El 31 de marzo de 2026, entre las 00:21 y las 03:20 UTC, un atacante publicó dos versiones troyanizadas de axios (la librería HTTP más usada de JavaScript, con más de 100 millones de descargas semanales y presente en alrededor del 80% de los entornos cloud) tras comprometer la cuenta npm de su mantenedor principal. Las versiones maliciosas añadían una dependencia inventada, plain-crypto-js, cuyo único propósito era ejecutar un script de posinstalación que desplegaba un troyano de acceso remoto multiplataforma (Windows, macOS y Linux).
Google Threat Intelligence Group y Microsoft atribuyeron el ataque, de forma independiente, a un grupo norcoreano vinculado al estado (rastreado como UNC1069 por Google y como Sapphire Sleet por Microsoft), con antecedentes en el robo de criptomonedas. Las versiones maliciosas estuvieron disponibles poco más de tres horas antes de ser retiradas, tiempo suficiente para que, según estimaciones de Wiz, alrededor del 3% de la base de usuarios de axios las descargara. El caso es un buen recordatorio de que ni siquiera las protecciones modernas son infalibles por sí solas: el proyecto usaba OIDC (Trusted Publishing) para sus publicaciones automáticas, pero el workflow de GitHub Actions seguía exponiendo, como alternativa, un token clásico de npm de larga duración; el atacante usó ese token robado para publicar manualmente, saltándose el flujo seguro por completo.
TanStack, Mistral AI y UiPath (mayo de 2026): la campaña que cruzó de npm a PyPI en horas
El 11 de mayo de 2026, un grupo rastreado como TeamPCP (también conocido como UNC6780) comprometió la pipeline de GitHub Actions de TanStack mediante una cadena de vulnerabilidades: forkeó el repositorio, abrió una pull request que disparaba un workflow de tipo pull_request_target, y envenenó la caché de pnpm que ese workflow restauraba. Cuando un mantenedor legítimo fusionó cambios más adelante, la caché envenenada se restauró y el código del atacante extrajo tokens OIDC directamente de la memoria del proceso del runner de GitHub Actions.
Con esos tokens, el atacante publicó cientos de versiones maliciosas repartidas en más de 150 nombres de paquete npm (dentro de la organización @tanstack, más paquetes de UiPath, del SDK de Mistral AI, de OpenSearch y de otros proyectos) y, horas más tarde, el ataque saltó a PyPI con versiones maliciosas de mistralai y guardrails-ai. Fue una de las primeras campañas en cruzar de npm a PyPI dentro del mismo incidente. Lo más incómodo del caso: como los paquetes se publicaron desde dentro de un runner legítimo de GitHub Actions usando tokens OIDC válidos, llevaban atestaciones de procedencia (provenance) técnicamente correctas. La procedencia por sí sola no es una garantía de seguridad si lo que está comprometido es la propia pipeline que la genera.
El panorama en cifras
Estos casos no son anomalías puntuales: son la punta visible de una tendencia que los datos agregados confirman. Según el informe State of the Software Supply Chain 2026 de Sonatype, solo en 2025 se identificaron más de 454.000 paquetes maliciosos nuevos, lo que eleva el total acumulado bloqueado a más de 1,233 millones de paquetes en npm, PyPI, Maven Central, NuGet y Hugging Face: un salto del 75% respecto al año anterior. Más del 99% de ese malware de código abierto se concentró en npm, y los gusanos autopropagables por sí solos añadieron más de 171.000 paquetes maliciosos al registro en cuestión de meses.
Y eso sin contar otras campañas del mismo periodo: TrapDoor distribuyó 34 paquetes maliciosos combinando npm, PyPI y Crates.io contra desarrolladores de criptomonedas, DeFi y Solana; en junio de 2026 se comprometieron 32 paquetes del scope @redhat-cloud-services en npm; y la campaña conocida como Hades afectó a paquetes de bioinformática en PyPI con una carga multietapa diseñada, entre otras cosas, para intentar engañar a los sistemas de triaje basados en IA que analizan el paquete de forma automática.
Por qué tu escáner no te salva
Las herramientas de análisis de composición de software (SCA) prometían resolver esto, pero la mayoría son, en el fondo, comparadores de CVE: miran tu lista de dependencias y la cruzan con la base de vulnerabilidades conocidas. Un paquete malicioso de cinco días de antigüedad no tiene ningún CVE asociado, así que pasa el filtro sin problemas.
Los números lo confirman. Cuando OWASP promovió los fallos de cadena de suministro a la categoría A03 de su Top 10 de 2025, tuvo que hacerlo casi a contracorriente de sus propios datos: es la categoría con menos debilidades (CWE) mapeadas de toda la lista, y apenas 11 CVE asociados, y aun así fue la que tuvo el impacto medio más alto de las diez y la que la mitad de los expertos consultados votó como su principal preocupación. Dicho de otro modo: el propio marco de referencia de la industria admite que este es el riesgo que peor detectan las herramientas tradicionales, y el que más duele cuando llega.
A eso se suma la lentitud del sistema de puntuación oficial: según el mismo informe de Sonatype citado antes, la mediana de tiempo que tarda el NVD en puntuar un CVE de código abierto es de 41 días, mientras que un paquete malicioso listo para usar puede aparecer en horas. Contra estos ataques, comparar contra CVE conocidos sirve de poco.
Cómo blindar tu pipeline
Lo que de verdad funciona combina control en el punto de entrada, verificación de procedencia y análisis de comportamiento. Ninguna medida por sí sola es suficiente:
- Usa instalaciones reproducibles:
npm cien vez denpm install, y ficheros de bloqueo (lockfiles) con versiones fijadas, para instalar exactamente lo verificado y fallar ante cualquier discrepancia. - Posee tu espacio de nombres: registra tus nombres de paquetes internos en el repositorio público como reserva, para que nadie pueda suplantarlos. Es la defensa directa contra la confusión de dependencias.
- Fuerza un único índice y prioridades de resolución explícitas, para que el gestor no elija el paquete público por tener una versión más alta.
- Análisis de comportamiento en la instalación: vigila qué hace un paquete al instalarse (conexiones de red salientes, lectura de claves) y pon en cuarentena los paquetes nuevos durante un periodo de enfriamiento.
- Verifica lo que sugiere la IA antes de instalarlo: que el paquete exista, que sea el oficial y que no se registrara ayer.
| Medida | Frente a qué ataque | Cómo se aplica |
|---|---|---|
| Instalaciones reproducibles | Versiones inesperadas (confusión de dependencias, cuenta comprometida) | npm ci, lockfile con versión e integridad fijadas, fallo explícito ante discrepancias |
| Reservar el namespace público | Confusión de dependencias | Registrar cada paquete interno en npm/PyPI, y usar scopes (@miempresa/*) mapeados por .npmrc a un único registro |
| Cuarentena de paquetes nuevos | Typosquatting, slopsquatting, gusanos como Shai-Hulud | Bloquear la instalación de versiones publicadas en las últimas 24-72 horas hasta que pasen un periodo de observación |
| Desactivar scripts de instalación por defecto | Payloads en postinstall/preinstall | npm config set ignore-scripts true, revisando de forma explícita qué paquetes sí necesitan ejecutar código |
| MFA con clave física o TOTP para mantenedores | Secuestro de cuentas vía phishing (el origen de Shai-Hulud y de varios casos de 2026) | Exigirlo en npm, PyPI y GitHub; nunca solo verificación por email |
| Procedencia con matices (SLSA/Sigstore) | Publicaciones no autorizadas | Exigir atestaciones de procedencia, pero auditando también la propia pipeline que las genera |
Qué significa para tu carrera en seguridad ofensiva
La cadena de suministro es uno de los vectores con más recorrido y peor cubiertos, y los datos lo confirman: es la categoría que la industria vota como su mayor preocupación, pero en la que menos se puede confiar en la automatización por sí sola. Entender cómo un atacante razona sobre los nombres internos de una empresa, cómo se ejecuta código en una instalación, cómo se secuestra una cuenta de mantenedor o cómo se envenena una caché de CI/CD es una habilidad muy demandada, y conecta directamente con el slopsquatting que ya cubrimos en el post de código generado por IA.
Es, en el fondo, pensar en flujos de confianza: de dónde viene cada pieza de software, quién tiene permiso para publicarla y qué pasa cuando se ejecuta. Si entrenas ese razonamiento con el curso Web eXploitation Expert (WXE), tienes la base para auditar también la cadena de suministro de una aplicación.
¿Quieres aprender a pensar como un atacante también en la cadena de suministro?
En SixHack Academy entrenamos el razonamiento sobre fronteras de confianza y ejecución de código que está detrás de estos ataques. El curso Web eXploitation Expert (WXE) te da esa base.
Por dónde empezar
- Audita qué namespaces internos usa tu organización y comprueba si sus nombres equivalentes están libres en npm y PyPI. Si lo están, ese es tu primer riesgo real de confusión de dependencias.
- Revisa la configuración de resolución de paquetes de tu proyecto (
.npmrc,pip.conf, la configuración de tu gestor de dependencias) y confirma que no mezcla, de forma implícita, un índice privado con el público. - Sustituye
npm installpornpm ci(o el equivalente en tu gestor) en todos los pipelines de CI/CD. - Comprueba si tu organización exige MFA con clave física o TOTP a todos los mantenedores con permiso de publicación, no solo verificación por email.
- La próxima vez que un asistente de IA te sugiera instalar un paquete que no reconoces, búscalo antes de instalarlo. Es el gesto más simple contra el slopsquatting.
Preguntas frecuentes
¿Qué diferencia hay entre typosquatting y confusión de dependencias?
El typosquatting apuesta a que alguien escriba mal el nombre de un paquete popular, o directamente secuestra la cuenta de un mantenedor legítimo. La confusión de dependencias suplanta el nombre de un paquete interno privado en el repositorio público, esperando que el gestor de paquetes prefiera el público por tener una versión más alta.
¿Qué es el slopsquatting?
Es registrar con código malicioso los nombres de paquetes que los asistentes de IA inventan (alucinan). El término se acuñó en abril de 2025 desde la Python Software Foundation, y un estudio de USENIX Security 2025 encontró que casi 1 de cada 5 paquetes recomendados por 16 modelos distintos no existía.
¿No me protege mi escáner de seguridad?
Casi nunca contra esto. La mayoría de escáneres comparan contra CVE conocidos, y un paquete malicioso recién publicado no tiene CVE (la propia categoría de OWASP que cubre estos fallos apenas tiene 11 CVE mapeados). Necesitas análisis de comportamiento en la instalación y control en el punto de entrada.
¿Cuál es la defensa más simple y eficaz?
Registrar tus nombres de paquetes internos en el repositorio público (para que nadie los suplante), usar instalaciones reproducibles con ficheros de bloqueo, exigir MFA con clave física o TOTP a los mantenedores y poner en cuarentena los paquetes nuevos antes de confiar en ellos.
¿Qué fue Shai-Hulud y por qué cambió las reglas del juego?
Fue el primer gusano autopropagable descubierto en npm, en septiembre de 2025. A diferencia de un ataque manual, una vez robaba las credenciales de un mantenedor se publicaba solo en cualquier otro paquete al que esa persona tuviera acceso, sin que el atacante tuviera que intervenir. Afectó a más de 500 paquetes en su primera oleada y generó, dos meses después, una variante más agresiva y destructiva.
¿Estos ataques solo afectan a npm y PyPI?
No, aunque son los ecosistemas donde se concentra la mayoría de los casos documentados (npm por volumen, PyPI por precisión de los payloads). Ya se han visto campañas que cruzan a Crates.io, NuGet y Packagist, y los informes de la industria de 2026 rastrean también malware en Maven Central y Hugging Face.
¿Puede la IA empeorar este problema, más allá del slopsquatting?
Sí, en un segundo frente menos evidente: cuando una IA elige o actualiza dependencias sin verificación en tiempo real, puede recomendar versiones que no existen o paquetes ya identificados como maliciosos. Un informe de la industria de 2026 encontró que, sin ese contexto verificado, un modelo de última generación alucinaba alrededor del 28% de las versiones de componentes al recomendar actualizaciones de dependencias.
Referencias
- OWASP Top 10:2025, A03: Software Supply Chain Failures: la categoría que en 2025 elevó los fallos de cadena de suministro al tercer puesto de los riesgos más críticos.
- Publicación original de 2021 sobre la técnica de confusión de dependencias.
- PyTorch: aviso oficial sobre el compromiso de torchtriton (2022).
- Wiz: análisis del gusano Shai-Hulud (2025).
- Google Threat Intelligence Group: atribución del ataque a axios (2026).
- SafeDep: análisis de la campaña TanStack / Mistral AI / UiPath (2026).
- Sonatype, State of the Software Supply Chain 2026: Open Source Malware.
- Wikipedia: "Slopsquatting", origen del término y resumen del estudio de USENIX Security 2025.
- npm: npm ci: instalaciones reproducibles desde el fichero de bloqueo.
- GitGuardian: análisis de typosquatting y confusión de dependencias.