👩🏿‍🔬 👩🏿‍🤝‍👩🏽 🧛 Razones para introducir el analizador de código estático PVS-Studio en el proceso de desarrollo 🚂 🅾️ 🕙

PVS-Studio es una herramienta para encontrar errores y vulnerabilidades potenciales en el código fuente de programas escritos en C, C ++, C # o Java. PVS-Studio pertenece a la clase de herramientas de prueba de seguridad de aplicaciones estáticas (SAST). El analizador se centra en la práctica de la integración continua (CI) y le permite identificar errores en las primeras etapas cuando solucionarlos no cuesta casi nada.

Análisis de código estático

Los proyectos de software en el proceso de su desarrollo son cada vez más. Ejemplos:

Linux kernel 1.0.0: 176,000 líneas de código
Linux kernel 5.0: 26,000,000 líneas de código
Photoshop 1.0: 128,000 líneas de código
Photoshop CS 6: 10,000,000 líneas de código

A medida que un proyecto crece en tamaño, su complejidad crece más rápido que linealmente. Por esta razón, a medida que crece el tamaño de la base del código , también lo hace la densidad de errores. Una forma de compensar la creciente complejidad es utilizar herramientas de análisis de código estático.

El analizador estático es un programa auxiliar del programador que realiza una revisión preliminar del código e indica fragmentos de código que tienen más probabilidades de contener un error. Gracias a esto, muchos errores pueden corregirse en una etapa temprana cuando el costo de corregirlos es mínimo.

El análisis estático no reemplaza, pero complementa otras metodologías de detección de defectos, como revisiones de código, pruebas unitarias, análisis de código dinámico, pruebas de regresión, pruebas manuales, etc.

Por ejemplo, si estamos hablando de revisiones de código , es mucho mejor si el programa detecta errores simples. Luego, los programadores que revisen el código podrán centrarse en verificaciones de alto nivel más útiles del algoritmo, y no se verán obligados a leer las funciones de comparación . Además, como muestra la práctica , muchos errores son muy difíciles de detectar "con los ojos" y es muy probable que pasen desapercibidos durante la fase de revisión del código.

Otra ventaja de las herramientas de análisis estático es la presencia de una rica base de datos de patrones de error. Pueden encontrar problemas cuya existencia el programador podría no tener en cuenta. Algunos ejemplos: V698 , V718 , V1023 .

PVS-Studio

Recomendamos implementar el analizador de código estático PVS-Studio que desarrollamos en el proceso de desarrollo. El producto se ejecuta en sistemas de 64 bits en Windows, Linux y macOS y puede analizar código diseñado para plataformas ARM integradas y de 32 bits.

En el momento de la publicación de este artículo, el analizador admite los siguientes lenguajes y compiladores:

Ventanas Visual Studio 2010-2019 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
Ventanas IAR Embedded Workbench, compilador C / C ++ para ARM C, C ++
Ventanas Momentics QNX, QCC C, C ++
Windows / Linux Keil µVision, DS-MDK, compilador ARM 5/6 C, C ++
Windows / Linux Texas Instruments Code Composer Studio, Herramientas de generación de código ARM C, C ++
Windows / Linux / macOS. GNU Arm Embedded Toolchain, compilador Arm Embedded GCC, C, C ++
Windows / Linux / macOS. Clang C, C ++
Linux / macOS. CCG C, C ++
Ventanas MinGW C, C ++
Windows / Linux / macOS. Java

El analizador tiene documentación detallada en inglés y ruso. Las descripciones de las reglas de diagnóstico contienen ejemplos de código correcto e incorrecto, así como enlaces a ejemplos de errores reales encontrados en proyectos de código abierto.

Para la comodidad de los especialistas que utilizarán PVS-Studio como herramienta SAST , el analizador muestra sus advertencias sobre la Enumeración de Debilidad Común, los Estándares de Codificación SEI CERT y el estándar MISRA. Tablas de cumplimiento de diagnósticos de PVS-Studio a varios estándares:

El analizador se puede usar de forma independiente e integrarse con Visual Studio e IntelliJ IDEA. Además, recientemente algunos de nuestros clientes han estado utilizando PVS-Studio como parte de SonarQube. PVS-Studio, al estar conectado como un complemento a SonarQube, es una fuente adicional de mensajes de diagnóstico.

Se han resuelto varios escenarios de integración en CI. La consideración de todos los escenarios está más allá del alcance de este artículo y es mejor consultar la documentación. Aquí hay algunos enlaces para que el lector pueda hacer una impresión general:

El analizador PVS-Studio detecta efectivamente una amplia gama de errores, desde errores tipográficos hasta pérdidas de memoria . Esto es posible gracias al análisis de flujo de datos, ejecución simbólica, coincidencia de patrones, anotación de métodos (incluida la automática). Puede obtener más información acerca de los principios operativos en el artículo " Tecnologías utilizadas en el analizador de código PVS-Studio para encontrar errores y vulnerabilidades potenciales ".

¿Por qué deberías usar PVS-Studio?

Al introducir el analizador de código estático PVS-Studio en el proceso de desarrollo, reducirá el costo de corregir muchos errores. Esto libera tiempo para implementar nuevas funcionalidades o para pruebas de alto nivel más exhaustivas.

Con el uso regular del analizador, el código mejorará gradualmente, lo que facilitará su mantenimiento. La corrección sistemática de errores y la práctica de escribir código de alta calidad reducirá la probabilidad de detectar vulnerabilidades de día cero en el proyecto. Este tema se trata con más detalle en el artículo " ¿Cómo puede PVS-Studio ayudar en la búsqueda de vulnerabilidades? "

Usar la herramienta PVS-Studio es beneficioso en equipos de cinco o más personas. Puede familiarizarse con el método de cálculo de la eficiencia de uso del analizador en el artículo " ROI de PVS-Studio ".

Para proyectos desarrollados por uno o dos entusiastas, el analizador PVS-Studio probablemente será redundante. Sin embargo, también se puede usar en proyectos tan pequeños, especialmente porque ofrecemos varias opciones de licencias gratuitas para estudiantes, proyectos de código abierto, etc.

Muy a menudo, al principio, nuestros clientes adquieren una licencia por un año. Después de un año, cuando están convencidos de que las capacidades del analizador y su soporte están completamente satisfechas, renuevan la licencia por dos o tres años a la vez. Esto les permite obtener un descuento sustancial. Puede solicitar precios y consultar sobre cuestiones de licencia aquí .

Conviértete en nuestro cliente. Con PVS-Studio, aumentará la madurez del proceso de desarrollo, ahorrará dinero en la lucha contra errores y creará un mejor software.

Le proporcionaremos un soporte rápido y de calidad. Las preguntas son respondidas directamente por los programadores que desarrollan los módulos en los que surgió la pregunta. Esto ayuda a obtener respuestas incluso en situaciones difíciles. Un ejemplo de dicha comunicación es " Falsos positivos en PVS-Studio: cuán profundo es la madriguera del conejo ".

Respuestas de objeción

A veces, los programadores perciben negativamente la idea de introducir el análisis de código estático en el proceso de desarrollo, criticando la metodología del análisis estático en su conjunto o específicamente la herramienta PVS-Studio. Cuando comienza la discusión, resulta que la crítica no está justificada y se deriva simplemente de la falta de voluntad para cambiar algo en el proceso de desarrollo establecido. Considere los argumentos típicos para no cambiar nada y en qué consiste su debilidad.

"El análisis estático tomará parte del tiempo de trabajo"

La afirmación "el análisis estático ocupará parte del tiempo de trabajo" aislada del contexto es cierta. La revisión periódica de las advertencias del analizador estático emitidas para el código nuevo o modificado realmente lleva tiempo. Sin embargo, el pensamiento debe continuar: pero el tiempo dedicado a esto es mucho menor que el costo de identificar errores por otros métodos.

¿De dónde viene la opinión sobre la necesidad de pasar tiempo advirtiendo a los analizadores de código estático?

Los programadores aún no están familiarizados con la metodología de análisis de código confunden las ejecuciones de prueba y el uso regular. Al principio, cualquier analizador ofrece una gran lista de advertencias, muchas de las cuales son falsas. La razón es que el analizador aún no está configurado. Un analizador sintonizado genera una pequeña cantidad de falsos positivos durante los lanzamientos regulares. En otras palabras, con el uso regular, la mayoría de las advertencias detectarán defectos reales o un código de olor. Solo es importante hacer esta configuración.

Este tema se describe con más detalle en el artículo " Trabajar con objeciones: el análisis estático tomará parte del tiempo de trabajo ".

"El analizador estático es muy ruidoso (produce muchos falsos positivos)"

Como se mencionó anteriormente, esta conclusión se realiza utilizando un analizador de código no configurado. Después de configurar PVS-Studio, puede esperar que el porcentaje de falsos positivos sea del 10-20%. Es decir, con cinco advertencias emitidas, cuatro indicarán errores reales o un código que probablemente causará errores en el futuro. Un ejemplo de tal configuración se puede ver en el artículo " Especificaciones del analizador PVS-Studio utilizando el ejemplo EFL Core Libraries, 10-15% de falsos positivos ".

Otra razón que distorsiona la idea del analizador es el deseo de incluir tantas advertencias como sea posible, sin comprender su propósito. Por ejemplo, si habilita el conjunto de reglas MISRA centrado en sistemas integrados para una aplicación clásica de Windows, el analizador genera cientos de miles de advertencias. No habrá significado práctico en ellos. Los diagnósticos especialmente innecesarios interfieren en la etapa de conocimiento de la herramienta y forman un concepto erróneo sobre sus capacidades de diagnóstico. El artículo “ ¿Cómo ver rápidamente advertencias interesantes de que el analizador PVS-Studio para código C y C ++? ” Ayuda a evitar esto.

"Introducir el análisis estático en el proceso de desarrollo es muy difícil, largo y costoso"

Muy bien, estas preocupaciones se reflejan en este comentario:

Por desgracia, los analizadores estáticos en sí mismos no son más que juguetes. Introducirlos en el flujo de trabajo es un gran trabajo, debe seleccionar personas para procesar y filtrar los resultados. Los intentos de trasladar estas tareas a los hombros de los desarrolladores comunes generalmente terminan en nada.

No es tan aterrador. Existen al menos tres enfoques que le permiten implementar minuciosamente el análisis estático incluso en grandes proyectos antiguos.

Primer acercamiento. "Método de trinquete", que Ivan Ponomarev habla bien en su informe " Análisis continuo de código estático ".

Segundo enfoque Para comenzar a utilizar rápidamente el análisis estático, ofrecemos a los clientes de PVS-Studio que utilicen la " base de marcado ". La idea general es la siguiente. El usuario inició el analizador y recibió muchas advertencias. Dado que un proyecto que se ha desarrollado durante muchos años, está vivo, se desarrolla y aporta dinero, lo más probable es que no haya muchas advertencias en el informe que indiquen defectos críticos. En otras palabras, los errores críticos ya se han solucionado de una forma u otra de manera más costosa o gracias a los comentarios de los clientes. En consecuencia, todo lo que el analizador encuentra ahora puede considerarse una deuda técnica, lo cual no es práctico para tratar de eliminarlo de inmediato.

Puede decirle a PVS-Studio que considere estas advertencias como irrelevantes (posponga la deuda técnica para más adelante) y no las muestre nuevamente. El analizador crea un archivo especial donde almacena información sobre errores hasta ahora poco interesantes. Y ahora PVS-Studio emitirá advertencias solo en código nuevo o modificado. Además, todo esto se implementa de manera inteligente. Si, por ejemplo, se agrega una línea vacía al comienzo de un determinado archivo .cpp, el analizador comprende que, de hecho, nada ha cambiado y permanecerá en silencio. Este archivo de marcado se puede incrustar en el sistema de control de versiones. El archivo es grande, pero no da miedo, porque a menudo no tiene sentido colocarlo.

Ahora todos los programadores verán advertencias relacionadas solo con el código nuevo o modificado. Por lo tanto, el analizador puede comenzar a usar lo que se llama al día siguiente. Y será posible volver a la deuda técnica más tarde, y gradualmente corregir errores y configurar el analizador.

El tercer enfoque. Puede concluir un contrato con nosotros y delegar a nuestro equipo el trabajo de configurar e integrar el análisis estático. Un ejemplo de esta práctica: " Cómo el equipo de PVS-Studio mejoró el código de Unreal Engine ".

"Lanzamos el analizador y no encontramos nada interesante"

Esto es completamente posible, pero esto no significa que el analizador no sea útil. Lo que pasa es que los errores fueron corregidos por métodos más caros. Así es como tomar el texto de un libro, ya leído por varios revisores, y ver qué puede encontrar el corrector ortográfico integrado en Microsoft Word. Se encontrarán pequeños errores, pero de esto no se deduce que la función de verificación en Word no será útil al escribir nuevos textos.

Este tema se trata con más detalle en el artículo " Filosofía del análisis de código estático: tenemos 100 programadores, el analizador encontró pocos errores, ¿es inútil? ".

"Un analizador estático es costoso, es mejor contratar a otro programador / probador"

De hecho, esto significa que no desea cambiar nada. De hecho, antes de que el equipo creciera y se llenara con nuevos programadores y probadores. Sin embargo, esto no condujo a un aumento significativo en la madurez del proceso de desarrollo. No obstante, examinemos esta objeción con más detalle.

Primero, llevar a una persona adicional para buscar errores es mucho más costoso que comenzar a usar un analizador de código. Calcule el fondo salarial de una persona para el año. Agregar impuestos y disposición del lugar de trabajo. El argumento de que una licencia es costosa ya no es un argumento. Y aún así, el analizador estático, a diferencia de la persona, no se va de vacaciones, no está enfermo y no se va. Si hablamos de equipos grandes, por ejemplo, 100 personas, para obtener algún efecto, deberá contratar a varias personas. La brecha a favor del analizador estático se está ampliando.

En segundo lugar, el mayor efecto se logra debido a la sinergia del uso de diversas técnicas de búsqueda de errores. Algunos errores se detectan bien mediante pruebas unitarias, algunos con pruebas manuales, etc. Imagina la situación. El proyecto tiene 10 programadores, muchas pruebas unitarias están escritas, pero no hay evaluadores. La calidad del proyecto no se adapta a los usuarios y la idea es abrir un trabajo como probador. Pero esto no se hace con el pretexto "es mejor contratar a otro programador", ¡que haya más pruebas unitarias! De acuerdo, esta es la decisión equivocada. Obviamente, el proceso de garantía de calidad es unilateral y la adición de pruebas manuales traerá beneficios mucho mayores. La misma situación es con el análisis estático.

"El análisis dinámico es más eficiente que el estático".

Los analizadores estáticos encuentran bien algunos errores. Algunos son analizadores dinámicos. Estas herramientas se complementan entre sí y no tiene sentido elegir una cosa.

Por ejemplo, los analizadores dinámicos no pueden encontrar muchos errores tipográficos o detectar código inalcanzable. En el artículo " Validación del código de Valgrind Dynamic Analyzer con un analizador estático ", puede encontrar algunos de estos errores.

"Las pruebas unitarias son más eficientes que el análisis de código estático"

Si elige entre escribir pruebas unitarias y análisis estático, quizás las pruebas sean más importantes y útiles. Pero no es necesario tomar ninguna decisión. Es necesario utilizar pruebas unitarias y análisis de código estático. Estas metodologías de búsqueda de errores se complementan perfectamente.

El análisis estático complementará las pruebas unitarias por los siguientes motivos:

Nadie prueba las pruebas por sí mismo y a menudo contienen errores. En nuestros artículos, hemos citado repetidamente ejemplos de errores en el código de prueba unitaria. En consecuencia, el análisis estático puede encontrar errores en las pruebas, que, a su vez, pueden encontrar errores en el código de la aplicación principal.
Las pruebas son muy difíciles de cubrir todo el código. Especialmente cuando se trata de código para manejar situaciones de emergencia. Los analizadores estáticos verifican todo el código.
Algunos errores son imposibles o extremadamente difíciles de detectar con pruebas unitarias. Ejemplo: V597 (CWE-14) .
Algunos errores se manifiestan solo cuando se procesan grandes cantidades de datos, y las pruebas unitarias no son prácticas para modelar tales situaciones. Un ejemplo es el desbordamiento de una variable de 32 bits en un programa de 64 bits ( V108 , V127 ).
Es más fácil y rápido encontrar un error ejecutando un análisis estático que depurando el código cuando resulta que no funciona la prueba de la unidad. Por supuesto, las pruebas unitarias encontrarán más errores, pero si algunos de ellos se pueden encontrar de una manera más barata (análisis estático), ¿por qué no usarlo?
Encontramos una gran cantidad de errores en varios proyectos. Muchos de estos proyectos están bien cubiertos por las pruebas, pero como puede ver, esto no ayuda. Por lo tanto, no hay ninguna razón para no comenzar, además de las pruebas unitarias, también utilizando análisis de código estático, mejorando así su calidad y seguridad.

"Los compiladores gratuitos modernos pueden hacer lo mismo que PVS-Studio"

Sí, de hecho, los compiladores están evolucionando y se están implementando nuevas advertencias para ayudarlos a encontrar errores en el código. Sin embargo, no debe esperar demasiado de los compiladores, en comparación con las soluciones profesionales pagadas, como PVS-Studio.

Ventajas de PVS-Studio:

Soporte al usuario.
Infraestructura rica (integración con otros productos).
Capacidades de diagnóstico desarrolladas.

Los primeros dos puntos ya son suficientes para superar las escalas a favor de PVS-Studio. Sin embargo, hablemos de diagnósticos. Estamos desarrollando constantemente el analizador para adelantarnos a otras herramientas. Por ejemplo, podemos encontrar aquí un error tan interesante " 31 de febrero ".

Esto no es suficiente para convencer a los lectores escépticos. Por lo tanto, de vez en cuando verificamos otros compiladores y mostramos que PVS-Studio puede encontrar errores en ellos:

PS

Si todavía duda si usar PVS-Studio, observe qué errores y en qué proyectos logramos detectar .

Enlaces utiles

Si desea compartir este artículo con una audiencia de habla inglesa, utilice el enlace a la traducción: Andrey Karpov. Por qué debería elegir el analizador estático PVS-Studio para integrarlo en su proceso de desarrollo .

Razones para introducir el analizador de código estático PVS-Studio en el proceso de desarrollo