Un puente permanece en servicio durante cincuenta años siguiendo un calendario de inspecciones fijo, sometido a pruebas de carga y con un mantenimiento constante durante todo ese tiempo. Un motor a reacción del mismo diseño vuela durante décadas bajo una supervisión normativa continua. En la mayoría de las disciplinas de ingeniería, el objetivo es contar con un diseño estable y probado, combinado con un mantenimiento activo. Los diseños más recientes se someten a un escrutinio mucho mayor, ya que nunca se han probado realmente.
Pero, por alguna razón, en ingeniería de software ocurre justo lo contrario. La versión más reciente se considera la más segura. Y ese instinto ha tenido graves consecuencias negativas en el pasado. Una puerta trasera se ocultaba en dos versiones concretas de xz-utils, las versiones 5.6.0 y 5.6.1, implantadas por un infiltrado que había tardado entre dos y tres años en conseguir los permisos necesarios para su lanzamiento. Quienes seguían utilizando la línea 5.4 x más antigua nunca se vieron expuestos, pero quienes habían descargado la última versión —lo que normalmente se recomienda a los equipos de seguridad— estaban utilizando una conexión SSH con una puerta trasera. La recomendación posterior de la propia CISA fue rebajar la versión, en lugar de actualizarla.
Ya lo hemos argumentado anteriormente, en lo que denominamos «la trampa de las actualizaciones», que aplicar el parche en cuanto aparece un CVE es un falso ahorro; estás eligiendo entre quedarte estancado o aceptar cualquier cambio que traiga consigo la corrección. xz-utils nos muestra la otra cara de la misma moneda. Quedarse donde estaba era la opción segura, y el último lanzamiento era la trampa.
Una forma de comprobarlo es preguntar al equipo de seguridad cuál es el número de CVE pendientes; seguro que te dan una respuesta al instante. Pero si les preguntas por qué un paquete o una imagen de contenedor concretos están ejecutándose en la versión actual, lo más probable es que te respondan «no lo sé». Simplemente es así, ¿no? Normalmente se debe a lo que había disponible cuando se inició el proyecto, y actualizar parecía dar más trabajo del que merecía la pena. Yendo un paso más allá, si pides algún registro escrito de esa decisión, lo más probable es que recibas una respuesta más tajante del tipo«¿por qué tendríamos que hacer eso?».
Entonces, ¿en qué falla esto?
A menudo se hace creer a los ingenieros que una imagen de contenedor o un paquete se vuelve más arriesgado a medida que el número de versión va quedando obsoleto. Pero el xz-utils Este ejemplo demuestra que eso no es cierto; la versión anterior era segura porque aún no había llegado nada malicioso a ella, y los equipos que la utilizaban no se habían apresurado a adoptar la última versión en cuanto salió al mercado. Por supuesto, es posible que muchos equipos simplemente no hubieran tenido tiempo de actualizarla, aunque quisieran hacerlo. Aun así, eso es mejor que no saber qué versión se está utilizando, o por qué, que es el verdadero fallo en este caso.
En cambio, los equipos deben tener en cuenta que, si disponen de una versión de una biblioteca que ha sido probada, comprendida y en la que se confía, mantenerla estable aporta un valor real. La supervisión comienza en el momento en que un desarrollador, un agente o un proceso de compilación solicita una imagen base de contenedor o un paquete de código abierto, evaluándolo antes de que entre en el entorno. Es la primera decisión de una cadena de decisiones que se toman.
Una actualización también es una decisión
En algún momento saldrá una nueva versión, pero aplicar un parche para una vulnerabilidad CVE implica aceptar también todo lo demás que se haya incluido en esa versión. Eso incluye aspectos como las dependencias transitivas, los valores predeterminados modificados o las rutas de código que nadie del equipo ha leído. La mayoría de las veces, ese riesgo pasa desapercibido y no ocurre ningún problema. Pero —y es un «pero» importante— las cosas pueden salir mal. lodash Pasó una parte de 2026 con una vulnerabilidad de inyección de código arbitrario, ya revelada, que afectaba a todas las versiones publicadas. Cuando finalmente se lanzó la corrección en la versión 4.18.0, dejó de funcionar de inmediato porque el parche sustituía una función interna por otra que nunca se había importado, lo que provocó que los proyectos reales fallaran en menos de un día.
npm dejó de ofrecer esa versión por completo y recomendó a los usuarios que volvieran a lodash 4.17.21 En cambio, el cambio que provocó incompatibilidades no tenía nada que ver con la propia vulnerabilidad, sino que se trataba de un error de empaquetado que se incluyó junto con la corrección de seguridad. La corrección real se incorporó en la versión 4.18.1.
Ninguna de las opciones que se barajaban era realmente segura. La actualización a la versión 4.18.0 provocó inmediatamente fallos en las compilaciones. Mantener la versión 4.17.21 dejaba la vulnerabilidad sin solucionar, mientras que todas las versiones anteriores a la 4.18.0 seguían siendo vulnerables. Algunos equipos volvieron a la versión 4.17.x específicamente para « escape » la compilación defectuosa, cambiando una compilación que funcionaba por una vía de inyección de código activa sin darse cuenta necesariamente de que ese era el intercambio que habían realizado.
En este caso, los equipos que se encontraban en la posición más ventajosa eran aquellos que sabían si su propia aplicación llegaba siquiera a llamar a la función _ afectada.plantilla una ruta con datos de entrada no fiables, y podrían sopesar ese riesgo real frente a la alternativa defectuosa, en lugar de optar por cualquiera de las dos opciones sin saber lo que realmente les costaría.
Solucionar la vulnerabilidad sin tener que sustituir todo lo que la rodea
El retroportado cambia las reglas del juego. Toma la corrección específica para una vulnerabilidad concreta y la aplica a la versión que ya se está ejecutando, en lugar de incorporar todo lo demás que se incluyó en la versión original. Si se aplica a una imagen de contenedor, el CVE se corrige sin necesidad de imponer una nueva imagen base. Si se aplica a un paquete, se realiza la misma corrección sin tener que pasar obligatoriamente a la última versión, precisamente el cambio que provocó fallos en proyectos reales que se estaban ejecutando lodash 4.18.0. Puedes solucionar el problema de seguridad sin tener que cambiar todo lo que lo rodea.
Un « SBOM » debe ganarse su lugar, no basta con que exista
Un SBOM, al igual que tantos otros documentos relacionados con el cumplimiento normativo, suele consultarse una sola vez y archivarse. Eso te indica qué había en el sistema el día en que alguien generó el informe. Pero el SBOM puede aportar mucho más a tu nivel de seguridad que eso. Puede servir como referencia de confianza para el software y ayudarte a gestionar esa referencia de forma continua. Para ello, debes asegurarte de que se mantenga actualizado y se compare con las nuevas vulnerabilidades a medida que se van publicando. Para mí, esa es la señal más clara de que una organización sigue realizando un seguimiento del software que utiliza, en lugar de limitarse a conformarse con lo que ya tiene.
Queremos que el « SBOM » no sea solo un elemento de inventario o de cumplimiento normativo. Debe ser un entorno regulado y mantenido de forma activa.
Entonces, ¿qué hay que cambiar?
Todas estas son decisiones que hay que tomar. Algunas se refieren a un componente de software concreto en un momento dado, como evaluar una solicitud, fijar una versión y realizar un backport en lugar de forzar una actualización. Otras, como si mantener actualizado un SBOM , tienen que ver con los procesos que tienes implantados. En realidad, cada una de ellas es una decisión sobre en qué confiar.
Lo más fácil es dejar las cosas tal y como están, porque «funciona». Pero «que funcione» no es del todo cierto, ¿verdad? El hecho de que algo funcione no significa que vaya a funcionar siempre, ni que sea la forma más segura de hacer las cosas, ni que sea la mejor manera de actuar.
Desde nuestro punto de vista, el enfoque más proactivo y consciente en materia de seguridad consistiría en controlar los cambios en el punto de entrada: evaluar los paquetes antes de que un desarrollador, un agente o un sistema de compilación los utilice. A partir de ahí, deberías tener la libertad de decidir de forma proactiva qué se permite entrar, fijar las versiones en las que confías, mantenerlas y modificarlas únicamente cuando haya una razón para hacerlo.
Mantener una versión no debería significar permanecer expuesto. Bibliotecas de Aikido retroporta la corrección a la versión que ya estás ejecutando, sin actualizaciones forzadas ni migraciones obligatorias. Empieza a aplicar parches aquí.
