Cadena de suministro de software bajo ataque: cómo GlassWorm comprometió 400+ herramientas de desarrollo

5 Min. de lectura

454.648 nuevos paquetes maliciosos en registros de código abierto solo en 2025. Un 75 por ciento más que el año anterior. Y en marzo de 2026, la campaña GlassWorm muestra cómo se han industrializado los ataques a la cadena de suministro de software: 433 componentes comprometidos en una semana, camuflados mediante caracteres Unicode invisibles y commits de cobertura generados por IA. Para las empresas que no supervisan sistemáticamente las dependencias de código abierto, el propio entorno de desarrollo se convierte en una puerta de entrada.

Lo más importante en resumen

454.648 nuevos paquetes maliciosos en registros de código abierto identificados en 2025, acumulando más de 1,2 millones de paquetes de malware conocidos (Sonatype, enero de 2026).
GlassWorm comprometió más de 433 componentes en marzo de 2026: 72 extensiones de VS Code, 88 paquetes npm, 151+ repositorios de GitHub (Aikido Security / BleepingComputer).
Crecimiento del 75 por ciento en malware de código abierto, con descargas que alcanzaron los 9.800 mil millones (Informe de Sonatype 2026).
El 65 por ciento de todas las CVEs de código abierto no han recibido una puntuación CVSS del NVD, lo que representa una gran laguna en la evaluación (Sonatype 2026).
NIS-2 exige explícitamente la gestión de riesgos de la cadena de suministro. El BSI ha definido la obligación de SBOM como base con TR-03183-2.

GlassWorm: Anatomía de un ataque industrializado

En marzo de 2026, investigadores de seguridad de Aikido Security descubrieron una de las campañas de cadena de suministro más sofisticadas hasta la fecha. La operación, denominada GlassWorm, comprometió en menos de dos semanas más de 433 componentes de software: 72 extensiones de Visual Studio Code en el Open VSX Marketplace, 88 paquetes npm y más de 151 repositorios de GitHub.

Lo que hizo que GlassWorm fuera especial no fue la cantidad, sino el método. Los atacantes utilizaron caracteres Unicode invisibles -llamados selectores de variación y códigos de área de uso privado- para ocultar código malicioso en el texto fuente. Para los revisores humanos, el código parecía limpio. Solo un análisis automatizado de las secuencias de bytes reveló las cargas útiles ocultas.

Además, se utilizaron «commits de cobertura» generados por IA: cambios de código aparentemente inofensivos que pretendían ocultar el código malicioso real en el historial de commits. La comunicación con los servidores de comando y control se realizó a través de la blockchain de Solana – con Google Calendar como canal de respaldo. Las herramientas clásicas de monitoreo de red no detectan estos canales de comunicación porque se ejecutan a través de servicios legítimos.

454.648

nuevos paquetes maliciosos en registros de código abierto (2025)

Fuente: Sonatype, State of the Software Supply Chain Report 2026

Los objetivos: robar credenciales para npm, GitHub y configuraciones de Git, vaciar carteras de criptomonedas e instalar backdoors persistentes en entornos de desarrollo. Quien instaló una extensión de VS Code comprometida dio a los atacantes acceso a su equipo de trabajo completo, incluidas todas las credenciales almacenadas allí.

La industrialización de la cadena de suministro de software como superficie de ataque

GlassWorm no es un caso aislado. Según el informe «State of the Software Supply Chain Report 2026» de Sonatype, solo en 2025 se identificaron más de 454.648 nuevos paquetes maliciosos en registros de código abierto como npm, PyPI y Maven Central. Esto representa un crecimiento del 75 por ciento con respecto al año anterior. Acumulativamente, ya se han documentado más de 1,2 millones de paquetes de malware conocidos.

Los métodos de ataque han cambiado fundamentalmente. Mientras que los ataques a la cadena de suministro hace unos años eran obra de actores individuales que aprovechaban errores tipográficos en nombres de paquetes (Typosquatting), hoy en día operan grupos respaldados por el Estado con medios industriales. El grupo Lazarus (Corea del Norte) utilizó en 2025 cadenas de carga útil de varias etapas, en las que un solo paquete manipulado cargaba una cascada de cinco componentes maliciosos adicionales.

El incidente de «Shai-Hulud» marca otro punto de inflexión: el primer gusano npm autorreplicante que creó más de 500 paquetes nuevos en el registro en pocos días. El 55,9 por ciento de todos los paquetes maliciosos documentados utilizan actualmente el abuso de repositorios como método de distribución principal: los registros se utilizan sistemáticamente como plataformas publicitarias.

Brian Fox, CTO de Sonatype, resume la situación: el código abierto es ya infraestructura de producción, los atacantes lo saben, y la IA acelera todo el sistema. La confianza debe mantenerse al ritmo de la velocidad de la máquina del software, lo que requiere medidas de protección automatizadas en el flujo de trabajo, no informes posteriores (Sonatype, State of the Software Supply Chain Report 2026).

Por qué fallan los conceptos de seguridad clásicos

Tres problemas estructurales hacen que la defensa contra los ataques a la cadena de suministro sea especialmente difícil:

La brecha en la evaluación de la NVD: El 65 por ciento de todos los CVEs de código abierto no tienen una puntuación CVSS de la Base de Datos Nacional de Vulnerabilidades, según Sonatype. Los escáneres de vulnerabilidades que se basan en datos de la NVD son, por lo tanto, sistemáticamente ciegos a una gran parte de las vulnerabilidades conocidas. Las empresas que se basan exclusivamente en análisis automatizados se sienten falsamente seguras.

Las estaciones de trabajo de los desarrolladores como punto ciego: Las extensiones de IDE no son supervisadas por la seguridad de TI en la mayoría de las empresas. La campaña GlassWorm se centró precisamente en este punto ciego: las extensiones de VS Code tienen amplios permisos en el sistema host, pero rara vez se tratan como instalaciones de software. Microsoft advirtió en marzo de 2026 sobre extensiones de asistentes de IA que roban historiales de chat de Copilot y otras herramientas LLM.

IA contra revisiones manuales: Cuando los atacantes utilizan confirmaciones de cobertura generadas por IA, las revisiones manuales de código ya no son suficientes. La velocidad a la que se crean y distribuyen nuevos paquetes maliciosos supera la capacidad de los analistas humanos. La detección automatizada basada en análisis de comportamiento en lugar de la simple comprobación de firmas se vuelve obligatoria.

65 %

de todos los CVEs de código abierto sin puntuación CVSS de la NVD

Fuente: Sonatype, State of the Software Supply Chain Report 2026

NIS-2 y la obligación de la cadena de suministro

Para las empresas en Alemania, la seguridad de la cadena de suministro de software ya no es opcional. NIS-2 exige en el artículo 21 medidas de seguridad explícitas para la cadena de suministro. El BSI ha definido con la directiva técnica TR-03183-2 la SBOM como instrumento obligatorio.

La consecuencia: las empresas deben documentar qué componentes de código abierto están incluidos en sus productos y herramientas internas. Deben tener procesos para reaccionar rápidamente cuando se descubran vulnerabilidades en estos componentes. Y deben realizar evaluaciones de riesgos para sus proveedores críticos, incluidos los proveedores de software.

El IBM X-Force Threat Intelligence Index 2026 confirma la urgencia: la explotación de aplicaciones públicamente accesibles aumentó un 44 por ciento, impulsada en gran medida por la falta de controles de autenticación y la detección de vulnerabilidades asistida por inteligencia artificial por parte de los atacantes.

Siete medidas contra ataques a la cadena de suministro

1. Implementar una lista blanca de extensiones. Las extensiones de IDE, las extensiones del navegador y las herramientas CLI solo deben instalarse desde listas aprobadas. VS-Code ofrece la configuración «extensions.allowed» en la política de la empresa.

2. Crear una SBOM para todos los productos y herramientas internas. CycloneDX o SPDX como formato, generado automáticamente en la canalización CI/CD. Sin una SBOM, no hay una visión general de las propias dependencias.

3. Activar el escaneo de dependencias en la canalización CI/CD. Herramientas como Snyk, Grype o Dependabot comprueban automáticamente en cada compilación si hay vulnerabilidades conocidas en los paquetes utilizados.

4. Utilizar la verificación de Sigstore para paquetes críticos. Sigstore permite la firma y verificación criptográfica de artefactos de software. Los paquetes manipulados sin una firma válida se bloquean automáticamente.

5. Zero Trust para el entorno de desarrollo. Las estaciones de trabajo de los desarrolladores necesitan el mismo nivel de seguridad que los servidores de producción: EDR, segmentación de red, control de acceso privilegiado. Los tiempos en que las máquinas de los desarrolladores tenían un papel especial han pasado.

6. Complementar los datos de NVD con inteligencia de amenazas comercial. Dada la brecha del 65 por ciento en las puntuaciones CVSS, los escáneres basados únicamente en NVD son insuficientes. Servicios como Sonatype, Snyk o Tidelift proporcionan datos más oportunos y completos.

7. Definir un plan de respuesta a incidentes para incidentes de la cadena de suministro. ¿Quién es responsable cuando se descubre una biblioteca comprometida? ¿Qué tan rápido se pueden identificar y parchear los sistemas afectados? Estos procesos deben estar en su lugar antes del incidente, no después.

Conclusión

Los ataques a la cadena de suministro de software están industrializados en 2026. La campaña GlassWorm muestra cómo los atacantes comprometen simultáneamente extensiones de IDE, paquetes npm y repositorios de GitHub, disfrazados con caracteres Unicode invisibles y confirmaciones generadas por inteligencia artificial. Para los responsables de la seguridad de TI, esto significa que su propio entorno de desarrollo ya no es de confianza, a menos que se asegure activamente. NIS-2 hace que la gestión de riesgos de la cadena de suministro sea obligatoria, y el BSI proporciona con la directiva SBOM el instrumento. Quien no actúe ahora será tomado por sorpresa en el próximo GlassWorm.

Preguntas frecuentes

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

Un ataque que no afecta directamente a la empresa objetivo, sino que compromete un componente de software que la empresa utiliza. Pueden ser bibliotecas de código abierto, extensiones de IDE, herramientas de compilación o paquetes de registros públicos como npm o PyPI. El código malicioso se distribuye automáticamente con la próxima actualización o instalación.

¿Cómo sé si mi empresa se ve afectada?

Sin SBOM y análisis de dependencias, la respuesta honesta es: probablemente no. El primer paso es hacer un inventario de todos los componentes de código abierto utilizados. Herramientas como Grype o Syft pueden crear SBOM de forma automatizada y compararlos con bases de datos de vulnerabilidades conocidas.

¿Protege un firewall de aplicaciones web contra ataques a la cadena de suministro?

No. Un WAF protege la aplicación de ataques externos a nivel de red. Los ataques a la cadena de suministro provienen del interior, a través de dependencias comprometidas que se consideran de confianza. Aquí ayudan el análisis de dependencias, la gestión de SBOM y la lista blanca de extensiones.

¿Qué exige concretamente NIS-2 para la cadena de suministro de software?

El artículo 21 de la directiva NIS-2 exige medidas para la seguridad de la cadena de suministro, incluidas las relaciones con proveedores y prestadores de servicios directos. El BSI lo concreta en la TR-03183-2 con la obligación de SBOM. Las empresas deben documentar qué componentes utilizan y demostrar procesos para una respuesta rápida en caso de vulnerabilidades.

¿Cuánto cuesta asegurar la cadena de suministro de software?

Para las PYME con una pipeline CI/CD existente, el esfuerzo es de 10.000 a 30.000 euros una vez (herramientas, introducción de SBOM, políticas de extensión) más costos corrientes para bases de datos de vulnerabilidades comerciales (2.000-10.000 euros/año). Sin una pipeline CI/CD, los costos aumentan a 40.000-80.000 euros, porque primero hay que construir la infraestructura.