Criterios para evaluar herramientas de análisis estático

Estas son las cosas en mi lista, que uso para mis clientes (incluyendo algunas de las que mencioné):

• Cobertura (según lo que la organización requiere hoy y espera utilizar en el futuro)
  • idioma
  • Arquitectura (por ejemplo, algunas herramientas son excelentes para aplicaciones web, pero no tanto para clientes ricos o incluso para servicios / daemons de Windows)
  • Framework (por ejemplo, soporte para ASP.NET pero no MVC, o Java pero no Spring)
  • Bibliotecas estándar (por ejemplo, reconociendo Hibernate, log4j o AntiXSS, por nombrar algunas problemáticas) según sea necesario
• Rendimiento de escaneo . En esto incluyo tanto:
  • velocidad
  • Escalabilidad a grandes bases de código (incluidos LoC, subsistemas / proyectos y referencias externas)
• Integridad : es decir, las reglas / scripts incluidos en el análisis, lo suficiente como para proporcionar confianza en la salida, o en otras palabras para minimizar los falsos negativos.
  • Tenga en cuenta que esta es la lista de las reglas proporcionadas (por ejemplo, verifica la "Inyección de SQL");
  • Y la calidad de esas comprobaciones, es decir, en realidad capturar Inyecciones de SQL. (Como ejemplo, un cierto líder en el campo, que permanecerá sin nombre, puede ser confundido fácilmente por muchas formas de flujo de código, por lo que faltan fallas en la inyección básica).
• Precisión de los resultados . Esto se aplica a los resultados que se informan (a diferencia de los que faltan, cubiertos en "Integridad"). La pobre precisión se puede ver en:
  • Altos números de falsos positivos
  • duplicados
  • categorías erróneas
  • Misprioritizaciones (por ejemplo, etiquetar un error de muy bajo impacto como "Alto riesgo")
  • Resultados irrelevantes (es decir, una falla de código que es precisa , pero completamente irrelevante para la aplicación o arquitectura; por ejemplo, encontrar XSS en una aplicación no HTML, no HTTP y no interactiva, o Inyección de SQL en una aplicación cliente).
• Personalización : como ha dicho, personalice las fuentes, los sumideros y los filtros; tambien reporta; pero también, no menos, personalizando reglas / scripts y agregando lógica personalizada (no solo fuente- > filter- > sink). Tenga en cuenta que muchas herramientas le permiten "personalizar" sus reglas, pero esto está realmente limitado solo a agregar fuente / sumidero / filtros.
• Sostenibilidad / repetibilidad : con esto me refiero al manejo de los análisis repetidos. ¿Cómo maneja los cambios? ¿Problemas previamente marcados como falsos positivos? ¿Obtengo comparaciones?
• Modelo de implementación , por ejemplo, usualmente combinación de:
  • estación auditora única
  • servidor compartido, accedido vía remoto
  • acceso web
  • complemento para desarrolladores
  • construir la conectividad del servidor
  • (y, por supuesto, la capacidad de establecer una política diferente para cada uno)
• Usabilidad . Esto incluye:
  • UI (incluidas las teclas de acceso rápido, etc.)
  • capacidades de filtrado del auditor
  • proporcionando suficiente contexto resaltando lo suficiente del flujo de código
  • texto estático, como explicaciones, descripciones, remediación, enlaces a fuentes externas, identificaciones en OWASP / CWE, etc.
  • funciones de usuario adicionales, por ejemplo, ¿Puedo agregar un resultado manual (no encontrado por escaneo automático)?
• Informes : tanto flexibles según el proyecto según sea necesario (no olvide los detalles para desarrolladores y de alto nivel para gerentes) y proyectos cruzados agregados. También comparaciones, etc. etc.
• Seguridad (en el caso de un modelo de servidor): protege los datos, la administración de permisos, etc. (como cualquier aplicación de servidor ...)
• Coste . Esto incluye al menos:
  • hardware
  • licencia - cualquiera o todas de las siguientes:
    • por asiento - auditor
    • por asiento - desarrollador
    • por asiento: usuario de informes
    • por servidor
    • por proyecto
    • por líneas de código
    • licencia de sitio
  • mantenimiento
  • servicios, por ejemplo, implementación, ajuste, integración personalizada, etc.
  • capacitación (tanto para el capacitador como para el auditor / tiempo de desarrollo)
• Integración con:
  • control de fuente
  • bug tracker
  • entorno de desarrollo (IDE)
  • construir servidor / CI / CD
  • automatización

Al analizar esto, creo que está más o menos en orden de preferencia: desde los requisitos básicos, a la aplicabilidad, a la calidad, a la facilidad de implementación, a la eficiencia, a lo bueno para tener ...

Aquí es lo más importante que debe saber acerca de cómo evaluar una herramienta de análisis estático:

Inténtalo en tu propio código.

Repetiré eso otra vez. Pruébalo en tu propio código. Debe ejecutar una prueba, donde la usa para analizar algunos de sus códigos representativos y luego analizar su salida.

La razón es que las herramientas de análisis estático varían significativamente en efectividad, y su efectividad depende del tipo de código que se escriba en su empresa. Por lo tanto, es posible que la herramienta que mejor se adapte a su empresa no sea la misma que la mejor para otra compañía en el futuro.

No puedes ir por una lista de características. El hecho de que una herramienta diga que es compatible con Java no significa que sea bueno para analizar el código Java, o que sea bueno para analizar su código Java y encontrar problemas que le interesen.

La mayoría de los proveedores de análisis estático con gusto lo ayudarán a configurar una versión de prueba gratuita para que pueda probar su herramienta en su propio código, así que aproveche su oferta.

Gary McGraw y John Steven han escrito un buen artículo sobre cómo elegir una herramienta de análisis de seguridad estática . Además de llegar al punto en que necesita probar las herramientas en su propio código para ver cuál es el mejor, también señalan que debe tener en cuenta qué tan bien puede personalizarse la herramienta para su entorno y sus necesidades, y el presupuesto para ello. costo.

Es probable que una larga lista de criterios lo distraiga como ayuda para encontrar una buena solución.

Tomemos, por ejemplo, el tema de los "falsos positivos". Es un problema inherente con tales herramientas. La solución a largo plazo es aprender a vivir con ellos. Esto significa que sus programadores tendrán que aprender a codificar alrededor de la herramienta de análisis estático, aprender qué causa que active un falso positivo y escribir el código de una manera diferente para que el falso positivo no se active. Es una técnica familiarizada con aquellos que usan pelusa, o aquellos que intentan compilar su código de manera gratuita: modificas el código hasta que el falso positivo deja de activarse.

El criterio más importante es entender el problema que estás tratando de resolver. Hay una enorme ventaja en hacer que sus programadores pasen el paso de ejecutar un analizador estático una vez, para eliminar los problemas más grandes en su código y aprender francamente lo que ya deberían saber sobre programación y no cometer esos errores. Pero el valor marginal de la ejecución continua de analizadores estáticos es mucho menor, y el costo marginal es mucho mayor.

A lo largo de los años, he sido un gran fanático de PC-Lint de Gimpel para el código C ++. Los dos factores más importantes para mí fueron la cobertura lingüística (en realidad, nadie más la tenía) y la "habitabilidad". Vivir con análisis estático es algo subjetivo, como saben. Gimpel tiene un capítulo en su manual llamado "Living with Lint" que hace un buen trabajo hablando a través de los altos y bajos. Hacerlo habitable implica tener la capacidad de personalizar las advertencias y los errores que se emiten, pero de una manera que no hace que los desarrolladores se vuelvan locos al trabajar con ellos.

En relación con la escalabilidad, he tenido problemas con las herramientas de análisis al no poder manejar el código de terceros (bibliotecas, etc.), por lo que en un gran proyecto, eso también es una consideración importante.