El consejo es siempre el mismo cuando una herramienta de vulnerabilidades detecta una CVE: actualizar. Pásate a la versión parcheada para que puedas cerrar el ticket y seguir adelante. Se ha convertido en un reflejo tan arraigado que nadie se detiene a preguntar si realmente funcionará.
La solución propuesta falla de tres maneras específicas. No hay una versión a la que actualizar y nunca la habrá, la versión parcheada aún no se ha lanzado, o la solución se lanza y rompe tu aplicación.
En resumen, las mejores prácticas y todos los frameworks, desde SOC2 hasta ISO27001, te dicen que mantengas tus dependencias actualizadas. Pero actualizar no equivale a solucionar, y, sin embargo, es la única respuesta que muchas herramientas ofrecen.
No siempre fue un instinto equivocado. Los mantenedores (afortunadamente) han estado corrigiendo vulnerabilidades en la última versión, y durante años eso fue suficiente.
Se reportan CVEs > los mantenedores las parchean > tú actualizas > obtienes la solución.
Pero los mantenedores generalmente no vuelven atrás para corregir versiones antiguas. Así que los equipos se acostumbraron a actualizar siempre a la versión cuando podían, y los atacantes notaron ese patrón y aprendieron a explotarlo. Ahora, cuando actualizas para corregir la CVE, existe la posibilidad de que en algún lugar de la actualización haya malware, por lo que obtener la última versión ya no es automáticamente seguro.
A principios de este año, los atacantes comprometieron una cuenta de mantenedor responsable de algunos de los paquetes más descargados en npm. chalk y debug, entre ellos, más de dos mil millones de descargas a la semana. Publicaron versiones maliciosas a través del canal oficial, y cada pipeline configurado para la autoactualización las incorporó directamente. Los equipos que seguían las mejores prácticas estaban distribuyendo malware en cuestión de minutos.
Es una situación de perder-perder. Te mantienes actualizado y te arriesgas a incorporar malware, o te congelas y acumulas deuda de seguridad. Esto es lo que llamamos la trampa de la actualización. La versión que ejecutas y las correcciones de seguridad aplicadas a ella no tienen por qué ser la misma decisión.
Las tres formas en que la actualización falla
Por supuesto, la «actualización» funciona muchas veces y sigue siendo importante. Pero hay tres situaciones en las que falla.
La primera es cuando no hay una versión corregida a la que migrar (y nunca la habrá). Tomemos request, uno de los clientes HTTP más utilizados en Node, que ha sido deprecado desde 2020. Y, sin embargo, sigue apareciendo en todas partes, normalmente arrastrado por algún paquete padre que nadie ha tocado en muchísimos años. Cuando ejecutas una herramienta SCA sobre request, la herramienta detecta una CVE para un bypass de mitigación de falsificación de solicitudes del lado del servidor (SSRF). ¿Adivina cuál es la solución aquí según la herramienta SCA? Sí, actualizar.
Pero lo más importante es que no hay nada a lo que actualizar, y nunca lo habrá. request no ha recibido mantenimiento en años. El aviso casi lo dice explícitamente, señalando que la vulnerabilidad solo afecta a versiones que el mantenedor ya no soporta (es decir, todas las versiones). Así que, en este caso, «actualizar» en realidad significa eliminar request y migrar a algo como axios o node-fetch. Eso es una reescritura y una migración, y significa que, hasta que alguien tenga tiempo para ello, la CVE simplemente permanece ahí.
Eso asume que la solución debe provenir del mantenedor. Para los paquetes EOL, alguien todavía tiene que entender la vulnerabilidad y escribir una solución para la versión ya en uso. Las distribuciones han hecho esto para los paquetes a nivel de sistema operativo durante años. El mismo enfoque ahora existe para las bibliotecas de aplicaciones, que es donde la mayoría de los equipos están atascados.
El segundo tipo de actualización es cuando la solución no existe todavía aunque el paquete esté activo. La popular librería lodash pasó un período de tiempo el año pasado con dos vulnerabilidades divulgadas que afectaban a todas las versiones publicadas hasta la 4.17.23 inclusive. Dado que esa era la última versión, no había nada a lo que actualizar. npm audit marcó las CVEs y reportó que no había ninguna solución disponible. Así que, aunque el consejo de actualizar era sensato, no era realmente factible porque la versión parcheada no se había lanzado.
La tercera es cuando el parche se despliega y rompe tu aplicación. CVE-2026-48937 en Node es un ejemplo reciente. El parche para la vulnerabilidad venía incluido con una SEMVER-MAJOR actualización de la nghttp2 dependencia y la eliminación del soporte de señalización de prioridad HTTP/2. El comportamiento vulnerable y la característica eliminada formaban parte del mismo código subyacente, por lo que no había forma de aplicar la corrección de seguridad sin asumir el cambio disruptivo. Los usuarios tuvieron que buscar con grep setPriority y .priority() y eliminarlos antes de poder actualizar.
Este es el riesgo de cualquier actualización. Una nueva versión puede cambiar el comportamiento de un paquete lo suficiente como para romper algo que funcionaba, forzar a otras dependencias a actualizarse con él, o llegar como una versión mayor que requiere una migración antes 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 romper algo de lo que depende tu sistema. Ingeniería se enfrenta entonces a la elección entre un elemento de la hoja de ruta que genera ingresos y la actualización. ¿Adivina cuál gana 😬? Entonces terminas con deuda técnica y una acumulación de CVEs.
Cómo la IA alteró el panorama
La mayoría de las empresas tienen una acumulación de CVEs demasiado grande para gestionar, y están nerviosas porque los últimos modelos de vanguardia pueden encontrar vulnerabilidades más rápido. Pero lo que es aún más amenazante es que pueden encadenar CVEs de gravedad media de una manera que los convierte en un patrón de explotación crítico. El modelo actual de escaneo, triaje y asignación de ese trabajo a los ingenieros no escala lo suficientemente rápido para gestionar este problema. La IA está, en efecto, agravando un problema existente y haciendo que sea más urgente para las organizaciones solucionarlo.
Qué hace la industria al respecto
Actualizar fue la única respuesta realista durante mucho tiempo. Los atrasos de CVE y las compilaciones fallidas que siguieron fueron una consecuencia predecible del limitado conjunto de opciones. Hay, en general, tres enfoques para este problema. Dos de ellos intercambian un problema por otro. El tercero es el que más se acerca a cerrar realmente el CVE sin crear uno nuevo.
El primero es el cribado en el punto de consumo. Antes de que un paquete llegue a su compilación, se comprueba: ¿es esta dependencia segura de instalar? Es una capa necesaria, especialmente después de ataques como chalk y debug. Pero no se ajusta a los paquetes vulnerables que ya están en producción. Es una puerta de entrada más 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 empuja hacia un ecosistema propietario sobre el que no tienen control. 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 técnicos 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 de 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 estás 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 esto. Hacerlo en todas las bibliotecas de aplicaciones, de forma automática y al ritmo en que surgen los CVE, es un problema totalmente diferente. En el caso de los paquetes en fin de vida útil (EOL) para los que no va a llegar ninguna corrección del desarrollador original, alguien tiene que seguir entendiendo la vulnerabilidad y escribir una corrección para la versión que ya se está utilizando. Ese mismo trabajo existe ahora como una opción escalable para las bibliotecas de aplicaciones, que es donde la mayoría de los equipos se encuentran atascados. El único caso en el que esto no se aplica es cuando aún no existe ninguna corrección del desarrollador original. Si el responsable del mantenimiento no ha escrito el parche, no hay nada que aislar ni aplicar. El CVE permanece ahí hasta que alguien lo haga.
Mantienes la versión en la que tu aplicación ya confía, aplicas solo la corrección y no acumulas CVE contra una versión congelada ni extraes la última versión con todo lo que conlleva.
Piensa en tu pila de software como una casa en la que has vivido durante años. La mayoría de las herramientas o bien criban lo que entra por la puerta, te entregan una lista de reparaciones y te dicen que las gestiones, o te piden que te mudes a una casa nueva y más pequeña que ellos construyeron. Arreglar la casa en la que ya vives es lo que la mayoría de los equipos realmente quieren.
Ahora existe una opción que hace exactamente eso: solucionar vulnerabilidades en los paquetes de código abierto de los que depende tu aplicación sin necesidad de actualizar, con Aikido Libraries.
