Utilización de componentes que presentan vulnerabilidades conocidas
La mayoría de las aplicaciones utilizan grandes cantidades de componentes de terceros. Estos componentes proporcionan todo, desde el registro hasta la creación de modelos, pasando por el acceso a la base de datos, etc.
Esto facilita enormemente el desarrollo de software y permite ahorrar mucho tiempo. Sin embargo, estos componentes también son fabricados por personas y algunos inevitablemente contendrán vulnerabilidades. Esto significa que usted podría estar expuesto sin saberlo a vulnerabilidades que podrían ser explotadas.
Mantenimiento actualizado de los componentes
Por regla general, se recomienda encarecidamente actualizar periódicamente los marcos, bibliotecas y otros componentes. Esto se puede hacer de diferentes maneras:
- Muchos programas de control de código fuente pueden analizar sus repositorios y avisarle cuando se descubre una vulnerabilidad en una dependencia.
- Muchos gestores de paquetes pueden analizar su aplicación e identificar las dependencias vulnerables que pueda tener.
- Existen numerosas soluciones de análisis de la composición del software (SCA) que permiten identificar cualquier dependencia vulnerable.
Reducir el riesgo de deuda técnica
Un problema bastante insidioso relacionado con la actualización de las bibliotecas es que pueden sufrir modificaciones en el código. Aunque estas modificaciones suelen estar documentadas, algunas modificaciones no documentadas pueden no aparecer hasta que el código se ejecute en producción.
Si su aplicación ejecuta numerosas versiones anteriores a la más reciente, la actualización a la última versión puede requerir mucho trabajo. En caso de que se revele una vulnerabilidad sensible al factor tiempo, es esencial que esté relativamente al día en lo que respecta a los componentes de terceros para evitar que la actualización lleve días.
También se desaconseja actualizar paquetes a ciegas sin leer al menos las notas de la versión, ya que pueden contener información importante sobre cambios que no son evidentes pero que podrían modificar el funcionamiento de su aplicación.
¿Podría la actualización hacer que su situación sea más precaria?
Aunque no es habitual, ha ocurrido que una vulnerabilidad puede:
- No existe en las versiones anteriores.
- Ser presentado durante la corrección de una vulnerabilidad.
Estos casos pueden llevar a pensar que la actualización regular de los paquetes no es realmente deseable. Por supuesto, esta forma de pensar debe evitarse en la medida de lo posible, ya que conduce a la acumulación de deuda técnica.
Teniendo en cuenta la relativa rareza de este escenario, las ventajas de las actualizaciones frecuentes de los paquetes superan con creces la posibilidad de una vulnerabilidad recientemente introducida, que en cualquier caso debería mitigarse fácilmente si se mantiene al día regularmente.
También parte del principio de que los proveedores no corrigen silenciosamente las vulnerabilidades sin divulgarlas, lo que, lamentablemente, sigue siendo muy habitual.
Ejemplos destacados
Aquí hay algunos ejemplos notables de los que probablemente haya oído hablar recientemente. Puede ver cómo y por qué es importante consultar sus bibliotecas y asegurarse de mantenerse al día.