Este grupo redactor ha estado largas horas buscando la solución a tus interrogantes, te ofrecemos la respuesta por esto deseamos servirte de mucha ayuda.
Solución:
Estas son las cosas de mi lista que utilizo para mis clientes (incluidas algunas de las que ha mencionado):
- Cobertura (de acuerdo con lo que la organización requiere hoy y espera usar en el futuro)
- Idioma
- Arquitectura (por ejemplo, algunas herramientas son excelentes para aplicaciones web, pero no tanto para clientes ricos o incluso para servicios / demonios de Windows)
- Framework (por ejemplo, soporte para ASP.NET pero no MVC, o Java pero no Spring)
- Bibliotecas estándar (por ejemplo, reconocer Hibernate, log4j o AntiXSS, por nombrar algunas problemáticas) según sea necesario
- Rendimiento de escaneo. En esto incluyo ambos:
- Velocidad
- Escalabilidad a grandes bases de código (incluidas LoC, subsistemas / proyectos y referencias externas)
- Lo completo – es decir, reglas / scripts incluidos en el escaneo, suficientes para proporcionar confianza en la salida, o en otras palabras, para minimizar false negativos.
- Tenga en cuenta que esta es la lista de reglas proporcionadas (por ejemplo, comprobaciones de “Inyección SQL”);
- Y la calidad de esos controles, es decir realmente atrapar Inyecciones SQL. (Como ejemplo, un cierto líder en el campo, que permanecerá anónimo, puede confundirse fácilmente con muchas formas de flujo de código, por lo que faltan fallas básicas de inyección).
- Exactitud de los resultados. Esto se aplica a los resultados que SON informados (a diferencia de los que faltan, cubiertos en “Completitud”). La mala precisión se puede ver en:
- Gran cantidad de false positivos
- Duplicados
- Categorizaciones erróneas
- Priorizaciones incorrectas (p. Ej., Etiquetar un error de muy bajo impacto como “Alto riesgo”)
- Resultados irrelevantes (es decir, un error de código que es precisa, pero completamente irrelevante para la aplicación o arquitectura; por ejemplo, encontrar XSS en una aplicación que no sea HTML, HTTP y no interactiva, o Inyección SQL en una aplicación cliente).
- Personalización – como dijiste, personalizar fuentes, sumideros y filtros; también informes; pero también, no menos, personalizar reglas / scripts y agregar lógica personalizada (no solo fuente-> filtro-> sumidero). Tenga en cuenta que muchas herramientas le permiten “personalizar” sus reglas, pero esto es realmente limitado solamente para agregar fuente / sumidero / filtros.
- Sostenibilidad / repetibilidad – con esto me refiero al manejo de exploraciones repetidas. ¿Cómo maneja los cambios? Problemas previamente marcados como false positivos? ¿Recibo comparaciones?
- Modelo de implementación, por ejemplo, normalmente una combinación de:
- puesto de auditor único
- servidor compartido, al que se accede vía remota
- acceso web
- complemento de desarrollador
- construir la capacidad de conexión del servidor
- (y, por supuesto, la capacidad de establecer una política diferente para cada uno)
- Usabilidad. Esto incluye:
- UI (incluidas teclas de acceso rápido, etc.)
- capacidades de filtrado de auditores
- Proporcionar suficiente contexto resaltando lo suficiente del flujo de código.
- static texto, como explicaciones, descripciones, corrección, enlaces a fuentes externas, ID en OWASP / CWE, etc.
- características de usuario adicionales, por ejemplo, ¿puedo agregar un resultado manual (no encontrado por el escaneo automático)?
- Reportando – ambos flexibles por proyecto según sea necesario (no olvide detallar para desarrolladores y de alto nivel para gerentes) y proyectos cruzados agregados. También comparaciones, etc.
- Seguridad (en el caso de un modelo de servidor): protección de los datos, gestión de permisos, etc. (como cualquier aplicación de servidor …)
- Costo. Esto incluye al menos:
- hardware
- licencia: cualquiera o todos los siguientes:
- por asiento – auditor
- por puesto – desarrollador
- por asiento: informa al usuario
- por servidor
- por proyecto
- por líneas de código
- licencia del sitio
- mantenimiento
- servicios, por ejemplo, implementación, ajuste, integración personalizada, etc.
- formación (tiempo tanto del formador como del auditor / desarrolladores)
- Integración con :
- fuente de control
- localizador de bichos
- entorno de desarrollo (IDE)
- construir servidor / CI / CD
- automatización
Mirando esto, creo que está más o menos en el orden de preferencia, comenzando desde los requisitos básicos hasta la aplicabilidad, la calidad, la facilidad de implementación, la eficiencia, lo agradable de tener …
Aquí está lo más importante que debe saber sobre cómo evaluar un static herramienta de análisis:
Pruébelo con su propio código.
Lo repetiré de nuevo. Pruébelo con su propio código. Necesita ejecutar una prueba, en la que lo usa para analizar algún código representativo suyo, y luego analiza su resultado.
La razón es que static Las herramientas de análisis varían significativamente en efectividad, y su efectividad depende del tipo de código que tiende a escribirse en su empresa. Por lo tanto, la mejor herramienta para su empresa puede no ser la misma que la mejor para otra empresa en el futuro.
No puede pasar por una lista de funciones. El hecho de que una herramienta diga que es compatible con Java no significa que sea buena para analizar el código Java, o para analizar su código Java y encontrar los problemas que le interesan.
La mayoría static Los proveedores de análisis con gusto lo ayudarán a configurar una prueba gratuita para que pueda probar su herramienta en su propio código, así que acepte su oferta.
Gary McGraw y John Steven han escrito un buen artículo sobre cómo elegir un valor static herramienta de análisis. Además de llegar al punto en que necesita probar las herramientas en su propio código para ver cuál es la mejor, también señalan que debe tener en cuenta qué tan bien se puede personalizar la herramienta para su entorno y necesidades, y presupuestar para esto. costo.
Una lista larga de criterios puede distraerlo tanto como ayudarlo a encontrar una buena solución.
Tomemos, por ejemplo, la cuestión de “false positivos “. Es un problema inherente a este tipo de herramientas. La solución a largo plazo es aprender a vivir con ellas. Significa que los programadores tendrán que aprender a codificar static herramienta de análisis, aprenda qué hace que active una false positivo, y escriba el código de una manera diferente para que el false positivo no se activa. Es una técnica familiar para aquellos que usan lint, o aquellos que intentan compilar su código de forma gratuita: modificas el código hasta que el false positivo deja de dispararse.
El criterio más importante es comprender el problema que está tratando de resolver. Es un beneficio enorme hacer que sus programadores pasen por el paso de ejecutar un static analizador una vez, para eliminar los problemas más grandes en su código y, francamente, aprender lo que ya deberían saber sobre programación y no cometer esos errores. Pero el valor marginal de correr continuamente static analizadores es mucho menor y el costo marginal es mucho mayor.