Ayudar a los desarrolladores a priorizar el backlog de seguridad

Hoy, cada vez más desarrolladores están dando un paso al frente para corregir las vulnerabilidades de sus aplicaciones, lo cual es excelente. Sin embargo, al hacerlo, se enfrentan a un largo backlog de vulnerabilidades. Decidir qué problema resolver primero es difícil y requiere tiempo y experiencia en seguridad que a menudo no tienen. Esta es una oportunidad para que las herramientas adecuadas se destaquen: pueden aportar la experiencia necesaria para saber qué preguntas de seguridad hacer al priorizar y la tecnología para responderlas rápidamente.

Cómo hacer frente a la sobrecarga de vulnerabilidades

La cantidad de vulnerabilidades en los componentes de código abierto aumenta constantemente: cada año se divulgan miles de vulnerabilidades nuevas. Para ponerlo en perspectiva, basta con considerar que la Snyk Vulnerability Database ha aumentado un 394 % en total durante los últimos cuatro años. Estas cifras, que no dejan de crecer, se reflejan en los backlogs de vulnerabilidades que enfrentan hoy las organizaciones.

Con recursos ya limitados y bajo la presión constante de entregar código funcional y seguro de forma rápida y frecuente para ayudar a que sus empresas sigan siendo competitivas, los desarrolladores solo pueden hacer frente a estos backlogs si priorizan bien. Como no pueden corregir de manera realista todas las vulnerabilidades de la lista, los equipos de desarrollo deben decidir cuáles ofrecen el mejor rendimiento por el tiempo invertido.

Estas decisiones pueden tener un gran impacto en los esfuerzos de una organización por gestionar y reducir el riesgo. Una mala priorización puede destinar tiempo de desarrollo a vulnerabilidades que resultan ser falsos positivos, lo que genera fricción y reduce la confianza de los desarrolladores. Priorizar una vulnerabilidad de gravedad alta sin exploits conocidos por encima de una vulnerabilidad de gravedad baja con un exploit activo podría debilitar la postura de seguridad general de la organización.

Saber hacer las preguntas correctas

Una priorización eficaz requiere experiencia: experiencia en seguridad que garantice una evaluación precisa y profunda de la amenaza que la vulnerabilidad representa para la organización. Por lo general, los desarrolladores no cuentan con esa experiencia, lo que dificulta que prioricen el riesgo adecuadamente.

Por eso, las herramientas de seguridad eficaces deben aportar esta experiencia que falta y plantear las preguntas correctas en el momento indicado. Los profesionales de seguridad pueden ajustar estas preguntas y ampliarlas mediante el producto.

Cómo establecer bien las prioridades

La primera pregunta que los desarrolladores deben poder hacer parece sencilla: ¿qué problema del backlog deberían resolver a continuación?

CVSS se diseñó precisamente para este fin, pero presenta varios desafíos. Calcular una puntuación basada en CVSS requiere conocimientos de seguridad. Incluso cuando se proporciona la puntuación lista para usar, entender cómo se obtuvo requiere conocimientos y, a veces, investigación adicional. Además, la gravedad de una vulnerabilidad no es el único factor para decidir qué problema resolver primero.

Por lo general, los desarrolladores no tienen la experiencia en seguridad necesaria para entender los matices de CVSS. Tampoco pueden dedicar tiempo a investigar por qué una vulnerabilidad recibió cierto nivel de gravedad. Para ayudar a los desarrolladores a establecer prioridades, la puntuación debe ser explícita y fácil de usar. Por ejemplo, Snyk considera la gravedad, la disponibilidad de una corrección, la madurez del exploit y la antigüedad de la vulnerabilidad para calcular su puntuación de prioridad. Luego, presenta la puntuación de una manera fácil de entender y usar para los desarrolladores.

La diferencia entre lo importante y lo urgente

Una vez establecidas las prioridades, hay que hacer otra pregunta: ¿qué problemas son más urgentes que otros?

Por ejemplo, las vulnerabilidades con exploits activos deberían tener una prioridad alta y considerarse lo bastante urgentes como para requerir atención inmediata. La famosa brecha de Equifax se originó a partir de una vulnerabilidad conocida para la que se habían publicado exploits activos apenas unos días antes del ataque. 

Saber si una vulnerabilidad puede explotarse es solo una parte de la solución. Sí, esto indica la probabilidad de que se explote, pero, al igual que las vulnerabilidades en general, no todos los exploits son iguales. Algunos son solo teóricos y nunca se han convertido en armas. Otros son mucho más maduros y tienen código de exploit publicado.  Los exploits maduros reducen las barreras para los atacantes, por lo que más atacantes intentan usarlos. Y, lo que es aún más importante, se agregan rápidamente a botnets automatizadas que rastrean constantemente la web en busca de debilidades fáciles de explotar, sin importar quién sea la víctima. Si dejas abierto un hueco así, es probable que estas botnets lo encuentren rápidamente.

Cuando se enfrentan a un backlog enorme de vulnerabilidades, los desarrolladores deben poder identificar rápidamente aquellas cuyos exploits son fáciles de encontrar y convertir en armas. Con esta información, decidir si deben priorizar una vulnerabilidad resulta mucho más fácil.

Corregir con el contexto adecuado

Una vulnerabilidad conocida puede tener un exploit, pero eso no significa que pueda explotarse en tu aplicación. La posibilidad de explotar una vulnerabilidad en tu aplicación depende de cómo interactúan tu código y las demás bibliotecas que usas con el componente vulnerable.

Sin embargo, obtener este contexto requiere no solo experiencia en seguridad, sino también capacidades de análisis. Los desarrolladores rara vez tienen acceso a estos dos recursos y tampoco disponen del tiempo para desarrollarlos por su cuenta.  Las herramientas con estas capacidades integradas ayudan a los desarrolladores a determinar si un método vulnerable está realmente incluido en la ruta de ejecución de una aplicación y a priorizar en consecuencia.

Por ejemplo, Snyk analiza previamente todos los componentes del entorno del usuario y puede monitorear la aplicación en ejecución, todo para ayudar a los desarrolladores a determinar la reachability de la vulnerabilidad desde la aplicación.

Menos obstáculos. Más protecciones.

Se pide a los desarrolladores que asuman cada vez más responsabilidades de seguridad, pero solo pueden hacerlo si saben que están dedicando su tiempo y recursos a las vulnerabilidades adecuadas. Una buena priorización también ayudará a reducir la fricción entre los desarrolladores y los equipos de seguridad: cuanto menos falsos positivos aparezcan en la lista de problemas que deben corregirse de inmediato, más confiarán los desarrolladores en el proceso.

Por su parte, los equipos de seguridad deben asegurarse de que los desarrolladores puedan priorizar de forma segura. Al proporcionarles protecciones, los equipos de seguridad pueden tener la tranquilidad de que las decisiones se toman dentro de límites seguros. Los equipos de seguridad deben establecer estas protecciones con la ayuda de políticas lo bastante detalladas como para permitir la gobernanza a escala. Cuanto más automatizadas sean estas políticas, mejor.  

Para ayudar a los desarrolladores a hacer las preguntas adecuadas y priorizar eficazmente, Snyk ofrece capacidades de priorización diseñadas primero para desarrolladores, que proponen las preguntas, encuentran las respuestas y simplifican las tareas de corrección posteriores. Descubre más aquí o empieza ahora gratis.