Uso de componentes con vulnerabilidades conocidas

La mayoría de las aplicaciones utilizan una gran cantidad de componentes de terceros. Estos componentes proporcionan de todo, desde registro, plantillas y acceso a bases de datos, entre otras funciones.

Esto facilita enormemente el desarrollo de software y ahorra mucho tiempo; sin embargo, estos componentes también son creados por personas y, inevitablemente, algunos contendrán vulnerabilidades. Esto significa que podría estar expuesto sin saberlo a vulnerabilidades que podrían ser explotadas.

Mantener los componentes actualizados

Como regla general, se recomienda encarecidamente mantener actualizados los marcos de trabajo, las bibliotecas y otros componentes de forma regular. Esto se puede hacer de varias maneras:

• Muchos programas de control de versiones pueden analizar sus repositorios y alertarle cuando se encuentra una vulnerabilidad en una dependencia
• Muchos gestores de paquetes pueden analizar su aplicación e identificar cualquier dependencia vulnerable que pueda tener
• Existen numerosas soluciones de Análisis de Composición de Software (SCA) que pueden identificar cualquier dependencia vulnerable

Mitigar el riesgo de la deuda técnica

Un problema bastante insidioso de actualizar las bibliotecas es que pueden incluir cambios que rompan el código. Aunque a menudo están documentados, también puede haber cambios no documentados que quizás no aparezcan hasta que su código esté ejecutándose en producción.

Si su aplicación tiene muchas versiones de retraso respecto a la más actual, es posible que se requiera una cantidad significativa de trabajo para actualizar a la última versión. En caso de que se divulgue una vulnerabilidad urgente, es fundamental estar relativamente al día con los componentes de terceros para evitar una situación en la que la actualización lleve días de trabajo.

Tampoco se recomienda actualizar paquetes a ciegas sin al menos leer las notas de la versión, ya que pueden contener información importante sobre cambios que no son evidentes pero que podrían alterar el funcionamiento de su aplicación.

¿Podría la actualización hacerlo menos seguro?

Aunque no es común, ha habido casos en los que una vulnerabilidad puede:

• No existir en versiones anteriores
• Introducirse al corregir otra vulnerabilidad

Estos casos pueden llevar a pensar que actualizar los paquetes de forma regular no es realmente deseable. Por supuesto, este razonamiento debe evitarse siempre que sea posible, ya que conduce a la acumulación de deuda técnica.

Dada la relativa rareza de este escenario, los beneficios de actualizar los paquetes con frecuencia superan con creces la posibilidad de una vulnerabilidad recién introducida, la cual debería ser fácil de mitigar de todos modos si se mantiene al día de forma regular.

Esto también parte de la suposición de que los proveedores no corrigen vulnerabilidades silenciosamente sin ninguna divulgación, lo cual, lamentablemente, sigue siendo muy común.

Ejemplos notables

A continuación, se enumeran algunos ejemplos notables de los que probablemente haya oído hablar en los últimos tiempos. Puede ver cómo y por qué es importante revisar sus bibliotecas y asegurarse de mantenerse actualizado.

• Heartbleed
• Struts2
• Log4j

‍