5 Min. de lectura<\/p>\n
454.648 nuevos paquetes maliciosos en registros de c\u00f3digo abierto solo en 2025. Un 75 por ciento m\u00e1s que el a\u00f1o anterior. Y en marzo de 2026, la campa\u00f1a GlassWorm muestra c\u00f3mo 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\u00e1ticamente las dependencias de c\u00f3digo abierto, el propio entorno de desarrollo se convierte en una puerta de entrada.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n En marzo de 2026, investigadores de seguridad de Aikido Security<\/a> descubrieron una de las campa\u00f1as de cadena de suministro m\u00e1s sofisticadas hasta la fecha. La operaci\u00f3n, denominada GlassWorm, comprometi\u00f3 en menos de dos semanas m\u00e1s de 433 componentes de software: 72 extensiones de Visual Studio Code en el Open VSX Marketplace, 88 paquetes npm y m\u00e1s de 151 repositorios de GitHub.<\/p>\n Lo que hizo que GlassWorm fuera especial no fue la cantidad, sino el m\u00e9todo. Los atacantes utilizaron caracteres Unicode invisibles -llamados selectores de variaci\u00f3n y c\u00f3digos de \u00e1rea de uso privado- para ocultar c\u00f3digo malicioso en el texto fuente. Para los revisores humanos, el c\u00f3digo parec\u00eda limpio. Solo un an\u00e1lisis automatizado de las secuencias de bytes revel\u00f3 las cargas \u00fatiles ocultas.<\/p>\n Adem\u00e1s, se utilizaron \u00abcommits de cobertura\u00bb generados por IA: cambios de c\u00f3digo aparentemente inofensivos que pretend\u00edan ocultar el c\u00f3digo malicioso real en el historial de commits. La comunicaci\u00f3n con los servidores de comando y control se realiz\u00f3 a trav\u00e9s de la blockchain de Solana<\/a> – con Google Calendar como canal de respaldo. Las herramientas cl\u00e1sicas de monitoreo de red no detectan estos canales de comunicaci\u00f3n porque se ejecutan a trav\u00e9s de servicios leg\u00edtimos.<\/p>\n 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\u00f3 una extensi\u00f3n de VS Code comprometida dio a los atacantes acceso a su equipo de trabajo completo, incluidas todas las credenciales almacenadas all\u00ed.<\/p>\n GlassWorm no es un caso aislado. Seg\u00fan el informe \u00abState of the Software Supply Chain Report 2026\u00bb de Sonatype<\/a>, solo en 2025 se identificaron m\u00e1s de 454.648 nuevos paquetes maliciosos en registros de c\u00f3digo abierto como npm, PyPI y Maven Central. Esto representa un crecimiento del 75 por ciento con respecto al a\u00f1o anterior. Acumulativamente, ya se han documentado m\u00e1s de 1,2 millones de paquetes de malware conocidos.<\/p>\n Los m\u00e9todos de ataque han cambiado fundamentalmente. Mientras que los ataques a la cadena de suministro hace unos a\u00f1os eran obra de actores individuales que aprovechaban errores tipogr\u00e1ficos en nombres de paquetes (Typosquatting), hoy en d\u00eda operan grupos respaldados por el Estado con medios industriales. El grupo Lazarus (Corea del Norte) utiliz\u00f3 en 2025 cadenas de carga \u00fatil de varias etapas, en las que un solo paquete manipulado cargaba una cascada de cinco componentes maliciosos adicionales.<\/p>\n El incidente de \u00abShai-Hulud\u00bb marca otro punto de inflexi\u00f3n: el primer gusano npm autorreplicante que cre\u00f3 m\u00e1s de 500 paquetes nuevos en el registro en pocos d\u00edas. El 55,9 por ciento de todos los paquetes maliciosos documentados utilizan actualmente el abuso de repositorios como m\u00e9todo de distribuci\u00f3n principal: los registros se utilizan sistem\u00e1ticamente como plataformas publicitarias.<\/p>\n Brian Fox, CTO de Sonatype, resume la situaci\u00f3n: el c\u00f3digo abierto es ya infraestructura de producci\u00f3n, los atacantes lo saben, y la IA acelera todo el sistema. La confianza debe mantenerse al ritmo de la velocidad de la m\u00e1quina del software, lo que requiere medidas de protecci\u00f3n automatizadas en el flujo de trabajo, no informes posteriores (Sonatype, State of the Software Supply Chain Report 2026).<\/p>\n Tres problemas estructurales hacen que la defensa contra los ataques a la cadena de suministro sea especialmente dif\u00edcil:<\/p>\n La brecha en la evaluaci\u00f3n de la NVD:<\/strong> El 65 por ciento de todos los CVEs de c\u00f3digo abierto no tienen una puntuaci\u00f3n CVSS de la Base de Datos Nacional de Vulnerabilidades, seg\u00fan Sonatype. Los esc\u00e1neres de vulnerabilidades que se basan en datos de la NVD son, por lo tanto, sistem\u00e1ticamente ciegos a una gran parte de las vulnerabilidades conocidas. Las empresas que se basan exclusivamente en an\u00e1lisis automatizados se sienten falsamente seguras.<\/p>\n Las estaciones de trabajo de los desarrolladores como punto ciego:<\/strong> Las extensiones de IDE no son supervisadas por la seguridad de TI en la mayor\u00eda de las empresas. La campa\u00f1a GlassWorm se centr\u00f3 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\u00f3 en marzo de 2026 sobre extensiones de asistentes de IA que roban historiales de chat de Copilot y otras herramientas LLM.<\/p>\n IA contra revisiones manuales:<\/strong> Cuando los atacantes utilizan confirmaciones de cobertura generadas por IA, las revisiones manuales de c\u00f3digo 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\u00f3n automatizada basada en an\u00e1lisis de comportamiento en lugar de la simple comprobaci\u00f3n de firmas se vuelve obligatoria.<\/p>\n Para las empresas en Alemania, la seguridad de la cadena de suministro de software ya no es opcional. NIS-2 exige en el art\u00edculo 21 medidas de seguridad expl\u00edcitas para la cadena de suministro. El BSI ha definido con la directiva t\u00e9cnica TR-03183-2 la SBOM como instrumento obligatorio<\/a>.<\/p>\n La consecuencia: las empresas deben documentar qu\u00e9 componentes de c\u00f3digo abierto est\u00e1n incluidos en sus productos y herramientas internas. Deben tener procesos para reaccionar r\u00e1pidamente cuando se descubran vulnerabilidades en estos componentes. Y deben realizar evaluaciones de riesgos para sus proveedores cr\u00edticos, incluidos los proveedores de software.<\/p>\n El IBM X-Force Threat Intelligence Index 2026<\/a> confirma la urgencia: la explotaci\u00f3n de aplicaciones p\u00fablicamente accesibles aument\u00f3 un 44 por ciento, impulsada en gran medida por la falta de controles de autenticaci\u00f3n y la detecci\u00f3n de vulnerabilidades asistida por inteligencia artificial por parte de los atacantes.<\/p>\n 1. Implementar una lista blanca de extensiones.<\/strong> Las extensiones de IDE, las extensiones del navegador y las herramientas CLI solo deben instalarse desde listas aprobadas. VS-Code ofrece la configuraci\u00f3n \u00abextensions.allowed\u00bb en la pol\u00edtica de la empresa.<\/p>\n 2. Crear una SBOM para todos los productos y herramientas internas.<\/strong> CycloneDX<\/a> o SPDX como formato, generado autom\u00e1ticamente en la canalizaci\u00f3n CI\/CD. Sin una SBOM, no hay una visi\u00f3n general de las propias dependencias.<\/p>\n 3. Activar el escaneo de dependencias en la canalizaci\u00f3n CI\/CD.<\/strong> Herramientas como Snyk<\/a>, Grype o Dependabot comprueban autom\u00e1ticamente en cada compilaci\u00f3n si hay vulnerabilidades conocidas en los paquetes utilizados.<\/p>\n 4. Utilizar la verificaci\u00f3n de Sigstore para paquetes cr\u00edticos.<\/strong> Sigstore permite la firma y verificaci\u00f3n criptogr\u00e1fica de artefactos de software. Los paquetes manipulados sin una firma v\u00e1lida se bloquean autom\u00e1ticamente.<\/p>\n 5. Zero Trust para el entorno de desarrollo.<\/strong> Las estaciones de trabajo de los desarrolladores<\/a> necesitan el mismo nivel de seguridad que los servidores de producci\u00f3n: EDR, segmentaci\u00f3n de red, control de acceso privilegiado. Los tiempos en que las m\u00e1quinas de los desarrolladores ten\u00edan un papel especial han pasado.<\/p>\n 6. Complementar los datos de NVD con inteligencia de amenazas comercial.<\/strong> Dada la brecha del 65 por ciento en las puntuaciones CVSS, los esc\u00e1neres basados \u00fanicamente en NVD son insuficientes. Servicios como Sonatype, Snyk o Tidelift proporcionan datos m\u00e1s oportunos y completos.<\/p>\n 7. Definir un plan de respuesta a incidentes para incidentes de la cadena de suministro.<\/strong> \u00bfQui\u00e9n es responsable cuando se descubre una biblioteca comprometida? \u00bfQu\u00e9 tan r\u00e1pido se pueden identificar y parchear los sistemas afectados? Estos procesos deben estar en su lugar antes del incidente, no despu\u00e9s.<\/p>\n Los ataques a la cadena de suministro de software est\u00e1n industrializados en 2026. La campa\u00f1a GlassWorm muestra c\u00f3mo los atacantes comprometen simult\u00e1neamente 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\u00f3n de riesgos de la cadena de suministro sea obligatoria, y el BSI proporciona con la directiva SBOM el instrumento. Quien no act\u00fae ahora ser\u00e1 tomado por sorpresa en el pr\u00f3ximo GlassWorm.<\/p>\n 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\u00f3digo abierto, extensiones de IDE, herramientas de compilaci\u00f3n o paquetes de registros p\u00fablicos como npm o PyPI. El c\u00f3digo malicioso se distribuye autom\u00e1ticamente con la pr\u00f3xima actualizaci\u00f3n o instalaci\u00f3n.<\/p>\n Sin SBOM y an\u00e1lisis de dependencias, la respuesta honesta es: probablemente no. El primer paso es hacer un inventario de todos los componentes de c\u00f3digo abierto utilizados. Herramientas como Grype o Syft pueden crear SBOM de forma automatizada y compararlos con bases de datos de vulnerabilidades conocidas.<\/p>\n No. Un WAF protege la aplicaci\u00f3n de ataques externos a nivel de red. Los ataques a la cadena de suministro provienen del interior, a trav\u00e9s de dependencias comprometidas que se consideran de confianza. Aqu\u00ed ayudan el an\u00e1lisis de dependencias, la gesti\u00f3n de SBOM y la lista blanca de extensiones.<\/p>\n El art\u00edculo 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\u00f3n de SBOM. Las empresas deben documentar qu\u00e9 componentes utilizan y demostrar procesos para una respuesta r\u00e1pida en caso de vulnerabilidades.<\/p>\n Para las PYME con una pipeline CI\/CD existente, el esfuerzo es de 10.000 a 30.000 euros una vez (herramientas, introducci\u00f3n de SBOM, pol\u00edticas de extensi\u00f3n) m\u00e1s costos corrientes para bases de datos de vulnerabilidades comerciales (2.000-10.000 euros\/a\u00f1o). Sin una pipeline CI\/CD, los costos aumentan a 40.000-80.000 euros, porque primero hay que construir la infraestructura.<\/p>\n Comprobaci\u00f3n pr\u00e1ctica de SBOM: lista de materiales de software hasta septiembre de 2026<\/a> (SecurityToday)<\/p>\n NIS2 en Alemania: lo que las empresas deben saber y hacer ahora (SecurityToday)<\/p>\n Phishing con IA: el 82 por ciento de los correos electr\u00f3nicos de ataque son de m\u00e1quinas<\/a> (SecurityToday)<\/p>\n NIS2 y cadena de suministro SaaS: la brecha de cumplimiento<\/a> (cloudmagazin)<\/p>\n Seguridad de la cadena de suministro de contenedores: SBOM y protecci\u00f3n de Docker – cloudmagazin<\/a><\/p>\n\n
GlassWorm: Anatom\u00eda de un ataque industrializado<\/h2>\n
La industrializaci\u00f3n de la cadena de suministro de software como superficie de ataque<\/h2>\n
Por qu\u00e9 fallan los conceptos de seguridad cl\u00e1sicos<\/h2>\n
NIS-2 y la obligaci\u00f3n de la cadena de suministro<\/h2>\n
Siete medidas contra ataques a la cadena de suministro<\/h2>\n
Conclusi\u00f3n<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfQu\u00e9 es exactamente un ataque a la cadena de suministro de software?<\/h3>\n
\u00bfC\u00f3mo s\u00e9 si mi empresa se ve afectada?<\/h3>\n
\u00bfProtege un firewall de aplicaciones web contra ataques a la cadena de suministro?<\/h3>\n
\u00bfQu\u00e9 exige concretamente NIS-2 para la cadena de suministro de software?<\/h3>\n
\u00bfCu\u00e1nto cuesta asegurar la cadena de suministro de software?<\/h3>\n
Lecturas adicionales<\/h2>\n
M\u00e1s del MBF Media Netzwerk<\/h2>\n