X
BLOG

Adopte el análisis estático en pequeños pasos

Adopte el análisis estático en pequeños pasos Tiempo de leer: 5 minutos

Hasta ahora, 2020 ha sido un año desafiante. Como muchos de nosotros trabajamos de forma remota desde casa, es más importante que nunca que el código que producimos sea lo mejor posible. El análisis estático es un punto de enfoque perfecto para los desarrolladores de software y los profesionales de la seguridad y la seguridad funcional.

Todos sabemos que el análisis de código estático es algo que deberíamos estar haciendo. Algunos de nosotros sabemos que deberíamos hacerlo porque nos ayudará. Otros pueden sentir que el análisis estático se les impone y que es una pérdida de tiempo, tedioso o crea trabajo con pocos beneficios. Si bien me gustaría decir que esas personas están equivocadas, desafortunadamente, ¡probablemente tengan razón!

Mordiendo más de lo que puedes masticar

Si el análisis estático es lento, ruidoso (falsos positivos), doloroso de usar, crea trabajo o no proporciona valor, generalmente es porque muerde más de lo que puede masticar. Configuración adecuada de herramientas de análisis estático también es un factor importante, pero ese es un tema completamente separado en sí mismo, y lo cubriré en otra publicación.

Para esta publicación, quiero concentrarme en un error que cometen muchas personas que adoptan por primera vez el análisis estático: tratar de hacer demasiadas cosas demasiado pronto. En general, lograr que el flujo de trabajo del análisis estático y la configuración sean correctos desde el principio es fundamental para el éxito: menos dolor, más ganancia. El primer paso es asegurarse de tener la herramienta adecuada para su organización. Recientemente produjimos un Webinar y una whitepaper cubriendo los conceptos básicos de cómo elegir la herramienta de análisis estático adecuada para satisfacer sus necesidades, así que échales un vistazo.

Empiece de a poco con el análisis estático

Una vez que seleccione la herramienta de análisis de código estático, debe configurarla. ¿Qué damas quieres correr? Comenzaría con una pauta simple: es mejor comenzar con un pequeño conjunto de verificadores, incluso solo uno si es necesario, y asegurarse de que usted y su equipo estén perfeccionando sus habilidades de análisis estático y su flujo de trabajo mientras obtienen un beneficio demostrable del esfuerzo. La alternativa común es activar un centenar o más de comprobadores que producen informes grandes a los que se hace un seguimiento esporádico.

Las herramientas de análisis estático pueden producir mucho ruido hasta que se colocan en posición vertical. Cuando digo "morder más de lo que puedes masticar", el ruido (a veces llamado falsos positivos) abruma las advertencias importantes. La adopción temprana a veces comienza como una búsqueda académica con la intención de una investigación temprana para tener una idea de cuántos errores hay en el código base. Este método no tiene en cuenta el flujo de trabajo del desarrollador y su uso diario de las herramientas. Tampoco se ajusta a la necesidad pragmática de tener software escrito, probado y listo para usar.

El mejor enfoque es comenzar poco a poco con el objetivo de mejorar constante e incrementalmente la calidad del código. Elimine los problemas de código críticos más problemáticos y luego amplíe para buscar otros problemas que aún son importantes, pero quizás no tan peligrosos. Echemos un vistazo a cómo funciona eso en un sentido práctico.

Aborde los grandes problemas primero

A veces vemos que las organizaciones intentan armar una lista de configuración de verificadores por consenso basándose en una gran lista de todos los posibles verificadores que proporciona una herramienta de análisis estático. Aunque es plausible, si considera que las herramientas de Parasoft tienen más de mil comprobadores, el enfoque es defectuoso porque se centra en lo que puede hacer la herramienta y no en abordar los problemas reales que enfrenta su aplicación en función del soporte al cliente, el entorno esperado, etc. en.

Los equipos pueden dedicar mucho tiempo a perseguir infracciones de los inspectores que no aportan mucho valor, incluso si el tipo de error parece importante en abstracto. Es esencial conectar el análisis estático con los problemas reales que el equipo está resolviendo o que espera enfrentar. Reducir la lista de verificadores es importante, pero aún puede producir demasiadas violaciones para un equipo o proyecto que recién está comenzando. Debe observar el tamaño del "bocado" que está tomando.

Limite el "mordisco" del análisis estático

Una excelente manera de minimizar el tamaño del bocado que está tomando (no es solo el número de comprobadores) es evaluar con qué código lo está ejecutando. La mayoría de los proyectos en estos días consisten en bases de código existentes, heredadas o heredadas. Si son lo suficientemente grandes, no es práctico ejecutar un análisis estático en este código y dedicar recursos para solucionar problemas. Debe limitar el "mordisco" en términos de la cantidad de código analizado.

Un enfoque común es limitar la acción sobre las advertencias informadas al código recientemente desarrollado o modificado. Por ejemplo, el líder del equipo decide que en el próximo sprint, todo el código nuevo se analizará con un conjunto inicial de verificadores priorizados. El primer conjunto de informes de análisis se utiliza para medir la cantidad de trabajo necesario. Si esto es demasiado para un sprint, el análisis puede limitarse aún más. Por otro lado, si este enfoque no genera suficientes advertencias, o si no se cumplen los objetivos de calidad, aumente el alcance.

Todo esto para decir: Da un pequeño bocado, un bocado de gran valor. Arréglelo, consiga algo, incorpórelo en su proceso diario y en su cultura. Añádalo lentamente. Establezca algunas fichas más y, finalmente, llegará a su objetivo de aspiración de todas las fichas que quería al principio.

Observe y aumente el valor del análisis estático a lo largo del tiempo

Comenzar con poco es más que controlar un flujo de trabajo manejable. También ayuda a los desarrolladores, que son nuevos en la técnica y en la herramienta, a ver rápidamente el valor. Al proporcionarles hallazgos críticos primero, ven errores que es importante corregir y comprenden cómo las pruebas o revisiones de código podrían haberlos pasado por alto. A medida que aumenta el análisis, los desarrolladores siempre obtienen los resultados más procesables. El objetivo es no llegar nunca a donde les está dando a los desarrolladores advertencias de bajo valor. Es una pérdida de tiempo y herramientas, y debe aprovechar sus procesos para filtrarlos.

Evite la clasificación

No es raro que surja el triaje cuando se habla de los resultados del análisis de código estático. La clasificación solo se usa en la vida real cuando un proceso se ve abrumado. Los equipos de software que se toman un bocado demasiado grande ejecutan herramientas de análisis estático en una gran base de código con verificadores predeterminados habilitados e inevitablemente terminan con muchas advertencias. Luego intentan revisarlos y decir, ¿cuáles necesito arreglar? ¿Cuáles son los más importantes? Esto es tedioso, demasiado subjetivo, propenso a errores y, en su mayoría, innecesario.

Las herramientas deben clasificarse por usted. Si no es así, probablemente tenga la herramienta incorrecta, la configuración incorrecta o el enfoque incorrecto. Una herramienta moderna de análisis estático debe poder filtrar las advertencias según la gravedad, la prioridad y el riesgo inherente. No dejes que la herramienta en sí te obligue a tomar un bocado demasiado grande.

Resumen

Con suerte, este consejo le será de utilidad. La adopción exitosa del análisis estático necesita pequeños pasos antes de avanzar en la mejora de la calidad, la seguridad y la protección. Limitar cuánto "muerde" su equipo al limitar el alcance del análisis tanto en términos de verificadores como de cantidad de código: todos pueden ver el valor. Evitar "un bocado demasiado grande" evita muchas de las quejas comunes sobre las herramientas de análisis estático. Las mejoras continuas e incrementales ayudan a todos a aprender a trabajar con análisis estático y a obtener un mejor valor por la inversión.

¡Buena suerte en su viaje de análisis estático en el resto de 2020!

Mira Parasoft en acción

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.

Prueba Parasoft