Uno de los inconvenientes a la hora de decidirse por el uso de una herramienta de análisis de código estático es cómo evaluarla. El primer acercamiento es siempre el mismo: la que más detecte.
Cuando ya te has estrujado los sesos mediante la arcaica técnica de “a prueba y error” te das cuenta de que la decisión depende completamente de lo que uno espere de la herramienta. Los auditores solemos ponernos en el lado del atacante, por lo que primamos la presencia de falsos positivos para evitar la presencia de falsos negativos. Que la herramienta detecte “todo“. que ya nosotros descartaremos lo que corresponda.

Como todo en la vida, visto en perspectiva se gana en claridad. Cuando entras en ecosistemas de cliente te das cuenta de que en multitud de ocasiones no entienden correctamente la implicación de las vulnerabilidades a pesar de que se les indiquen con exactitud las líneas, ficheros, etc y que aunque sean programadores no van a ser capaces de discernir un falso positivo de una vulnerabilidad real. De todo esto surge una importante duda: ¿cómo actuar?
La respuesta es obvia: hay que ser flexible y permitir una parametrización que haga útil la herramienta a ambos tipos de usuarios. Problema resuelto, ¿o no?

Aún con los criterios definidos tomar la decisión de qué herramienta utilizar sigue siendo complicado. ¿cómo comparo varias herramientas? está claro que en el caso de las OpenSource tengo acceso a las mismas y puedo probar multitud de códigos con ellas, aún así salvo que tenga un análisis manual con qué comparar no puedo establecer un marco técnico unificado, y además extrapolar resultados de un puñado de códigos concretos no aporta una visibilidad real de la calidad técnica de una herramienta.
Cada vez el agujero es más profundo, ¿debemos pensar en dejar de cavar? No, de hecho hay más miga, pensemos en que como indicabamos al principio, el criterio de valoración de una herramienta no debe consistir únicamente en la detección. De cara a que sea útil en los ecosistemas cliente hay un puñado de requerimientos importantes que no deben menospreciarse: integración de la misma en el ciclo de desarrollo, apoyo a la corrección de las vulnerabilidades detectadas, gestión de los resultados, parametrización de los informes, creación de reglas personalizadas y un largo etcétera.

Desde la organización WASC (Web Application Security Consortium) han iniciado un proyecto para definir un criterio de evaluación de herramientas de análisis estático que tenga en cuenta estos requerimientos, se trata del SATEC (Static Analysis Tool Evaluation Criteria). Desde buguroo apoyamos estas iniciativas y formamos parte de las mismas.

Hasta el momento hay definido un pequeño borrador con las categorías, aunque por el momento está en fase muy alpha. Para apoyar el proyecto reomendamos seguir la lista de correo creada a tal efecto, y estar atento al twitter ofifical de WASC.