X
BLOG

Una estrategia de análisis estático saludable

Una estrategia de análisis estático saludable Tiempo de leer: 4 minutos

Como parte de mi serie sobre el 7 hábitos de los programadores de gran éxito, hoy voy a discutir algunas formas de asegurarme de que el análisis estático sea efectivo y sostenible.

Políticas

Para comenzar por el principio, es mejor comenzar con su política de análisis estático. Algunas personas se preguntan por qué esto es importante, pero en realidad es crucial para una iniciativa de análisis estático exitosa. Su póliza cubrirá cosas como qué reglas debe ejecutar, cuándo puede ignorarlas frente a cuándo debe corregirlas, cómo se realizan las supresiones, etc. También debe decidir qué código debe analizarse, a saber, todo ese código heredado acaba de sentarse, de lo que hablaremos en breve.

Sin una política coherente, el análisis estático se convierte rápidamente en un buscador de errores que se ejecuta ocasionalmente, reduciendo el valor que obtiene de él. Si está en un negocio de cumplimiento como médico o automotriz, debe hacer análisis estático de todos modos, por lo que también puede hacerlo bien y obtener algo de valor.

Selección de herramienta

Tener la herramienta adecuada es importante. La herramienta debe funcionar dentro de su editor de código (IDE), con los idiomas que está usando, en el sistema operativo que está usando. La herramienta debe admitir la ejecución tanto en el servidor como en el IDE, en el IDE (para desarrolladores) y la generación de informes basados ​​en la web (para los administradores). Debe poder configurar la herramienta para que haga solo las reglas que desee (no solo las que el proveedor de la herramienta desea que ejecute). Las herramientas maduras vienen con configuraciones iniciales listas para usar para que pueda comenzar con iniciativas de la industria como MISRA, OWASP, CWE y PCI.

Ser capaz de ampliar la herramienta con sus propias reglas, ideas y mejores prácticas también será importante para su éxito a largo plazo. Y no se olvide del soporte técnico: ¿alguien puede analizar los problemas relacionados con las reglas ruidosas y ayudarlo a solucionarlos? ¿Va a utilizar el código abierto y hacer las correcciones usted mismo? ¿Normalmente utiliza los servicios de proveedores para ayudar a que su proyecto se ponga en marcha y vaya en la dirección correcta, rápidamente?

Estos y más son aspectos a considerar al seleccionar una herramienta. No caiga en la trampa del horneado: proporciona poca información útil sobre si una herramienta realmente hará lo que necesita, y las herramientas de análisis estático simplemente funcionan de manera diferente.

Selección de reglas

Como se mencionó anteriormente, es fácil caer en la trampa de simplemente activar las reglas en la herramienta de análisis estático que tiene. Algunos proveedores fomentan activamente esto, ¡otros incluso lo requieren! Las necesidades de prueba de software de cada persona son diferentes. Una configuración predeterminada puede ayudarlo a comenzar, pero para tener éxito debe personalizarla.

Algunas cosas que puede hacer incluyen desactivar las reglas ruidosas y lograr que los niveles de gravedad coincidan con sus propias prácticas reales (no desea que una herramienta diga que algo es crítico cuando cree que es de baja gravedad). Una sugerencia no obvia es desactivar las reglas que le gustan pero que no planea arreglar hoy. Cuando tenga tiempo para abordar las infracciones, active la regla, no antes. Ignorarlos cuando se denuncien solo conducirá a la frustración y los malos hábitos al enseñar a los desarrolladores que no todas las reglas importan.

Las reglas que está ejecutando deben relacionarse con los problemas que tiene en el campo, los problemas que podría esperar razonablemente, los problemas de seguridad, los elementos encontrados durante la revisión del código y cualquier elemento de cumplimiento: reglas que DEBE ejecutar.

Supresiones

Incluso cuando tiene exactamente las reglas correctas, a veces el contexto hace que un análisis estático particular no resulte importante en una parte del código, mientras que en otra sigue siendo crítico. Tiene algunas opciones aquí, las menos valiosas son frustrarse y desactivar la regla. Esta es una mala elección si sabe que la regla puede proporcionar valor en algunas áreas. Si su herramienta no le permite configurar y suprimir correctamente, eligió la herramienta incorrecta; vuelva al paso 2 anterior.

Otra trampa en la que algunos caen es participar en una gestión manual de los resultados y distribuir los que se consideran importantes. Esto requiere mucha mano de obra, no es escalable, no se puede mantener, y terminará arreglando las cosas que son menos importantes y faltará las que son más importantes. Necesita un proceso basado en datos que lo ayude a evaluar qué violaciones deben corregirse y cuáles pueden ignorarse de manera segura, y luego una forma de marcarlas para que no vuelvan. Idealmente, esto lo pueden hacer los desarrolladores directamente en el IDE donde está el código, así como los administradores, arquitectos y similares, en una interfaz de usuario basada en web.

Algunos ponen estas supresiones en un sistema separado. Esto tiene la ventaja de no cambiar nunca el código, pero conlleva el riesgo de tener que volver a trabajar cuando se bifurca o refactoriza, o si hay algún problema de sincronización. Otros realizan un cambio en el código en forma de un comentario especial. Si bien esto requiere un cambio de código, es persistente y preciso, y también documenta las supresiones, lo cual es genial si alguna vez te auditan. Piense en sus necesidades y elija el método que mejor se adapte a su entorno. Si su herramienta no es compatible con ambos, vuelva al paso 2.

Código heredado

El código heredado está relacionado con las supresiones. Es importante decidir cómo quiere manejar el código antiguo. Nuevamente, depende de sus necesidades, pero a continuación describí algunos métodos.

Algunas organizaciones eligen corregir solo las violaciones de análisis estático en el código heredado si hay un informe de error de campo pendiente que toca esas líneas de código; no se debe tocar nada más en el archivo. Si tiene un código realmente antiguo o el riesgo de cambio es alto, esta es una política completamente razonable. Minimizará el riesgo.

Otra idea es arreglar todo en un archivo cuando esté allí de todos modos. Esto conlleva cierto riesgo de cambio, pero si tiene un buen conjunto de pruebas unitarias (hablaremos de eso la próxima vez), entonces no tiene que preocuparse tanto. En el lado positivo, cualquier código que toque estará actualizado con los últimos estándares de código requeridos y las mejores prácticas. El código obsoleto será menos obsoleto de lo que era.

También puede hacer un método híbrido, o simplemente ignorar todo el código antiguo antes de una fecha determinada y simplemente usar el análisis estático en el futuro. Averigüe lo que puede lograr y hágalo de esa manera. Piense primero en los riesgos y beneficios de su estrategia propuesta.

El análisis estático es una de las herramientas más valiosas en su arsenal de calidad / seguridad de software. Hacerlo bien aporta un gran valor, pero hacerlo mal puede condenar a una generación de codificadores de su organización a utilizar procesos de calidad y seguridad anticuados. Si tiene alguna pregunta, hágamelo saber en los comentarios a continuación. Siempre estoy feliz de conversar sobre cómo hacer que el análisis estático funcione.

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