X
BLOG

Introducción al análisis estático sin abrumar al equipo

Introducción al análisis estático sin abrumar al equipo Tiempo de leer: 8 minutos
Esta publicación es la primera de algunas que escribiré para ayudar a los nuevos usuarios a adoptar herramientas de análisis estático en su proceso de desarrollo. Comenzar puede ser complicado si no se ha tomado un tiempo al principio para asegurarse de haber identificado las estrategias adecuadas para su proyecto.

Como arquitecto de soluciones aquí en Parasoft, tenemos muchas personas que buscan ayuda en esta área, ¡así que sepa que no está solo! Y si quieres más información, puedes descargar y leer esta guía completa que ayudé a armar.

Supongo que sus herramientas de análisis estático están instaladas y se ha configurado cualquier configuración inicial. Después de eso, comenzar puede ser complicado si no se ha tomado un tiempo al principio para asegurarse de haber identificado las estrategias adecuadas para su proyecto. Aquí, lo que quiero decir con "comenzar" es comprender mejor el enfoque general de la integración del análisis estático en un proyecto existente y cómo aumentar el retorno de la inversión del análisis estático a lo largo del tiempo.

¿Qué es el análisis estático?

En términos simples, el análisis estático es el proceso de examinar el código fuente y binario sin ejecución, generalmente con el propósito de encontrar errores o evaluar la calidad. A diferencia del análisis dinámico (p. Ej. Parasoft Insure ++), que requiere un programa en ejecución para funcionar, el análisis estático se puede ejecutar en el código fuente sin la necesidad de un ejecutable.

Esto significa que el análisis estático se puede utilizar en código parcialmente completo, bibliotecas y código fuente de terceros. El desarrollador tiene acceso al análisis estático, para usarlo mientras se escribe o modifica el código, o para aplicarlo en cualquier base de código arbitrario.

Análisis estático en apoyo de la seguridad.

En el dominio de seguridad de la aplicación, análisis de código estático va por el término Prueba de seguridad de aplicaciones estáticas (SAST). El análisis estático puede respaldar la detección de vulnerabilidades de seguridad, junto con la detección de errores, métricas de calidad y cumplimiento de estándares de codificación.

Análisis estático en apoyo de la seguridad funcional y los estándares de codificación

Las herramientas de análisis estático también son obligatorias (o en algunos casos, “altamente recomendadas”) por estándares de seguridad funcional como ISO 26262 o EN 50128, por su capacidad para detectar defectos difíciles de encontrar y mejorar la seguridad del software. Por supuesto, esto también vuelve a la seguridad, ya que las herramientas de análisis estático también ayudan a los equipos de software a ajustarse a los estándares de codificación utilizados principalmente para validar la codificación segura, como CERT o incluso MISRA.

Introducción del análisis estático en su proyecto

Una gran ventaja de las herramientas de análisis estático es que pueden introducirse y utilizarse en cualquier etapa de un proyecto, y son efectivas incluso si el proyecto está incompleto y parcialmente codificado. El mayor desafío con la introducción del análisis estático es que una gran cantidad de código puede producir una gran cantidad de advertencias. Por lo tanto, el enfoque al integrar el análisis estático en un proyecto debe estar en lograr que el equipo sea productivo lo antes posible y minimizar la oportunidad de que el equipo se sienta abrumado por todas las advertencias del análisis estático. No se trata de disminuir la importancia de estas advertencias, pero la mayoría de los desarrolladores no pueden darse el lujo de corregir el código existente o heredado, al menos no de inmediato.

El enfoque debe ser la integración de las herramientas en los procesos cotidianos para maximizar el acceso y la usabilidad, y luego lidiar con los errores más críticos y las vulnerabilidades de seguridad. Una vez que el equipo se vuelve más competente, puede concentrarse en optimizar las herramientas y los procesos para aumentar el retorno de la inversión.

Empiece con el final a la vista

Para aprovechar al máximo el análisis estático, es importante comprender el objetivo final. Si el objetivo es una mejor seguridad, por ejemplo, que dará forma al enfoque del análisis y la corrección, o si el objetivo es cumplir con un estándar de codificación como MISRA C, el enfoque será satisfacer el estándar de codificación y demostrarlo a las entidades de certificación según sea necesario. .

Cuando se adopta por primera vez el análisis estático, es fácil caer en la trampa de que más es mejor (es decir, más análisis y más advertencias significa que está obteniendo el máximo valor de la herramienta). Ésta es una trampa común. En cambio, manténgase enfocado en el objetivo final.

Si la seguridad es el foco, mantén el foco en mejorar la seguridad y reduce la distracción de otros tipos de advertencias. Por supuesto, siempre es importante rastrear los errores críticos, pero no deben distraer la atención del objetivo principal. Con el tiempo, a medida que el equipo se vuelva más competente, podrá incorporar otros objetivos secundarios, como mejorar la calidad general o hacer cumplir los estándares de codificación. A medida que el análisis estático se convierta en parte de la rutina diaria de cada desarrollador, podrán analizar los resultados más rápidamente y corregir errores de manera más eficiente. En este momento, los objetivos secundarios se lograrán de manera más efectiva, en lugar de simplemente ser abrumadores.

Estrategias para introducir el análisis estático en cada etapa de madurez del producto

Una vez que comprenda su objetivo principal en el que concentrarse, debe identificar la madurez del producto en desarrollo, ya que afecta la forma en que se puede adoptar el análisis estático. Considere las principales etapas de desarrollo a continuación e identifique dónde encaja su proyecto, para que pueda comprender qué enfoque de adopción es mejor para usted.

Proyecto existente - en desarrollo actual

El escenario más común es una organización de software que decide utilizar el análisis estático y lo implementa en sus proyectos actuales.

Cada proyecto puede optar por adoptar las herramientas al comienzo de un sprint o al comienzo de una importante actualización de funciones nuevas. Siendo realistas, los equipos de software siempre están trabajando, incluso cuando un producto está "terminado", hay otra versión o variante en marcha. El aspecto clave de este escenario de adopción es que hay un cuerpo significativo de código existente y nuevo código que se desarrolla a diario. El enfoque recomendado para la integración se llama "una línea en la arena”, Lo que significa mejorar el código nuevo a medida que se desarrolla, al tiempo que pospone las advertencias menos críticas deuda técnica. Hablaremos de esto más en un momento.

Proyecto existente - Producto en el mercado en mantenimiento

La adopción de análisis estático para un producto maduro puede tener objetivos diferentes a los de un proyecto aún en desarrollo. Este es un producto que se encuentra en los últimos años del ciclo de vida del desarrollo de software, en el que se escribe poco código nuevo, solo para corregir errores persistentes y vulnerabilidades de seguridad. El enfoque principal para adoptar un análisis estático para estos proyectos se llama "reconocer y aplazar.”En este enfoque, dado que se está desarrollando poco código nuevo, todos los errores descubiertos y las vulnerabilidades de seguridad se agregan a la deuda técnica existente.

Proyecto Greenfield

Aunque no es frecuente que los equipos de software tengan un nuevo comienzo, un nuevo producto y proyecto es el punto ideal para integrar nuevas herramientas y técnicas en el proceso de desarrollo.

En estos proyectos, existe poco código específico para el proyecto, pero aún puede depender de software de código abierto y de terceros. Los desarrolladores pueden integrar el análisis estático en sus entornos de desarrollo desde el principio, lo que garantiza un alto estándar de calidad a medida que se escribe el código. Esto permite la adopción de estándares de codificación y garantiza que las advertencias críticas de análisis estático se resuelvan a medida que surgen, lo que agrega menos errores y vulnerabilidades a la pila de deudas técnicas. El enfoque de la adopción en este caso se denomina acertadamente "Greenfield."

Enfoques de adopción del análisis estático: cómo gestionar los primeros informes de análisis estático

Una vez que se ha instalado una herramienta de análisis estático en el proyecto, generalmente hay un informe bastante extenso de violaciones y advertencias reportadas por la herramienta. Esto puede ser abrumador, especialmente en bases de código grandes, por lo que la forma en que se administran estos informes iniciales influye directamente en el éxito de la integración de la herramienta en el proyecto.

No todas las advertencias son críticas, por lo que no es necesario tratar todo de inmediato. Aprender qué abordar de inmediato y qué aplazar es la clave del éxito. Como se mencionó anteriormente, la madurez y el tamaño del producto tienen una influencia directa en el enfoque, que se describe a continuación con más detalle.

Línea en el enfoque de arena

Como su nombre lo indica, en este enfoque, los desarrolladores deciden que después del análisis inicial, no permitirán que más advertencias críticas y violaciones ingresen al código base. En otras palabras, se comprometen a analizar cada advertencia crítica para decidir su veracidad e implementar una solución oportuna, en caso de que se trate de un error.

El equipo también puede decidir agregar advertencias críticas ya descubiertas en el código existente para agregarlas a la lista de errores en su herramienta de informes. Ejemplos de estos tipos de advertencias pueden ser vulnerabilidades de seguridad críticas, como inyecciones de SQL, o errores graves de memoria, como desbordamientos de búfer. En la mayoría de los casos, las advertencias menos serias pueden posponerse para un análisis posterior. Quizás esté pensando, "¿esto no se suma a nuestra deuda técnica?" Y si es así, ¡tiene razón! Pero en esta etapa, estamos de acuerdo con eso. Cualquier error potencial dentro de estas advertencias ya estaba en la pila de deuda técnica. Al menos ahora, están identificados y son mucho más fáciles de arreglar en un momento posterior.

Reconocer y aplazar el enfoque

En el caso de que un producto ya esté en el mercado y en mantenimiento, aún es beneficioso identificar los errores persistentes y las vulnerabilidades de seguridad en el código, pero no es factible para los desarrolladores analizar (y mucho menos corregir) todas estas advertencias.

En tal caso, tiene sentido mirar los informes más importantes y decidir un curso de acción. El resto de las advertencias se reconocen, ya que el equipo de software reconoce que existen, pero en su mayoría se aplazan para un momento posterior. (Esto nuevamente se suma a la deuda técnica de la organización, pero como se mencionó anteriormente, estos errores técnicamente ya existen como deuda técnica). Este enfoque difiere del enfoque de línea en la arena en que después de identificar las advertencias clave, simplemente difiere el resto, sin necesariamente ningún análisis.

Enfoque greenfield

Un proyecto con poco código existente es un punto de partida ideal para el análisis estático. En este caso, los equipos de software pueden investigar todas las advertencias que surjan y corregir los errores encontrados. A diferencia de los otros enfoques, solo hay algunas advertencias que administrar, por lo que los desarrolladores pueden abordar la carga de trabajo adicional. Este también es un momento ideal para implementar y hacer cumplir un estándar de codificación a través de las herramientas, ya que las violaciones se pueden identificar y corregir directamente dentro del IDE y antes de que cualquier código se envíe al control de versiones (lo que también podría hacer en los otros escenarios descritos aquí). .

La adopción del análisis estático en las tres etapas principales de madurez se diferencian por cómo tratan la acumulación de advertencias, como se ilustra a continuación:

La adopción del análisis estático en las tres principales etapas de madurez: En una Proyecto Greenfield, la mayoría de las advertencias reportadas se investigan y corrigen con poca cantidad de deuda técnica. Proyectos en desarrollo tienden a tener una acumulación de advertencias que en su mayoría se aplazan y solo se tratan las advertencias críticas, y productos en mantenimiento tienden a aplazar la mayoría de las advertencias.

Configuración versus filtrado

Una de las principales diferencias entre las herramientas de análisis estático de código abierto o ligeras y las herramientas comerciales de análisis estático avanzado es la capacidad de configurar qué conjunto de verificadores están habilitados para el análisis y filtrar los resultados informados según la categoría de advertencia, el nombre del archivo, la gravedad y otros atributos. Esto ayuda con el objetivo de no sentirse abrumados: los desarrolladores pueden centrarse solo en los tipos de advertencias que les interesan y reducir la cantidad de información proporcionada en un momento dado.

También hay una diferencia que vale la pena señalar entre configurando damas y  filtrado de resultados. Aunque inicialmente podría parecer mejor limitar el número de reglas en la configuración global, a menudo se debe usar el filtrado para limitar el alcance de los informes en lugar de eliminar el verificador por completo. Si una regla que luego resulta ser importante se desactiva en la configuración, no habrá historial en el repositorio de advertencias, por lo que no podrá saber si el error fue introducido por cambios recientes o ya en el código. antes de que se adoptara el análisis estático.

Recomendaría usar la configuración para limitar simplemente el conjunto de reglas a aquellas que son previsibles como útiles para el equipo de software. Nuevamente, comience con el objetivo final en mente: si mejorar la seguridad es el objetivo clave, tiene sentido habilitar todas las reglas relacionadas con la seguridad, deshabilitar las reglas menos importantes y habilitar uno de los estándares de codificación segura incorporados, como CERT C. Luego, si está utilizando una solución avanzada de análisis estático como la prueba Parasoft C / C ++, puede aprovechar sus herramientas de administración integradas para manejar los datos producidos a partir de los informes de análisis estático e impulsar el enfoque de desarrollo futuro.

Resumen

Las herramientas de análisis estático brindan a las organizaciones de software la capacidad de detectar y rastrear errores, vulnerabilidades de seguridad sin necesidad de ejecutar código. Estas herramientas se pueden aplicar a código existente, heredado y de terceros y proporcionar calidad.

La adopción de análisis estático varía en cierta medida según la madurez del proyecto. Un gran cuerpo de código genera numerosas advertencias. Esto es completamente manejable y el éxito de la adopción depende de cómo los equipos decidan abordar los resultados. Se introducen varias técnicas para cada nivel de madurez principal de un proyecto y cómo estas herramientas se pueden integrar en el flujo de trabajo diario para desarrolladores, líderes de equipo y gerentes.

En mi próxima publicación, hablaré sobre la integración del análisis estático en sus flujos de trabajo diarios, ¡así que asegúrese de volver para eso! O suscríbete al blog completando tu nombre en el cuadro justo debajo de esta publicación, para recibir una notificación cuando se publique.

Introducción al análisis estático

Escrito por

Billy McMullin

Como arquitecto de soluciones en Parasoft, Billy ayuda a los equipos a establecer estrategias y establecer prioridades a medida que adoptan prácticas modernas de desarrollo y prueba de software en su organización.

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

Prueba Parasoft