En términos generales, la afirmación «ignore las vulnerabilidades» no es algo que uno espere oír de una empresa de seguridad. Al fin y al cabo, las vulnerabilidades son responsables de brechas de tal magnitud que llenan nuestros canales durante meses de comentarios, análisis y recomendaciones posteriores al incidente.
Y desde luego, no es habitual ver «ignorar las vulnerabilidades» asociado a la idea de «mejorar la seguridad».
Ahora sí, aunque, como ocurre con la mayoría de los consejos, hay salvedades y matices.
Desde luego, no deberías ignorar todas las vulnerabilidades, pero resulta que hay una categoría de vulnerabilidades que puedes ignorar sin riesgo por ahora, o al menos relegar para más adelante. Descubrí este concepto mientras leía el informe Estado de la gestión de vulnerabilidades de código abierto en 2018 de WhiteSource Software.
Además de algunas estadísticas muy interesantes, el informe plantea que las vulnerabilidades del software de código abierto pueden agruparse en dos categorías: ineficaces y eficaces.
La premisa de la clasificación de WhiteSource es que algunas vulnerabilidades son ineficaces, es decir, no se pueden explotar porque el código personalizado no las invoca. Según este planteamiento, poder analizarlas y diferenciarlas permite a los equipos de seguridad y a los desarrolladores centrarse en las vulnerabilidades consideradas eficaces y, de este modo, reducir el tiempo y el esfuerzo necesarios, al tiempo que se mejora la seguridad general de la aplicación.
Por ejemplo, pensemos en una aplicación personalizada que depende de un componente de código abierto que contiene una función vulnerable. Según la definición de White Source, la función vulnerable de este ejemplo podría declararse «ineficaz» porque la aplicación personalizada nunca la invoca. Los lectores más perspicaces observarán que la función vulnerable podría ser invocada por una función de un componente de código abierto (ya sea otro componente o el mismo), lo que la convertiría en eficaz. Cuando pregunté a WhiteSource sobre esta posibilidad, ampliaron su clasificación y señalaron que sí se tiene en cuenta. Si el código vulnerable se invoca desde código personalizado o indirectamente a través de otro componente de código abierto, se etiqueta como «eficaz». Por el contrario, si no existe ninguna ruta —directa o indirecta— que invoque la función vulnerable, 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 también que el 7,5 % de todos los proyectos son vulnerables, poder priorizar las vulnerabilidades en las que centrarse sería sin duda una gran ventaja. WhiteSource también determinó que nada menos que el 64 % de los productos de código abierto contenían únicamente vulnerabilidades ineficaces que, según sostienen, pueden ignorarse sin riesgo.
Ahora bien, aunque no estoy convencido de que debamos ignorar alegremente las vulnerabilidades de cualquier código solo porque no se ejecuten activamente, sí considero útil esta distinción para priorizar la gestión de vulnerabilidades. Al centrarse en el código vulnerable que sí se ejecuta activamente, los desarrolladores y los profesionales de la seguridad pueden mejorar de inmediato la seguridad general de una aplicación. Esto permite aprovechar mejor a los desarrolladores sénior, quienes, según el informe de White Source, dedican de media más tiempo que los desarrolladores júnior a corregir vulnerabilidades.
Es necesario establecer algún tipo de método de priorización. WhiteSource afirmó que en 2017 se notificaron cerca de 3500 vulnerabilidades, lo que supone un aumento del 60 % con respecto a 2016. No todas esas 3500 vulnerabilidades notificadas afectan a todas las aplicaciones u organizaciones, pero debemos recordar que estas cifras son acumulativas. Es decir, las 3500 son vulnerabilidades nuevas que se añaden a un total acumulado.
No hace falta decir que existen muchas vulnerabilidades en el código, tanto en el desarrollado a medida como en el de código abierto. Poder priorizar la corrección en función de si son «efectivas» o «inefectivas» está en consonancia con las estrategias de seguridad emergentes, que evalúan el riesgo basándose en la amenaza existencial, además de en otros factores. La amenaza existencial de una vulnerabilidad inefectiva es prácticamente inexistente. Dicho esto, ignorar las vulnerabilidades inefectivas puede no ser el mejor enfoque a largo plazo. Es posible que, con el tiempo, dichas vulnerabilidades se vuelvan efectivas. Los cambios en el código desarrollado a medida a medida que se añaden o mejoran funcionalidades, así como los cambios que experimentan con el tiempo los componentes de código abierto, pueden abrir 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 orientado a detectar vulnerabilidades debería realizarse, en el mejor de los casos, de forma continua y, en el peor, durante la compilación final.
Pero, para cumplir los plazos y aprovechar eficientemente el tiempo de los desarrolladores, relegar las vulnerabilidades «ineficaces» al final de la cola para poder corregir de inmediato las vulnerabilidades «eficaces» podría ser una de las mejores formas de mejorar la seguridad ahora mismo.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.