Mejora de la seguridad ignorando las vulnerabilidades
En términos generales, la afirmación "ignorar vulnerabilidades" no es algo que uno espera escuchar de una empresa de seguridad. Después de todo, las vulnerabilidades son responsables de infracciones de tal magnitud que llenan nuestros feeds durante meses con comentarios, análisis y recomendaciones post mortem.
Y ciertamente no vemos "ignorar vulnerabilidades" emparejado con la noción de "mejorar la seguridad".
Ahora lo tienes, aunque, como ocurre con la mayoría de los consejos, esto conlleva salvedades y salvedades.
Por supuesto, no deberías ignorar todas las vulnerabilidades, pero resulta que hay una clase de vulnerabilidades que puedes ignorar con seguridad ahora mismo, o al menos quitarles prioridad para un día lluvioso. Me topé con este concepto mientras leía el Estado de la gestión de vulnerabilidades de código abierto de 2018 de WhiteSource Software .
Además de algunas estadísticas muy interesantes, el documento plantea la idea de que las vulnerabilidades de código abierto pueden agruparse en dos categorías: ineficaces y efectivas.
La premisa de la categorización de WhiteSource es que algunas vulnerabilidades son ineficaces, es decir, no son explotables porque no son invocadas por código personalizado. Poder analizar y diferenciar, según cuenta la historia, significa que la seguridad y los desarrolladores pueden centrarse en aquellas vulnerabilidades que se consideran efectivas y, de ese modo, reducir el tiempo y el esfuerzo al tiempo que mejoran la seguridad general de la aplicação.
Por ejemplo, considere una aplicaciones personalizadas que se basa en un componente de código abierto que contiene una función vulnerable. Según la definición de White Source, la función vulnerable en este ejemplo podría declararse "ineficaz" porque la aplicaciones personalizadas nunca la invoca. Los lectores astutos notarán que la función vulnerable podría ser invocada por una función en un componente de código abierto (ya sea otro componente o el mismo) y así hacerla efectiva. Cuando le pregunté a WhiteSource sobre esta posibilidad, ampliaron su categorización señalando que esta posibilidad se toma en consideración. Si el código vulnerable se invoca desde un código personalizado o indirectamente a través de otro componente de código abierto, se etiqueta como "efectivo". Por el contrario, si no existe ninguna ruta -directa o indirecta- que invoque la función vulnerable, ésta se etiqueta como "ineficaz".
Dado que la investigación de WhiteSource determinó no solo que el 96,8% de los desarrolladores dependen de componentes de código abierto, sino que el 7,5% de todos los proyectos son vulnerables, poder priorizar en qué vulnerabilidades centrarse sin duda sería una gran ventaja. WhiteSource determinó además que se encontró que un enorme 64% de los productos de código abierto contenían únicamente vulnerabilidades ineficaces , que según ellos pueden ignorarse con seguridad.
Ahora bien, si bien no estoy convencido de que debamos ignorar alegremente las vulnerabilidades en cualquier código porque no se invocan activamente, veo valor en utilizar dicha distinción para priorizar la gestión de vulnerabilidades. Al centrarse en el código vulnerable que se invoca activamente, los desarrolladores y profesionales de seguridad pueden mejorar de inmediato la seguridad general de una aplicação. Esto permite un mejor uso de los desarrolladores senior, quienes, según el informe de White Source, pasan en promedio más tiempo abordando vulnerabilidades que los desarrolladores junior.
Es necesario implementar algún tipo de método de priorización. WhiteSource afirmó que hubo casi 3500 vulnerabilidades reportadas en 2017, un aumento del 60% respecto de 2016. No todas esas 3500 vulnerabilidades reportadas afectan a todas las aplicação u organizaciones, pero debemos recordar que estos números son acumulativos. Es decir, las 3500 son nuevas vulnerabilidades que se suman a un total acumulado.
No hace falta decir que hay muchas vulnerabilidades en el código, tanto personalizado como de código abierto. Poder priorizar las medidas de remediación en función de si son "eficaces" o "ineficaces" está en consonancia con las estrategias de seguridad emergentes que califican el riesgo en función de la amenaza existencial, además de otros factores. La amenaza existencial de una vulnerabilidad ineficaz es casi inexistente. Dicho esto, ignorar las vulnerabilidades ineficaces puede no ser el mejor enfoque a largo plazo. Es posible que con el tiempo tales vulnerabilidades resulten efectivas. Los cambios en el código personalizado a medida que se agregan y/o mejoran características, así como los cambios a lo largo del tiempo en los componentes de código abierto, pueden generar la apertura de una ruta que invoque una función vulnerable. Esta es una de las razones por las que el análisis del código fuente específicamente para detectar vulnerabilidades debería realizarse de forma continua en el mejor de los casos y, en el peor de los casos, durante la compilación final.
Pero con el objetivo de cumplir con los plazos y usar el tiempo de los desarrolladores de manera eficiente, dejar las vulnerabilidades "ineficaces" al final de la cola para que las "efectivas" puedan repararse inmediatamente podría ser una de las mejores formas en que los desarrolladores pueden mejorar la seguridad en este momento.