El consejo es siempre el mismo cuando una herramienta de detección de vulnerabilidades señala un CVE: actualizar. Pasar a la versión parcheada para poder cerrar el ticket y seguir adelante. Se ha convertido en un acto tan instintivo que nadie se para a preguntarse si realmente funcionará.
La solución propuesta falla en tres aspectos concretos: no hay ninguna versión a la que actualizar y nunca la habrá; la versión parcheada aún no se ha lanzado; o bien, si se lanza la solución, esta provoca errores en tu aplicación.
En resumen, las mejores prácticas y todas las normas, desde SOC 2 hasta ISO 27001, recomiendan mantener actualizadas las dependencias. Sin embargo, actualizar no equivale a corregir, y, sin embargo, es la única solución que ofrecen muchas herramientas.
No siempre fue un instinto erróneo. Los responsables del mantenimiento (afortunadamente) han estado corrigiendo vulnerabilidades en la última versión, y durante años eso fue suficiente.
Se notifican los CVE > los responsables del mantenimiento los corrigen > actualizas > obtienes la corrección.
Pero los responsables del mantenimiento no suelen volver atrás para corregir versiones anteriores. Así que los equipos se acostumbraron a actualizar siempre a la última versión cuando podían, y los atacantes se dieron cuenta de ese patrón y aprendieron a aprovecharlo. Ahora, cuando actualizas para solucionar el CVE, existe cierta probabilidad de que en algún lugar de la actualización haya malware, por lo que descargar la última versión ya no es automáticamente seguro.
A principios de este año, unos atacantes comprometieron una cuenta de mantenedor responsable de algunos de los paquetes más descargados de npm: chalk y debug, que suman entre ambos más de dos mil millones de descargas a la semana. Publicaron versiones maliciosas a través del canal oficial, y todos los procesos de actualización automática las incorporaron directamente. Los equipos que seguían las mejores prácticas acabaron distribuyendo malware en cuestión de minutos.
Es una situación en la que todos salen perdiendo. O te mantienes al día y te arriesgas a introducir malware, o te quedas estancado y acumulas una deuda de seguridad. A esto es lo que llamamos la «trampa de las actualizaciones». La versión que utilizas y las correcciones de seguridad que se le aplican no tienen por qué ser la misma decisión.
Las tres razones por las que falla la actualización
Por supuesto, la «actualización» funciona en la mayoría de los casos y sigue siendo importante. Pero hay tres situaciones en las que falla.
El primer caso es cuando no hay una versión fija a la que migrar (y nunca la habrá). Por ejemplo: solicitud, uno de los clientes HTTP más utilizados en Node, que está obsoleto desde 2020. Y, sin embargo, sigue apareciendo por todas partes, normalmente arrastrado por algún paquete principal que nadie ha tocado desde hace una eternidad. Cuando se ejecuta una SCA sobre «request», la herramienta detecta un CVE relacionado con eludir las medidas de mitigación de la falsificación de solicitudes del lado del servidor (SSRF). ¿Adivinas cuál es la solución que propone la SCA ? Exacto: actualizar.
Pero lo peor es que no hay nada a lo que actualizarse, y nunca lo habrá. solicitud no se ha actualizado desde hace años. El aviso prácticamente lo dice así, ya que señala que el fallo solo afecta a las versiones que el responsable ya no mantiene (es decir, todas las versiones). Así que, en este caso, «actualizar» significa, en realidad, desinstalar solicitud dejar eso y pasar a algo como axios o node-fetch. Eso supone una reescritura y una migración, y significa que, hasta que alguien tenga tiempo para hacerlo, el CVE se queda ahí sin más.
El segundo tipo de actualización se da cuando no existe la corrección sin embargo aunque el paquete siga activo. La popular biblioteca lodash El año pasado pasó un tiempo con dos vulnerabilidades conocidas que afectaban a todas las versiones publicadas hasta la 4.17.23, incluida esta. Como esa era la última versión, no había nada a lo que actualizar. npm audit señaló los CVE e informó de que no había ninguna corrección disponible. Así que, aunque la recomendación de actualizar era acertada, en realidad no era viable porque aún no se había lanzado la versión parcheada.
La tercera es cuando se lanza la corrección y hace que tu aplicación deje de funcionar. CVE-2026-48937 en Node es un ejemplo reciente. La corrección de la vulnerabilidad se incluyó junto con un SEMVER-MAJOR actualización de la nghttp2 la dependencia y la eliminación de la compatibilidad con la señalización de prioridad de HTTP/2. El comportamiento vulnerable y la característica que se iba a eliminar formaban parte del mismo código subyacente, por lo que no había forma de aplicar la corrección de seguridad sin incluir al mismo tiempo el cambio que provocaba incompatibilidades. Los usuarios tenían que buscar con «grep» establecer prioridad y .priority() y eliminarlos antes de que pudieran actualizar en absoluto.
Este es el riesgo que conlleva cualquier actualización. Una nueva versión puede modificar el comportamiento de un paquete hasta el punto de que deje de funcionar algo que antes funcionaba, obligar a actualizar otras dependencias junto con él, o presentarse como una versión principal que requiera una migración antes incluso de poder instalarse.
Y, yendo un paso más allá, si actualizas un paquete, es posible que tengas que actualizar otros cinco. Uno de ellos podría provocar un fallo en algún componente del que depende tu sistema. El equipo de ingeniería se enfrenta entonces a la disyuntiva entre un elemento de la hoja de ruta que genera ingresos y la actualización. Adivina cuál se lleva la palma 😬. Al final, acabas acumulando deuda técnica y una montaña de vulnerabilidades CVE.
Cómo la IA ha cambiado las reglas del juego
La mayoría de las empresas tienen una acumulación de CVE demasiado grande como para poder gestionarla, y están preocupadas porque los modelos de última generación pueden detectar vulnerabilidades más rápidamente. Pero lo que supone una amenaza aún mayor es que pueden encadenar CVE de gravedad media de tal forma que se conviertan en un patrón de explotación crítico. El modelo actual de análisis, clasificación y distribución de ese trabajo entre los ingenieros no se adapta con la rapidez suficiente para gestionar este problema. La IA está agravando de hecho un problema ya existente y haciendo que su solución sea aún más urgente para las organizaciones.
Qué hace el sector al respecto
Durante mucho tiempo, la actualización fue la única solución realista. La acumulación de CVE y los errores de compilación que se produjeron a raíz de ello fueron una consecuencia previsible de las limitadas opciones disponibles. En términos generales, existen tres enfoques para abordar este problema. Dos de ellos cambian un problema por otro. El tercero, en cambio, resuelve el CVE sin correr el riesgo de que surja uno nuevo.
La primera es la detección en el punto de consumo. Antes de que un paquete llegue a tu entorno de compilación, se comprueba: ¿es seguro instalar esta dependencia? Se trata de una medida necesaria, sobre todo tras ataques como «chalk» y «debug». Sin embargo, no sirve para los paquetes vulnerables que ya están en producción. Es más un filtro que una solución y, fuera de ese ámbito, la respuesta sigue siendo actualizar.
La segunda consiste en trasladar a los equipos a una pila de sustitución reforzada. En lugar de arreglar lo que los equipos ya utilizan, se les obliga a pasar al ecosistema propietario de otra empresa. Esto puede funcionar para aplicaciones nuevas, pero en el caso de los sistemas de producción que dependen de bibliotecas e imágenes base específicas, convierte la corrección de problemas en un proyecto de migración. Una vez dentro, salir de ahí es un proyecto en sí mismo.
La tercera opción consiste en aplicar la corrección a la versión que ya se está utilizando. La mayoría de las organizaciones no tienen la capacidad, los conocimientos ni la voluntad para hacerlo. Cuando se corrige un CVE en el código fuente original, se aísla la parte más pequeña del código que lo soluciona de la versión más reciente y se aplica de forma limpia a la versión anterior que ya se está ejecutando. Comprobar que no ha cambiado nada más requiere una gran experiencia y un mantenimiento continuo. Las distribuciones llevan años haciendo versiones de este tipo. Hacerlo en todas las bibliotecas de aplicaciones, de forma automática y al ritmo en que surgen los CVE, es un problema totalmente distinto. Este enfoque implica mantener la versión en la que tu aplicación ya confía, aplicar solo la corrección y, de este modo, no acumular CVE en una versión congelada ni descargar la última versión con todo lo que esta conlleva.
Piensa en tu pila de software como una casa en la que llevas viviendo años. La mayoría de las herramientas o bien filtran lo que entra por la puerta, te entregan una lista de reparaciones y te dicen que te las apañes tú, o bien te piden que te mudes a una casa nueva y más pequeña que ellas mismas han construido. Lo que la mayoría de los equipos realmente quieren es arreglar la casa en la que ya viven.
Ahora existe una opción que hace precisamente eso: corregir las vulnerabilidades de los paquetes de código abierto de los que depende tu aplicación sin necesidad de actualizar, gracias a Aikido Libraries.
