Uso de componentes con vulnerabilidades conocidas
La mayoría de las aplicaciones utilizan una gran cantidad de componentes de terceros. Estos componentes proporcionan todo lo necesario, desde el registro de datos hasta la creación de plantillas y el acceso a bases de datos.
Esto facilita enormemente el desarrollo de software y ahorra mucho tiempo, pero estos componentes también son creados por personas y, por lo tanto, algunos de ellos contienen inevitablemente vulnerabilidades. Es decir, pueden quedar expuestos a vulnerabilidades que pueden ser explotadas sin que ellos lo sepan.
Mantener los componentes actualizados
Por lo general, es recomendable mantener actualizados periódicamente los marcos, bibliotecas y otros componentes. Esto se puede hacer de varias maneras, como las siguientes:
- Muchos programas de control de código fuente pueden analizar repositorios y alertar si se detectan vulnerabilidades en las dependencias.
- Muchos gestores de paquetes pueden analizar aplicaciones e identificar las vulnerabilidades que pueden tener los usuarios.
- Existen numerosas soluciones de análisis de la composición del software (SCA) que permiten identificar las vulnerabilidades de las dependencias.
Mitigación del riesgo de la deuda tecnológica
Uno de los problemas más sutiles de la actualización de bibliotecas es que puede haber cambios que rompan el código. Aunque estos cambios suelen estar documentados, puede haber cambios no documentados que no se detecten hasta que el código se ejecute en un entorno de producción.
Si la aplicación ejecuta varias versiones anteriores a la última, la actualización a la última versión puede requerir una cantidad considerable de trabajo. Cuando se detecta una vulnerabilidad urgente, es importante mantener los componentes de terceros relativamente actualizados para evitar situaciones en las que la actualización lleve varios días.
Además, aunque no quede claro, el paquete puede contener información importante sobre cambios que pueden afectar al funcionamiento de la aplicación, por lo que no se recomienda actualizar el paquete sin leer las notas de la versión.
¿No sería más seguro actualizar?
Aunque no es muy frecuente, pueden darse los siguientes casos de vulnerabilidad.
- No existe en versiones anteriores.
- Se introducirá cuando se corrija la vulnerabilidad.
En estos casos, se podría pensar que no es realmente conveniente actualizar los paquetes con regularidad. Por supuesto, esta idea conduce a la acumulación de deuda técnica, por lo que debe evitarse en la medida de lo posible.
Este escenario es relativamente poco frecuente, por lo que las ventajas que se obtienen al actualizar el paquete con frecuencia son mucho mayores que la posibilidad de que se introduzcan nuevas vulnerabilidades. Si se mantiene actualizado periódicamente, será fácil mitigarlas en cualquier caso.
Además, se parte del supuesto de que los proveedores no corrigen silenciosamente las vulnerabilidades sin hacerlas públicas. Lamentablemente, esto sigue siendo muy habitual.
Ejemplos destacados
A continuación se enumeran algunos ejemplos destacados que es posible que haya escuchado recientemente. Podrá comprender por qué es importante revisar la biblioteca y mantenerse al día.