X
BLOG

Cómo elegir herramientas modernas de análisis estático: más allá del horneado

Cómo elegir herramientas modernas de análisis estático: más allá del horneado Tiempo de leer: 6 minutos

Desde un nivel de 50,000 pies, todos análisis de código estático las herramientas tienen el mismo aspecto. Analizan el código sin ejecutarlo y encuentran defectos, vulnerabilidades y otros problemas.

Todas las herramientas generan avisos e informes. Por lo general, se integran en IDE y CI / CD / sistemas de compilación. Si desea integrar con éxito cualquier herramienta de codificación en su desarrollo diario y obtener el mayor retorno de su inversión, vale la pena evaluar completamente sus opciones.

Más allá del horneado de la herramienta de análisis estático

Al tratar de determinar qué herramienta de análisis estático funcionará mejor, muchos evaluadores adoptan un enfoque común para seleccionar una herramienta para su grupo u organización. Ejecutan cada herramienta en el mismo código, comparan los resultados y luego eligen la herramienta que informa la mayoría de las infracciones de forma inmediata.

Esta no es realmente una evaluación de producto. Es un horneado. Y el ganador no es necesariamente la mejor herramienta para establecer un proceso de análisis estático escalable y sostenible dentro del equipo u organización.

De hecho, muchos factores clave que marcan la diferencia entre una adopción exitosa del análisis estático y otra iniciativa fallida comúnmente se pasan por alto durante estas etapas iniciales.

Evalúe sus necesidades de análisis de código estático y su situación actual

Antes de comenzar la búsqueda de una herramienta, eche un vistazo brutalmente honesto a su organización. Evalúe lo siguiente:

Qué necesita su organización. Para tener éxito con el análisis estático, es importante comprender lo que se supone que debe resolver.

  • ¿Qué puntos de dolor específicos se están abordando con el análisis estático?
  • ¿Tiene la organización requisitos de cumplimiento normativo?
  • ¿Es la seguridad de las aplicaciones una preocupación?
  • ¿Qué ya se está haciendo?
  • ¿Quién necesita ver los informes de análisis y actuar?

Dónde se encuentra su organización. También es importante saber qué se pretende resolver con las nuevas herramientas y si encajan con su organización.

  • ¿Su proceso de desarrollo actual es lo suficientemente estable, repetible y optimizado para proporcionar una base sólida para el análisis estático?
  • ¿Cuáles fueron los resultados de evaluaciones previas o implementaciones de herramientas de análisis estático?

Criterios en su proceso de selección de herramientas

La elección de una herramienta de análisis estático para su adopción y eventual integración en su proceso de desarrollo requiere esfuerzo y planificación. Es más que una revisión técnica. El proceso requiere un examen de qué tan bien encaja la herramienta con su organización. También es importante evaluar al proveedor que vende y respalda las herramientas.

Criterios de evaluación de herramientas

Estos son los criterios a considerar durante la evaluación técnica de las herramientas candidatas:

  • Cobertura de las pautas necesarias
  • Calidad de los comprobadores incorporados para las pautas necesarias.
  • Cobertura para la industria y estándares corporativos
  • Profundidad y amplitud de análisis
  • Medios prácticos para reducir el ruido (violaciones ignorables del inspector)
  • Número razonable y enfoque de falsos positivos
  • El número aceptable de falsos negativos
  • Facilidad para ajustar las fichas integradas para que se adapten a las políticas de su organización
  • Facilidad para agregar nuevos verificadores personalizados para verificar requisitos únicos
  • Nivel de complejidad admitido para nuevos correctores personalizados

Lea nuestro documento técnico para obtener más detalles sobre cada uno:

Consideraciones del proveedor

Elegir el proveedor adecuado es tan importante como elegir las herramientas adecuadas. Cuando una organización adquiere una herramienta, se compromete a entablar una relación con el proveedor de su elección.

Detrás de las implementaciones de herramientas más exitosas, hay un proveedor dedicado a ayudar a la organización a lograr los objetivos comerciales, abordar los desafíos que surgen e impulsar la adopción.

Es importante considerar varios niveles de calificación y evaluación del proveedor a lo largo del proceso de evaluación. En este punto, considere lo siguiente:

  • ¿Se alinean las capacidades del proveedor para la escala, el crecimiento y la visión con sus requisitos y objetivos?
  • ¿Tiene el proveedor una estrategia coherente sobre cómo implementarlo en una organización y evolucionar a medida que cambian las necesidades de la organización?
  • ¿Cuáles son las “mejores prácticas” recomendadas por el proveedor para usar su herramienta?

También es importante comprender la reputación del proveedor en el mercado. Responde estas preguntas:

  • ¿Qué organizaciones están utilizando la herramienta?
  • ¿Qué revelan los estudios de caso sobre su implementación, uso y beneficios?
  • ¿Qué dicen los expertos de la industria en reseñas, reseñas y premios?

Calidad versus cantidad: se trata de cobertura

Una pregunta común de los posibles clientes es: ¿Cuántas fichas tiene su producto?

La pregunta implica que la calidad de una herramienta depende de la cantidad de errores diferentes que cubre. Esta es una mala medida para cualquier herramienta, particularmente las herramientas de análisis estático.

Los usuarios de herramientas de análisis estático deberían estar realmente preocupados por qué tan bien cubre cada herramienta diferentes tipos de errores, estándares de codificación y profundidad de análisis. Un ejemplo común de esto es la afirmación de cada proveedor de la cobertura de CWE Top 25 u OWASP Top 10 o MISRA C / C ++ por su herramienta.

No es raro ver a los proveedores reclamar una cobertura del 100% de los estándares de codificación populares. Una afirmación que a menudo es engañosa. En lugar de preocuparse por la cantidad de verificadores o reglas, la pregunta real debería ser: ¿Qué tan bien cubre una herramienta los tipos de problemas de codificación que le preocupan?

Un ejemplo: Cobertura de MISRA C, C ++ y CERT C

Aunque los estándares de codificación como MISRA tienen sus raíces en la automoción, su adopción se está extendiendo a otros dominios críticos para la seguridad. Junto con SEI CERT C, el mercado lo requiere o se usa para eliminar el riesgo de su desarrollo de software. Independientemente del caso de uso, estos estándares se utilizan inevitablemente para evaluar herramientas de análisis estático.

Sin embargo, los reclamos de cobertura para cada estándar están abiertos a interpretación porque los estándares no definen con precisión cómo una herramienta reclama cobertura. Es valioso sumergirse en capacidades particulares que pueden ser importantes para su caso de uso. Si su proyecto necesita MISRA C, por ejemplo, se debe analizar en detalle la capacidad de cada herramienta.

Considere la siguiente evaluación de varias soluciones comerciales y de código abierto sobre su cobertura de los estándares MISRA y CERT C:

Las soluciones de código abierto muestran una cobertura deficiente, lo que no es sorprendente porque su intención nunca fue seguir tales estándares. Sin embargo, las diversas herramientas comerciales, que a menudo afirman ser compatibles con estos estándares, no están realmente cumpliendo. El criterio de evaluación real que importa aquí es la cobertura del estándar, no el número de verificadores necesarios para respaldar el estándar.

Sin embargo, al utilizar un conjunto de pruebas para medir la cobertura frente a un estándar, también debe considerar la cobertura del conjunto de pruebas en sí. La imagen de cobertura de Juliet CWE Top 25 (2011) a continuación enumera los ID de enumeración de debilidades comunes (CWE) y si están cubiertos por alguna prueba en los conjuntos de pruebas de Juliet C / C ++ y Java. Puede ver claramente que el conjunto de pruebas no cubre por completo los CWE importantes (25 principales); esto es común en muchos conjuntos de pruebas.

Soluciones de código abierto

Surge una pregunta obvia sobre el uso de herramientas de código abierto para una solución de análisis estático. Hay algunos problemas clave con FOSS que se deben tener en cuenta. Una evaluación debe incluir los costos de funciones, servicios y soporte importantes que faltan.

Los detalles sobre los costos y beneficios de FOSS, en general, están disponibles aquí, incluidos temas como soporte, actividad y longevidad del proyecto y escalabilidad. Si los estándares de la industria son importantes y las auditorías externas son parte de su negocio, es posible que las soluciones FOSS no sean una opción.

Preguntas que necesitan respuesta

Al evaluar los resultados de cada proyecto piloto, la evaluación y la toma de decisiones finales deben reducirse a responder las siguientes preguntas clave:

¿El equipo realmente lo adoptará y usará? La mejor herramienta del mundo no ofrecerá ningún valor si no se puede implementar, si los desarrolladores no la usan o si es una interrupción demasiado grande para el progreso del proyecto. Decidir qué tan bien se adopta algo requiere una evaluación integral no solo de las herramientas, verificadores e integraciones, sino también del proveedor, su soporte, servicios y capacitación.

¿Abordará los problemas que la organización y el equipo están tratando de resolver? La implementación de nuevas tecnologías requiere centrarse en los problemas que se intentan resolver, en lugar de esperar que el análisis estático aborde sus problemas.

Además, las expectativas de la nueva tecnología para abordar el problema deben ser realistas. Es importante cuantificar el éxito y el ROI. Es importante determinar de antemano cómo se mide el éxito: tiempo perdido, lanzamientos perdidos o casos de soporte de campo.

¿Es esta una solución a largo plazo? Las evaluaciones requieren mucho tiempo y el compromiso del equipo. Las implementaciones completas requieren más tiempo y compromiso. Decidirse por una herramienta que sea "lo suficientemente buena por ahora" puede ahorrar dinero a corto plazo, pero resultar extremadamente costoso a largo plazo.

Resumen

Las evaluaciones de herramientas de análisis estático a menudo terminan como un punto de partida en el que cada herramienta se prueba en un código común y se evalúa en función de los resultados. Aunque esto es útil y la evaluación técnica es importante, los evaluadores deben mirar más allá de estos resultados hacia un panorama más amplio y un cronograma más largo.

Los evaluadores deben considerar qué tan bien las herramientas administran los resultados, incluida la visualización y los informes fáciles de usar. Los equipos deben comprender claramente cómo cada herramienta respalda las afirmaciones realizadas en áreas como los estándares de codificación, por ejemplo.

Escrito por

Arthur Hicken

Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft