Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
La IA está a punto de superar la capacidad de detectar vulnerabilidades de software, pero no la de solucionarlas.
En abril de 2026, Anthropic anunció el Proyecto Glasswing junto con once socios principales, entre los que se incluyen AWS, Apple, Cisco, Google, JPMorgan Chase, la Fundación Linux, Microsoft y Palo Alto Networks.
La iniciativa se basa en Claude Mythos Preview, un modelo de vanguardia que ya ha detectado miles de vulnerabilidades de alta gravedad, entre las que se incluyen fallos en todos los principales sistemas operativos y navegadores web. Algunas de esas fallas habían pasado desapercibidas durante décadas de auditorías realizadas por personas, lo que cambia las reglas del juego para cualquiera que comercialice software con componentes de código abierto.
Aunque el acceso es limitado por el momento, la tendencia es clara: la detección de vulnerabilidades es cada vez más rápida, más económica y está cada vez más automatizada, y no seguirá siendo un privilegio exclusivo de un pequeño grupo de expertos en seguridad.
La seguridad de la cadena de suministro de código abierto siempre se ha reducido a una pregunta: quién es responsable de solucionar qué, y con qué rapidez se hace. Tras Glasswing, la detección de vulnerabilidades mediante IA avanza a la velocidad de las máquinas, mientras que la aplicación de parches sigue avanzando al ritmo del calendario.
Esta presión afecta a dos aspectos distintos del riesgo del software libre: lo que se instala y lo que ocurre después. Por un lado, se trata de la confianza en el propio paquete. Por otro, se trata de si las vulnerabilidades llegan a solucionarse. Ambos aspectos están a punto de verse sometidos a presión de diferentes maneras.
Y las autoridades reguladoras lo han dejado claro: si distribuyes el código binario, la responsabilidad del error recae sobre ti.
El proyecto Glasswing y la avalancha de vulnerabilidades CVE que se avecina en tus dependencias
Mythos Preview no es un escáner más rápido. Analiza bases de código complejas y genera exploits funcionales, no hallazgos teóricos. Anthropic restringió el acceso a los socios de Glasswing precisamente porque esa misma capacidad acabaría en manos de los adversarios. El margen de maniobra para los defensores es reducido, y la mayoría de los equipos aún no han adaptado sus hipótesis.
Hay dos consecuencias concretas que revisten especial importancia para las organizaciones que dependen de paquetes de código abierto.
En primer lugar, el volumen de CVE va a aumentar. Mythos ya ha detectado miles de fallos en código que había sido objeto de auditorías exhaustivas. Las bibliotecas de código abierto destinadas a entornos de producción que nunca han sido sometidas a ese nivel de escrutinio recibirán el mismo tratamiento a medida que modelos similares lleguen al mercado general. La mayoría de los equipos de seguridad ya van con retraso en la gestión de los CVE pendientes.
En segundo lugar, se reduce drásticamente el tiempo que transcurre entre la divulgación y la explotación. El acuerdo de nivel de servicio (SLA) de 30 días para la aplicación de parches se basaba en el lapso de tiempo que media entre la publicación de un CVE y la aparición de un exploit operativo para él. Mythos elimina ese lapso en una sola sesión.
Si tu estrategia de parches se basa en un flujo constante y manejable de CVE en los paquetes que se mantienen activamente, ambas partes de esa suposición están a punto de desmoronarse.
En pocas palabras:
- El descubrimiento de vulnerabilidades se está acelerando
- La creación de exploits se está acelerando
- La velocidad de aplicación de parches no es
Es en ese vacío donde el riesgo se agrava.
Eres responsable de todas las dependencias que distribuyes
El cambio normativo ha pasado más desapercibido que el anuncio sobre la IA, pero tiene las mismas repercusiones.
En virtud de la Ley de Ciberresiliencia de la UE, los fabricantes son responsables de la seguridad de los productos con elementos digitales durante todo su periodo de soporte, incluidos todos los componentes de código abierto integrados. Las sanciones pueden alcanzar los 15 millones de euros o el 2,5 % de la facturación anual global. El fabricante es la entidad que comercializa el producto. No importa quién haya escrito la dependencia, si el mantenedor recibe una remuneración o si el proyecto de origen ha sido abandonado. Si lo comercializas, asumes la responsabilidad.
FedRAMP ha avanzado en la misma dirección. Se espera que los proveedores de servicios en la nube mantengan la seguridad de todos los componentes dentro de su ámbito de autorización, con procesos de aplicación de parches documentados y el software al final de su vida útil (EOL) marcado como un problema de autorización conocido. En el marco de FedRAMP 20x, las SBOM que coincidan con lo que realmente se está ejecutando se están convirtiendo en un requisito básico.
Los contratos con los clientes también se han adaptado a esta tendencia. Los equipos de compras ahora solicitan SBOM, documentos VEX y acuerdos de nivel de servicio (SLA) para parches como elementos estándar. «Utilizamos una biblioteca de terceros» no es una respuesta válida cuando se produce un ataque en el entorno de producción.
El modelo jurídico es fácil de resumir. La responsabilidad se rige por el sistema binario, no por la licencia del código fuente. La defensa basada en el «método de los muchos ojos» nunca ha tenido validez jurídica y, tras el caso Glasswing, tampoco es viable desde el punto de vista técnico.
El software de código abierto conlleva dos riesgos distintos
El software de código abierto conlleva dos riesgos distintos al incorporarlo a tu entorno. El primero es la integridad de la cadena de suministro: qué contiene realmente el paquete el día de la instalación. El segundo es la aplicación de parches: la rapidez con la que se corrige una vulnerabilidad conocida y qué ocurre cuando no hay ninguna solución a la vista.
Se trata de problemas distintos con modelos de amenaza diferentes. Los ataques a la cadena de suministro son una cuestión de credenciales y confianza. Glasswing no tiene nada que ver con ellos, y estos llevan años intensificándose por su propia cuenta. Es en la aplicación de parches donde Glasswing cambia las reglas del juego, tanto durante el mantenimiento activo como tras el fin de vida útil (EOL). La combinación es lo nuevo. El mismo equipo de seguridad que ya estaba haciendo frente a un ritmo constante de ataques a la cadena de suministro ahora se enfrenta a una avalancha de CVE más rápida y de mayor envergadura que afecta a todo el árbol de dependencias.
A la responsabilidad no le importa qué problema te haya afectado. Ahora repasemos cada uno de ellos por orden.
La amenaza desde el primer día: paquetes comprometidos
El primer riesgo de cualquier dependencia es lo que contiene el día de su instalación. Desde hace años, artefactos manipulados, cuentas de mantenedores secuestradas y dominios falsos que se aprovechan de similitudes ortográficas han ido llegando al entorno de producción a través de instalaciones de registros que parecen fiables.
Marzo de 2026 el ataque a Axios es el ejemplo reciente más destacado: las credenciales robadas al mantenedor principal del proyecto, un gancho malicioso de postinstalación enviado a unos 100 millones de usuarios que lo descargaban semanalmente durante tres horas.
Otros casos recientes incluyen el gusano Shai-Hulud y el incidente de la CLI de Bitwarden , que tenía como objetivo las credenciales de una herramienta de programación de IA.
Esta categoría sigue su propio camino. Glasswing no facilita ni dificulta los ataques a la cadena de suministro de npm, y Mythos no puede ayudar a un atacante a comprometer la cuenta de un mantenedor. Sin embargo, la amenaza lleva años intensificándose, impulsada únicamente por los incentivos de los atacantes, y, en el marco de la CRA, entra en la misma categoría de responsabilidad que cualquier otro producto que se distribuya. La detección se produce horas después de que se haya producido el incidente.
La prevención requiere una fuente de paquetes que haya sido verificada, firmada y recompilada a partir de código fuente auditable, en lugar de obtenerse directamente de un registro público.
La amenaza de la falta de parches: software activo y al final de su vida útil
Los ataques a la cadena de suministro se centran en quién controla el artefacto. La brecha de parches se refiere a algo distinto: la rapidez con la que se corrige un error conocido en un paquete legítimo y sin manipular en el código que se ejecuta.
Esto se manifiesta de dos formas: parches lentos en las bibliotecas que reciben mantenimiento y ausencia total de parches en las que han llegado al final de su ciclo de vida (EOL). Glasswing agrava ambas situaciones.
Cuando se publican los parches tras la aparición de vulnerabilidades
El tiempo que tarda en publicarse un parche varía mucho dentro del ecosistema. Los proyectos de primer nivel con un proceso de divulgación coordinado publican el parche en cuanto se hace público el CVE. El resto del ecosistema se mueve más lentamente: unas horas para correcciones triviales, semanas o más cuando el mantenedor tiene que realizar un backport, preservar la compatibilidad de la API o compaginarlo con su trabajo diario.
La implementación en tu entorno añade tiempo adicional al de la ventana de origen.
Esa ventana solía ser aceptable. El desarrollo de exploits era lo suficientemente lento como para que los defensores tuvieran una ventaja considerable sobre los atacantes.
Mythos acaba con esa ventaja inicial. El descubrimiento y la explotación se producen ahora en una sola sesión, y esta capacidad no se limitará a los defensores. Una vez que modelos similares lleguen a manos de los adversarios, el plazo para aplicar los parches se convierte en un plazo de exposición. Para cuando el parche esté disponible, el exploit ya lleva días circulando.
El paquete está actualizado y el responsable de su mantenimiento responde con rapidez. Pero nada de eso sirve de ayuda cuando el sistema se ve comprometido al tercer día de un ciclo de parches de catorce días.
Bibliotecas EOL tras Glasswing
El periodo posterior a la fecha de fin de vida útil es el periodo sin parches, durante el cual no se lanzará ningún parche, nunca.
Log4Shell (CVE-2021-44228) sigue figurando entre las diez vulnerabilidades más atacadas más de cuatro años después de su revelación, ya que Log4j sigue integrado en aplicaciones heredadas que nadie quiere migrar. El mismo patrón se repite en toda la larga lista de bibliotecas sin mantenimiento: errores conocidos, exploits públicos y una base instalada cuya actualización resultaría demasiado disruptiva. El informe «State of DevSecOps 2026» de Datadog reveló que los servicios que se ejecutan en versiones de lenguaje en fin de vida útil (EOL) tienen una tasa de vulnerabilidades explotables del 50 %, en comparación con el 31 % de los que cuentan con soporte, y que la mediana de las dependencias se encuentra 278 días por detrás de su última versión.
Ahora aplica el descubrimiento de clases de Glasswing a esa población.
El parche de una biblioteca mantenida acaba llegando, aunque sea lentamente. Cuando Mythos detecta una vulnerabilidad de día cero en algo como Python 3.7, una versión de Spring Framework fuera de ciclo de vida o cualquiera de los miles de paquetes de npm cuyo mantenedor no ha publicado nada desde hace dos años, el fallo se hace público y queda sin parchear para siempre. Las actualizaciones forzadas son la primera solución a la que recurre todo el mundo. En la práctica, requieren migraciones con cambios radicales en el código de aplicaciones que no se han tocado en años, con un riesgo de regresión y unos costes de ingeniería que los equipos de cumplimiento normativo no pueden asumir.
Es aquí donde el fin de la vida útil deja de ser un problema de mantenimiento y se convierte en un riesgo de seguridad permanente.
En un mundo tras Glasswing, el software sin mantenimiento no solo es arriesgado, sino que es previsible y repetidamente vulnerable a los ataques, sin que vaya a llegar nunca ningún parche.
Cómo SecureChain para software de código abierto cubre esa brecha
SecureChain para software de código abierto sustituye tus registros públicos de paquetes por una fuente controlada y protegida de forma continua. Tus desarrolladores siguen trabajando como siempre.
Detrás de una única URL de registro se producen tres cambios:
- Todos los paquetes se vuelven a compilar a partir del código fuente verificado
Cada paquete se compila en un entorno seguro y aislado a partir de código fuente auditable. Sin binarios heredados, sin artefactos opacos del desarrollador original.
- El malware se bloquea antes de llegar a tu pila
Cada paquete se analiza a nivel de código fuente en busca de código malicioso, puntos de instalación sospechosos y firmas de amenazas conocidas antes de llegar al registro.
- Los parches se distribuyen de forma continua, incluso después de que el producto haya dejado de comercializarse
SecureChain proporciona parches en virtud del acuerdo de nivel de servicio (SLA) a medida que surgen nuevas vulnerabilidades CVE, incluidas aquellas que aporta nuestro equipo cuando el proveedor original no las cubre. La cobertura continúa tras el fin del soporte técnico, en la versión que ya está utilizando, sin actualizaciones obligatorias ni reescrituras del código.
Listo para una auditoría desde el primer día
En lo que respecta al cumplimiento normativo, este problema tiene sus propios requisitos. Cada paquete que envía SecureChain lleva un historial de compilación de nivel 3 de SLSA , una SBOM firmada que coincide con el binario que recibes y documentos VEX que indican si cada CVE señalada en el paquete está parcheada en la versión que estás ejecutando o no es aplicable a ella.
Esos tres documentos son precisamente lo que solicitan los equipos de auditoría y de compras. La trazabilidad de nivel 3 de SLSA demuestra que el paquete se ha compilado a partir del código fuente, que puede inspeccionarse, en un entorno de compilación reforzado, y que no ha sido manipulado durante el traslado. La SBOM indica al auditor exactamente qué elementos se encuentran en producción. El documento VEX indica al escáner qué parches se han aplicado y cuáles no son aplicables a esta versión, de modo que su equipo no tenga que clasificar CVE que ya están solucionadas.
Si se añade un compromiso de corrección respaldado por un SLA, el aumento del volumen de CVE no se traduce en un aumento de los hallazgos de auditoría. La documentación que necesita tu equipo de cumplimiento normativo se genera como efecto secundario de los propios parches.
Lo que obtienen tus equipos a cambio
El código abierto sigue siendo la mejor forma de desarrollar software. La idea que se suele tener, sobre todo en situaciones de presión, es que adoptar un paquete es una decisión que solo hay que tomar una vez y que no conlleva ningún coste de seguridad a largo plazo.
SecureChain te ofrece la velocidad y la flexibilidad del código abierto sin riesgos.
Tu equipo se centra en desarrollar productos en lugar de perseguir problemas de seguridad. Tus desarrolladores siguen instalando los paquetes que ya utilizan. Tu proceso de compilación apunta a SecureChain en lugar de al registro público. Los parches siguen llegando para los componentes que importan, incluidos aquellos que la comunidad de código abierto ya ha dejado atrás. La procedencia y las listas SBOM se generan automáticamente. Cuando se produzca la próxima revelación del tipo Glasswing, la respuesta será una actualización de versión, no un incidente de seis semanas.
No es necesario que cambies tu pila para reducir este riesgo, pero sí debes modificar la forma en que se gestiona.
La responsabilidad sobre lo que envías no cambia. Lo que cambia es el trabajo de transportarlo.
