3 parámetros para medir las pruebas SAST

En nuestro blog anterior sobre por qué no puedes comparar herramientas SAST usando solo listas, suites de pruebas y benchmarks, analizamos las distintas herramientas y métricas que se usan habitualmente para evaluar y comparar herramientas de pruebas SAST. También vimos algunas razones por las que esas herramientas pueden arrojar resultados inconsistentes y no ser confiables para evaluar una herramienta de pruebas SAST.

En cambio, al evaluar una herramienta de pruebas SAST, debes tener en cuenta 3 parámetros:

• precisión

• completitud

• otros valores únicos

En este blog, analizaremos esos parámetros y veremos cómo medirlos. Al evaluar una herramienta de pruebas SAST, hay dos tipos de mediciones relevantes: cuantitativas (es decir, la cantidad de resultados frente al «ruido») y cualitativas (en concreto, la profundidad y la cobertura de los lenguajes).

Aspectos cuantitativos

Al principio, las siguientes definiciones de precisión y completitud pueden parecer algo complejas, porque en realidad son dos caras de la misma moneda. Es matemáticamente imposible (según el teorema de Rice) lograr un análisis estático de programas perfecto. Podrías pensar que aumentar la cantidad de sugerencias permitiría encontrar todos los problemas posibles. Lamentablemente, esto también aumenta la cantidad de falsos positivos (FP) hasta un nivel en el que el ruido hace que los resultados sean imposibles de usar. Los proveedores de pruebas SAST pueden aplicar algunos trucos para mejorar los resultados, pero alcanzar la perfección es matemáticamente imposible.

Precisión

En el contexto de las pruebas SAST, la precisión se define, a grandes rasgos, como la mayor cantidad posible de VP (verdaderos positivos, hallazgos que corresponden a problemas reales) y la menor cantidad posible de FP (hallazgos que no son vulnerabilidades y, por lo tanto, son incorrectos).

La precisión es especialmente importante. Una tasa de precisión alta significa que obtenemos más resultados útiles y menos «ruido» (informes irrelevantes que no permiten tomar medidas). El «ruido» también es el principal factor que disuade a los desarrolladores de usar productos de pruebas SAST. Por eso, cuanto mayor sea la precisión, mejor será la experiencia general de desarrollo.

Para calcular la precisión, primero debes clasificar los resultados. La fórmula es TP*100/(TP+FP). El resultado será un número entre 1 y 100. Cuanto más alto sea el número, mayor será la precisión. Por ejemplo, una herramienta que encuentra 140 VP y 40 FP tendría una tasa de precisión del 77,7 %.

Completitud

NIST define la «completitud, a veces denominada tasa de recall, como una medida de los problemas reales encontrados (VP) frente a todos los problemas posibles (VP y falsos negativos). Cuanto mayor sea la completitud (hasta su máximo teórico de 1), mejor cubrirá la herramienta los problemas existentes en el código». En términos prácticos: la cantidad de problemas reales que no se detectaron, es decir, los falsos negativos (FN).

Cuanto más completa sea la herramienta, mejor será tu visibilidad y protección. Esto también puede traducirse en más hallazgos, por supuesto, pero si la tasa de precisión es alta, la mayoría deberían ser relevantes. Dicho esto, la gravedad de esos hallazgos siempre influye en la completitud: mil FN de baja gravedad no son necesariamente algo malo si intentas minimizar el ruido. Como regla general, cuantos menos FN, mejor. Y es importante saber cómo reducirlos para no pasar por alto las vulnerabilidades reales.

Esta métrica solo se puede generar si conoces alguna vulnerabilidad en tu código o si comparas varias herramientas y detectas diferencias en los hallazgos. Otra opción es analizar la gravedad de los FN y enfocarte primero en los de mayor prioridad. Es difícil medir los FN porque son incógnitas desconocidas. Es inevitable tener que hacer concesiones. La experiencia demuestra que siempre hay que esperar FN en proyectos complejos. En ciberseguridad, nunca es una opción bajar la guardia por sentirse demasiado seguro.

El aspecto cualitativo

La medición cualitativa analiza cómo se aborda la cobertura de lenguajes y vulnerabilidades. Como vimos en el blog anterior, limitarse a las listas de vulnerabilidades conocidas, las suites de pruebas y los repositorios con vulnerabilidades intencionales ofrece una visión incompleta. Por eso, una buena herramienta SAST va más allá de las listas.

Esta medición se puede dividir en dos áreas de interés: la cobertura de lenguajes y vulnerabilidades, y el enfoque respecto a la profundidad y la precisión.

¿Cómo se determina la cobertura de lenguajes?

Es importante entender cómo se prioriza y determina la cobertura de lenguajes de la herramienta SAST que estás evaluando.

Ya sabemos que las listas de vulnerabilidades no son suficientes. Un enfoque más integral consistiría en reunir datos de varias fuentes para ofrecer una cobertura sólida de lenguajes, actualizada frente a los riesgos cibernéticos actuales y relevante según el contexto.

Así que, aunque las listas pueden servir como referencia, hay otras fuentes que conviene explorar:

• Fuentes de noticias: es más probable que se exploten las vulnerabilidades que son tendencia y los vectores recién publicados.

• Bases de datos de vulnerabilidades conocidas y datos de exploits, como NVD Database y Snyk Vulnerability Database.

• Mejores prácticas y contexto específicos de cada lenguaje y framework

• Investigación sobre vulnerabilidades de día cero, como patrones nuevos o existentes

Para determinar qué lenguajes y frameworks admitir en Snyk Code, usamos todo lo anterior y más para elaborar una lista de los problemas más relevantes que deberían interesarles a los clientes.

¿Cómo se abordan la profundidad y la precisión de la cobertura de lenguajes?

Contar con una lista sólida de lenguajes y vulnerabilidades compatibles es un primer paso importante, pero también debes considerar qué tan bien se traduce esa cobertura en resultados.

Por ejemplo, una herramienta SAST que depende de la comunidad de código abierto para crear e incorporar reglas nuevas con poca o ninguna revisión estricta es propensa a generar muchos FP y, con frecuencia, arroja resultados inconsistentes entre diferentes lenguajes y vulnerabilidades.

En Snyk Code, contamos con un equipo de investigadores de seguridad dedicados que trabaja constantemente para ampliar la cobertura de lenguajes y vulnerabilidades, además de mejorar la cobertura existente con mayor profundidad y precisión.

¿Cuál es la velocidad de desarrollo y mantenimiento de la herramienta SAST?

Como se indicó anteriormente, el mantenimiento y el desarrollo continuo de una solución SAST son importantes. Esto abarca dos áreas: la hoja de ruta del producto y la capacidad de la empresa o comunidad para cumplirla. Los avances recientes en aprendizaje automático hacen interesante analizar cómo influye en esa hoja de ruta. También son clave la compatibilidad con lenguajes modernos, el uso de un motor moderno y la velocidad con la que se agregan nuevos lenguajes.

En segundo lugar, es importante entender qué capacidad tiene una empresa o comunidad para mantener la base de conocimientos de SAST. Como se mencionó anteriormente, la seguridad requiere observación constante y capacidad de responder a distintas fuentes.

En resumen

Con la evaluación cuantitativa, ahora querrás entender cómo se comporta realmente la herramienta en condiciones reales. No basta con contar con la mejor cobertura de lenguajes y vulnerabilidades si la herramienta genera muchos resultados (aunque sean VP) o, por el contrario, mucho ruido (FP). Un profesional de seguridad busca un alto nivel de completitud, pero a los desarrolladores les interesan más los consejos prácticos que les permitan actuar. Por eso, es importante equilibrar la cantidad de sugerencias, su priorización y la capacidad del equipo de desarrollo para resolverlas. Nuestra experiencia e investigación demuestran que abrumar a los desarrolladores con sugerencias (sobre todo si la precisión es baja) los desmotiva y, de hecho, ralentiza el proceso.

Desde una perspectiva cualitativa, recomendamos hacer una lista de los aspectos relevantes para tu entorno, crear una matriz e ingresar los valores de cada competidor.

Para medir las características cuantitativas, recomendamos elegir proyectos reales que conozcas. Para mayor comodidad, procura que el proyecto sea pequeño o mediano. Como se mencionó en el blog anterior, evita usar una aplicación con vulnerabilidades intencionales, ya que es probable que no represente el valor real de la herramienta.

Después de ejecutar la herramienta SAST y recibir los resultados, es hora de clasificarlos. Clasificar significa determinar si un resultado es un VP (un problema real) o un FP (un problema que no es real). Los resultados de SAST suelen depender del contexto, por lo que es importante conocer bien el proyecto que estás analizando. En definitiva, tu experiencia y tu trabajo no se pueden reemplazar con resultados de benchmarks preconfigurados.

Por último, tendrás que calcular la precisión y la completitud con las fórmulas mencionadas anteriormente en esta publicación.

¿Por qué no recopilar todas las herramientas y ejecutarlas?

Como se indicó anteriormente, todas las herramientas agregan VP y FP. Así que, aunque parezca lógico usar todas las herramientas posibles, en realidad, el trabajo de filtrar el ruido supera el valor que aporta otra herramienta. Los desarrolladores tendrán que revisar sugerencias duplicadas de distintas herramientas y en diferentes formatos, lo que genera mucho trabajo adicional, además de limitaciones en el tiempo de ejecución. Aunque esta es una buena forma de obtener cifras de FN y FP, no es viable para las operaciones continuas. Según nuestra experiencia, lo más importante es contar con una plataforma fácil de usar para los desarrolladores. Si trabajas en un entorno muy crítico para la seguridad o regulado, quizá te convenga agregar herramientas especializadas más adelante en el proceso de CI/CD.

Sin duda, SAST es una herramienta poderosa que todo desarrollador debería tener en su «caja de herramientas» y que puede marcar una gran diferencia en la seguridad de tus aplicaciones. Por eso, es fundamental elegir la herramienta más adecuada para ti y tu organización. Esperamos que la información y los pasos descritos anteriormente y en la publicación anterior te ayuden a tomar decisiones más informadas.