🤘🏿 🏟️ 👩🏼‍🔬 Por qué debería elegir el analizador estático PVS-Studio para integrarlo en su proceso de desarrollo 📥 🥫 🗡️

PVS-Studio es una herramienta para detectar errores y vulnerabilidades potenciales en el código fuente de programas escritos en C, C ++, C # o Java, y también es una herramienta de prueba de seguridad de aplicaciones estáticas (SAST). Está destinado a ser utilizado como parte de la práctica de CI y permite al usuario detectar errores en las primeras etapas de desarrollo, donde no cuesta casi nada solucionarlos.

Análisis de código estático

A medida que se desarrollan los proyectos de software, crecen en tamaño. Compara:

Linux kernel 1.0.0: 176,000 LOC
Linux kernel 5.0: 26,000,000 LOC
Photoshop 1.0: 128,000 LOC
Photoshop CS 6: 10,000,000 LOC

A medida que el proyecto crece, su complejidad crece más rápido que linealmente. Esto explica por qué la densidad de errores crece junto con la base de código. Una de las formas de compensar la creciente complejidad es utilizar herramientas de análisis de código estático.

Un analizador estático es una herramienta de software que realiza una revisión preliminar del código y señala fragmentos de código que es muy probable que contengan errores. Esto permite a los desarrolladores corregir la mayoría de los errores en la primera etapa de desarrollo, donde son más baratos de solucionar.

El análisis estático no reemplaza, sino que complementa, otras prácticas de detección de errores, como revisión de código, pruebas unitarias, análisis dinámico, pruebas de regresión, pruebas manuales, etc.

Tome la revisión de código , por ejemplo. Un escenario mucho mejor es hacer que un analizador de software encuentre los errores más triviales para que pueda enfocarse en verificaciones de alto nivel más útiles del algoritmo en lugar de descubrir funciones de comparación , más aún porque, como lo demuestra nuestra experiencia , el ojo humano es malo al notar muchos de los errores y es muy probable que se los pase por alto durante la revisión del código.

Otra ventaja de las herramientas de análisis estático es la extensa base de patrones de error. Pueden encontrar defectos que muchos programadores pueden no conocer, como V698 , V718 , V1023 .

PVS-Studio

Recomendamos elegir PVS-Studio, un analizador de código estático desarrollado por nuestro equipo. Se ejecuta en sistemas Windows, Linux y macOS de 64 bits y puede verificar el código fuente de los programas para plataformas ARM integradas y de 32 bits.

Al momento de escribir 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 viene con documentación detallada en inglés y ruso. Las descripciones de las reglas de diagnóstico incluyen ejemplos de código correcto e incorrecto. También incluyen enlaces a fragmentos de código de programas reales de código abierto.

Para aquellos especialistas que utilizarán PVS-Studio como herramienta SAST , los diagnósticos se asignan a la Enumeración de Debilidad Común, los Estándares de Codificación SEI CERT y el estándar MISRA. Aquí están las tablas de mapeo de diagnósticos PVS-Studio a diferentes estándares:

El analizador se puede usar como una herramienta independiente y como un complemento para Visual Studio e IntelliJ IDEA. Algunos de nuestros clientes también han estado utilizando PVS-Studio como parte de SonarQube últimamente. Cuando se utiliza como complemento para SonarQube, el analizador proporciona mensajes de diagnóstico adicionales.

Hemos desarrollado una serie de escenarios de uso de PVS-Studio con sistemas CI. Como observar todos los escenarios está fuera del alcance de este artículo, consulte la documentación. Aquí hay algunos enlaces para darle una idea general:

PVS-Studio detecta efectivamente una amplia gama de fallas desde errores tipográficos hasta pérdidas de memoria . Esto es posible gracias al análisis del flujo de datos, la ejecución simbólica, la coincidencia de patrones y la anotación de métodos (incluida la anotación automatizada). Para obtener más información sobre los principios de funcionamiento detrás del analizador, consulte 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

La integración de PVS-Studio en su proceso de desarrollo hará que muchos de los errores sean más baratos de solucionar, lo que ayudará a ahorrar tiempo, que podrá invertir en implementar una nueva característica o llevar a cabo pruebas de alto nivel más exhaustivas.

Si se usa regularmente, el analizador eventualmente lo ayudará a mejorar la calidad de su código, lo que facilitará su mantenimiento. La corrección regular de errores y la práctica de escribir código de alta calidad lo hará menos susceptible a las vulnerabilidades de día cero. Este tema se trata con más detalle en el artículo " ¿Cómo puede PVS-Studio ayudar en la detección de vulnerabilidades? ".

PVS-Studio es más rentable cuando lo usan equipos de cinco miembros y más. La estimación del ROI se proporciona en el artículo " PVS-Studio ROI ".

La integración de PVS-Studio en proyectos desarrollados por un par de entusiastas probablemente no sería práctico, pero incluso los proyectos pequeños pueden beneficiarse de ello, más aún ya que ofrecemos opciones de licencias gratuitas para estudiantes, desarrolladores de código abierto, etc.

Nuestros nuevos clientes generalmente comprarán una licencia de un año. Cuando caduque, ya están contentos con las capacidades de nuestro analizador y el servicio de soporte al usuario y renovarán la licencia por dos o tres años, lo cual es mucho más barato que la licencia de un año. Puede solicitar los precios y solicitar asesoramiento sobre licencias aquí .

Conviértase en nuestros clientes y deje que PVS-Studio haga que su proceso de desarrollo sea más maduro, la corrección de errores más barata y su código mejor.

En nuestro turno, le proporcionaremos un soporte rápido y competente. Sus preguntas serán abordadas directamente por los programadores que desarrollan los módulos particulares en cuestión. Esto garantiza obtener una respuesta incluso en las situaciones más complicadas. Aquí hay un ejemplo de este tipo: " Falsos positivos en PVS-Studio: cuán profundo es la madriguera del conejo ".

Respondiendo a las críticas

Los programadores a veces son negativos acerca de la idea de incluir el análisis de código estático en su proceso de desarrollo y critican el método de análisis estático en general o PVS-Studio en particular. A medida que comienza a profundizar, resulta que sus críticas son infundadas y es simplemente el producto de su renuencia a cambiar cualquier cosa en el proceso de desarrollo establecido. Veamos qué argumentos típicos para no cambiar la situación a la que recurren y qué les pasa.

"El análisis estático ocupará parte de su tiempo de trabajo"

Fuera de contexto, la afirmación "el análisis estático ocupará parte de su tiempo de trabajo" es cierta. Se necesita tiempo para examinar periódicamente las advertencias emitidas por el analizador para el código recién escrito o modificado. Pero esa idea debe continuar: "pero tomará mucho menos tiempo que otros métodos de detección de errores".

¿Por qué la gente cree que examinar el informe de un analizador estático lleva mucho tiempo?

Los programadores que aún no están familiarizados con el método de análisis de código confunden las ejecuciones de prueba únicas y el uso regular. Cuando se ejecuta por primera vez, cualquier analizador generará una gran lista de advertencias, con una alta tasa de falsos positivos. Esto sucede porque la herramienta aún no se ha personalizado. Con la configuración ajustada para satisfacer sus necesidades exactas, no verá muchos falsos positivos si ejecuta el analizador regularmente. En otras palabras, con el uso regular, la mayoría de los diagnósticos del analizador detectarán fallas genuinas o códigos de olor. Solo tienes que hacer ese ajuste.

El artículo " Manejo de objeciones: el análisis estático ocupará parte del tiempo de trabajo " desarrolla el tema.

"Los analizadores estáticos producen demasiado ruido (es decir, demasiados falsos positivos)"

Nuevamente, esta afirmación es cierta cuando no ha personalizado correctamente la herramienta. Una vez que haya ajustado la configuración de PVS-Studio según sea necesario, puede esperar que la tasa de falsos positivos baje al 10-20%. Es decir, de cada cinco advertencias, cuatro señalarán errores o códigos genuinos que es muy probable que se conviertan en la fuente de errores en el futuro. El artículo " Características del analizador PVS-Studio por el ejemplo de bibliotecas principales EFL, 10-15% de falsos positivos " muestra un ejemplo de personalización del analizador.

Otra fuente de ideas erróneas es la tentación de activar tantos diagnósticos como sea posible, sin conocer su propósito exacto. Por ejemplo, si activa el conjunto de reglas MISRA, que fue diseñado para sistemas integrados, cuando verifica una aplicación clásica de Windows, el analizador generará cientos de miles de advertencias, ninguna de las cuales le será de utilidad. Los diagnósticos irrelevantes son especialmente dañinos cuando solo está comenzando con la herramienta, ya que puede tener una impresión equivocada sobre sus capacidades de diagnóstico. El artículo " ¿Cómo consultar rápidamente las advertencias interesantes que ofrece el analizador PVS-Studio para el código C y C ++? " Le ayudará a evitar la decepción.

"Integrar el análisis estático en el proceso de desarrollo es demasiado costoso en términos de esfuerzo, tiempo y dinero"

Esta preocupación se ilustra vívidamente en el siguiente comentario:

Desafortunadamente, los analizadores estáticos en sí mismos no son más que juguetes. Es un gran trabajo tratar de hacerlos parte de su proceso de trabajo de rutina, y requiere asignar parte del personal para examinar y filtrar los resultados del análisis. Cualquier intento de colocar esta carga en los desarrolladores comunes generalmente no sirve de nada.

No es tan horrible. Existen al menos tres prácticas para integrar sin problemas el análisis estático incluso en grandes proyectos antiguos.

Práctica 1. "Trinquete", que Ivan Ponomarev explica muy bien en su artículo " Introduzca el análisis estático en el proceso, no solo busque errores con él ".

Práctica 2. Para ayudar a nuestros usuarios a comenzar rápidamente, recomendamos utilizar la " base de supresión ". En pocas palabras, la idea es que ejecute el analizador y obtenga múltiples advertencias. Dado que el proyecto ha estado en desarrollo durante muchos años y todavía está vivo, evolucionando y es rentable, no es probable que reciba muchas advertencias que apuntan a defectos críticos. En otras palabras, la mayoría de los errores críticos ya se han solucionado utilizando otros medios, más caros, o en respuesta a los comentarios de los usuarios. En ese caso, cualquier error encontrado durante la primera verificación, puede verse como una deuda técnica, lo que no sería razonable apresurarse a solucionar de inmediato.

Puede decirle a PVS-Studio que trate estas advertencias como irrelevantes (posponiendo así la resolución de la deuda técnica hasta más tarde) y no las muestre nuevamente. El analizador creará un archivo especial que almacenará la información sobre errores actualmente irrelevantes y emitirá advertencias solo para el código recién escrito o modificado. El mecanismo es bastante inteligente. Por ejemplo, si agrega una línea vacía al comienzo de algún archivo .cpp, el analizador comprenderá que esta línea no hace ninguna diferencia y se mantendrá en silencio. El archivo de supresión puede ser controlado por versión. Es grande, pero no importa porque no es necesario controlarlo a menudo.

Después de eso, cada programador de su equipo recibirá solo las advertencias activadas por código recién escrito o modificado. A partir del día siguiente, podrá usar el analizador como parte de su trabajo de rutina. En cuanto a la deuda técnica, podrá acceder a ella más tarde y corregir gradualmente los errores y ajustar la configuración del analizador según sea necesario.

Práctica 3. Puede delegar la tarea de configurar e integrar PVS-Studio a nuestro equipo al redactar un contrato con nosotros. Un ejemplo de esta práctica se describe en el artículo " Cómo el equipo de PVS-Studio mejoró el código de Unreal Engine ".

"Ejecutamos el analizador pero no encontramos nada de interés"

Este escenario es bastante posible, pero todavía no significa que el analizador no vaya a ser de ninguna utilidad. El problema es que los errores ya se han encontrado y corregido utilizando otros medios más caros. Es como alimentar un texto ya revisado por un grupo de correctores de pruebas a Microsoft Word para ver si su corrector ortográfico incorporado podría encontrar algo. Encontraría solo algunos errores, si es que los hay, pero eso no significa que el corrector ortográfico de Word sea inú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 desarrolladores, el analizador encontró algunos errores, ¿es inútil el analizador? ".

"Un analizador estático es una herramienta costosa; será mejor que contratemos un programador / probador adicional »

Lo que este argumento realmente dice es que la persona no quiere cambiar nada. Después de todo, su equipo ha estado creciendo y contratando nuevos programadores y probadores durante algún tiempo, pero eso no ayudó a lograr un proceso de desarrollo más maduro. Dicho esto, aún deberíamos elaborar este argumento.

Primero, contratar a otra persona para la búsqueda de errores es mucho más costoso que comprar un analizador estático. Simplemente calcule la nómina anual del nuevo empleado y agregue los impuestos y gastos al configurar un nuevo espacio de trabajo. Teniendo en cuenta las cifras resultantes, el argumento acerca de que un analizador de software es demasiado costoso no parece ser un argumento en absoluto. Además, un analizador estático, a diferencia de los humanos, no se tomará vacaciones ni se irá de baja por enfermedad ni abandonará la empresa por completo. Para un equipo grande, digamos, 100 personas, tendría que contratar no solo uno sino varios empleados nuevos para lograr un resultado notable. En ese caso, comprar un analizador estático se convierte en una solución aún más favorable.

Segundo, el mejor resultado se logra a través de la sinergia entre varias técnicas de detección de errores utilizadas en combinación. Algunos errores se diagnostican mejor mediante pruebas unitarias, otros mediante pruebas manuales, etc. Imagine tener 10 programadores trabajando en un proyecto, con muchas pruebas unitarias pero sin un solo probador. Los usuarios no están satisfechos con la calidad del proyecto, por lo que se te ocurre contratar un probador, pero no lo haces porque "será mejor que contratemos un programador adicional, ¡que haya más pruebas unitarias!" No se puede llamar una decisión sabia, ¿verdad? En este escenario, el proceso de control de calidad es obviamente de una sola pierna y solo se obtendría agregando pruebas manuales. Lo mismo es cierto para el análisis estático.

"El análisis dinámico es mejor que el análisis estático"

Algunos errores se diagnostican mejor con analizadores estáticos, otros con analizadores dinámicos. Este tipo de herramientas se complementan entre sí, por lo que no tiene que elegir solo una.

Por ejemplo, los analizadores dinámicos no pueden detectar código inalcanzable y muchos de los errores causados por errores tipográficos. Algunos de los tipos de errores de análisis dinámico tienen dificultades para encontrar se describen en el artículo " Comprobación del código del analizador dinámico Valgrind por un analizador estático ".

"Las pruebas unitarias son mejores que el análisis estático"

Si tuviera que elegir entre escribir pruebas unitarias y usar análisis estático, diría que las pruebas son más importantes y valiosas. Pero no tienes que elegir; debe usar tanto pruebas unitarias como análisis estáticos. Estas técnicas funcionan muy bien juntas.

Estos son los argumentos para usar el análisis estático junto con las pruebas unitarias:

Las pruebas en sí mismas no se prueban y a menudo contienen errores. En nuestros artículos, mostramos muchos ejemplos de errores encontrados en pruebas unitarias en proyectos reales. El análisis estático puede encontrar errores en las pruebas, que, a su vez, pueden encontrar errores en el código principal.
Es difícil cubrir todo el código con pruebas, especialmente aquellas partes que se ocupan del manejo de excepciones. A diferencia de ellos, los analizadores estáticos verifican todo el código.
Algunos errores son extremadamente difíciles, si es posible, de detectar a través de pruebas unitarias. V597 (CWE-14) es uno de esos ejemplos.
Algunos errores se manifiestan solo cuando el programa funciona con grandes cantidades de datos, por lo que no es práctico simular tales situaciones en pruebas unitarias. Un ejemplo de esto es un desbordamiento de una variable de 32 bits en un programa de 64 bits ( V108 , V127 ).
Cuando una prueba no pasa, el error se puede encontrar más fácil y rápidamente ejecutando el analizador estático que depurando. Claro, las pruebas unitarias encontrarían más errores, pero cuando puede atraparlos utilizando una técnica más barata (es decir, análisis estático), ¿por qué no hacerlo?
Encontramos montones de errores en varios proyectos. Muchos de ellos están muy cubiertos con pruebas, pero, como puede ver, no ayudan mucho. Por lo tanto, no hay ninguna razón por la que no deba adoptar el análisis estático además de las pruebas unitarias para mejorar la calidad y confiabilidad de su código.

"Los compiladores gratuitos contemporáneos pueden encontrar los mismos errores que PVS-Studio puede"

Claro, los compiladores están evolucionando y adquiriendo nuevas advertencias, que pueden detectar errores. Pero no puede esperar mucho de los compiladores en comparación con soluciones propietarias profesionales como PVS-Studio.

Razones para ir a PVS-Studio:

Soporte eficiente al usuario
Infraestructura altamente desarrollada (integración con otros productos)
Potentes capacidades de diagnóstico

Las dos primeras razones ya son suficientes para inclinar la balanza hacia la elección de PVS-Studio, pero hablemos también de los diagnósticos. Mejoramos constantemente nuestro producto para adelantarnos a otros proveedores. Por ejemplo, nuestra herramienta puede detectar un error interesante descrito en el artículo " 31 de febrero ".

Teniendo en cuenta que todo lo mencionado anteriormente no es suficiente para hacer que los escépticos cambien de opinión, revisamos los compiladores de vez en cuando para mostrar que ellos también tienen errores que PVS-Studio puede detectar:

PS

Si todavía duda si debe usar PVS-Studio, solo mire esta lista de errores que ha encontrado en varios proyectos .

Por qué debería elegir el analizador estático PVS-Studio para integrarlo en su proceso de desarrollo