🏜️ 🌱 👸🏾 Pourquoi choisir l'analyseur statique PVS-Studio à intégrer dans votre processus de développement 👩🏼‍💼 🎤 👿

PVS-Studio est un outil pour détecter les bogues et les vulnérabilités potentielles dans le code source des programmes écrits en C, C ++, C # ou Java, et est également un outil SAST (Static Application Security Testing). Il est destiné à être utilisé dans le cadre de la pratique de CI et permet à l'utilisateur de détecter les bogues aux premiers stades de développement, où ils ne coûtent presque rien à corriger.

Analyse de code statique

À mesure que les projets logiciels se développent, leur taille augmente. Comparez:

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

À mesure que le projet se développe, sa complexité augmente plus rapidement que linéairement. Cela explique pourquoi la densité d'erreurs augmente avec la base de code. L'une des façons de compenser la complexité croissante consiste à utiliser des outils d'analyse de code statique.

Un analyseur statique est un outil logiciel qui effectue une révision préliminaire du code et signale les fragments de code qui sont très susceptibles de contenir des erreurs. Cela permet aux développeurs de corriger la plupart des bogues au stade de développement le plus précoce, où ils sont les moins chers à corriger.

L'analyse statique ne remplace pas - mais complète plutôt - d'autres pratiques de détection de bogues telles que la révision de code, les tests unitaires, l'analyse dynamique, les tests de régression, les tests manuels, etc.

Prenons l'exemple de la révision du code . Un bien meilleur scénario consiste à demander à un analyseur de logiciels de trouver les bogues les plus triviaux pour que vous puissiez vous concentrer sur des vérifications de haut niveau plus utiles de l'algorithme plutôt que de trouver des fonctions de comparaison - d'autant plus que, comme notre expérience le prouve, l'œil humain ne reconnaît pas bon nombre des bogues et ils sont très susceptibles d'être ignorés lors de la révision du code.

Un autre avantage des outils d'analyse statique est la vaste base de modèles d'erreurs. Ils peuvent trouver des défauts que de nombreux programmeurs ne connaissent peut-être même pas, tels que V698 , V718 , V1023 .

PVS-Studio

Nous vous recommandons de choisir PVS-Studio, un analyseur de code statique développé par notre équipe. Il s'exécute sur les systèmes Windows, Linux et macOS 64 bits et peut vérifier le code source des programmes pour les plates-formes ARM 32 bits, 64 bits et intégrées.

Au moment de la rédaction de cet article, l'analyseur prend en charge les langages et compilateurs suivants:

Windows Visual Studio 2010-2019 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
Windows IAR Embedded Workbench, compilateur C / C ++ pour ARM C, C ++
Windows QNX Momentics, QCC C, C ++
Windows / Linux Keil µVision, DS-MDK, ARM Compiler 5/6 C, C ++
Windows / Linux Texas Instruments Code Composer Studio, Outils de génération de code ARM C, C ++
Windows / Linux / macOS. GNU Arm Embedded Toolchain, compilateur Arm Embedded GCC, C, C ++
Windows / Linux / macOS. Clang C, C ++
Linux / macOS. GCC C, C ++
Windows MinGW C, C ++
Windows / Linux / macOS. Java

L'analyseur est livré avec une documentation détaillée en anglais et en russe. Les descriptions des règles de diagnostic incluent des exemples de code correct et incorrect. Ils incluent également des liens vers des extraits de code provenant de vrais programmes open source.

Pour les spécialistes qui vont utiliser PVS-Studio comme outil SAST , les diagnostics sont mappés sur l'énumération commune des faiblesses, les normes de codage SEI CERT et la norme MISRA. Voici les tableaux de correspondance des diagnostics PVS-Studio avec différentes normes:

L'analyseur peut être utilisé à la fois comme outil autonome et comme plug-in pour Visual Studio et IntelliJ IDEA. Certains de nos clients utilisent également PVS-Studio dans le cadre de SonarQube ces derniers temps. Lorsqu'il est utilisé comme plug - in pour SonarQube, l'analyseur fournit des messages de diagnostic supplémentaires.

Nous avons développé un certain nombre de scénarios d'utilisation de PVS-Studio avec des systèmes CI. Étant donné que l'observation de tous les scénarios n'entre pas dans le cadre de cet article, reportez-vous à la documentation. Voici quelques liens pour vous donner une idée générale:

PVS-Studio détecte efficacement un large éventail de défauts, des fautes de frappe aux fuites de mémoire . Cela est possible grâce à l'analyse du flux de données, l'exécution symbolique, la correspondance de modèle et l'annotation de méthode (y compris l'annotation automatisée). Pour en savoir plus sur les principes de fonctionnement de l'analyseur, consultez l'article " Technologies utilisées dans l'analyseur de code PVS-Studio pour trouver des bogues et des vulnérabilités potentielles ".

Pourquoi devriez-vous utiliser PVS-Studio

L'intégration de PVS-Studio dans votre processus de développement rendra bon nombre de bogues moins coûteux à corriger, contribuant ainsi à gagner du temps, que vous pourrez investir dans la mise en œuvre d'une nouvelle fonctionnalité ou la réalisation de tests de haut niveau plus approfondis.

S'il est utilisé régulièrement, l'analyseur vous aidera éventuellement à améliorer la qualité de votre code, facilitant ainsi sa maintenance. La correction régulière des bogues et la pratique de l'écriture de code de haute qualité le rendront moins vulnérable aux vulnérabilités Zero-day. Ce sujet est traité plus en détail dans l'article " Comment PVS-Studio peut-il aider à détecter les vulnérabilités? ".

PVS-Studio est plus rentable lorsqu'il est utilisé par des équipes de cinq membres et plus. L'estimation du ROI est donnée dans l'article " PVS-Studio ROI ".

L'intégration de PVS-Studio dans des projets développés par quelques passionnés serait probablement peu pratique, mais même les petits projets peuvent en bénéficier - d'autant plus que nous proposons des options de licence gratuites pour les étudiants, les développeurs open-source, etc.

Nos nouveaux clients achèteront généralement une licence d'un an. À son expiration, ils sont déjà satisfaits des capacités de notre analyseur et du service d'assistance aux utilisateurs et renouvelleront la licence pour deux ou trois ans, ce qui est beaucoup moins cher que la licence d'un an. Vous pouvez demander les prix et demander des conseils sur les licences ici .

Devenez nos clients et laissez PVS-Studio rendre votre processus de développement plus mature, la correction des bogues moins cher et votre code meilleur.

À notre tour, nous vous fournirons un support rapide et compétent. Vos questions seront adressées directement par les programmeurs développant les modules particuliers en question. Cela garantit d'obtenir une réponse même dans les situations les plus compliquées. Voici un exemple: " Faux positifs dans PVS-Studio: à quelle profondeur le trou du lapin va ."

Répondre aux critiques

Les programmeurs sont parfois négatifs sur l'idée d'inclure l'analyse de code statique dans leur processus de développement et critiquent la méthode d'analyse statique en général ou PVS-Studio en particulier. Lorsque vous commencez à creuser plus profondément, il s'avère que leurs critiques ne sont pas fondées et sont simplement le produit de leur réticence à changer quoi que ce soit dans le processus de développement établi. Voyons quels sont les arguments typiques pour ne pas changer la situation dans laquelle ils ont recours et ce qui ne va pas.

"L'analyse statique occupera une partie de votre temps de travail"

Hors contexte, l'énoncé «l'analyse statique occupera une partie de votre temps de travail» est vrai. Il faut du temps pour examiner régulièrement les avertissements émis par l'analyseur pour le code nouvellement écrit ou modifié. Mais cette idée doit être poursuivie: "mais cela prendra beaucoup moins de temps que les autres méthodes de détection de bogues".

Pourquoi les gens pensent-ils que l'examen d'un rapport d'analyseur statique prend du temps?

Les programmeurs qui ne sont pas encore familiarisés avec la méthode d'analyse de code confondent les exécutions de tests uniques et l'utilisation régulière. Lorsqu'il est exécuté pour la première fois, tout analyseur génère une énorme liste d'avertissements, avec un taux élevé de faux positifs. Cela se produit car l'outil n'a pas encore été personnalisé. Avec les paramètres modifiés pour répondre à vos besoins exacts, vous ne verrez pas beaucoup de faux positifs si vous exécutez l'analyseur régulièrement. En d'autres termes, avec une utilisation régulière, la plupart des diagnostics de l'analyseur détecteront de véritables défauts ou une odeur de code. Vous n'avez qu'à faire ce réglage.

L'article « Gérer les objections: l'analyse statique occupera une partie du temps de travail » développe le sujet.

"Les analyseurs statiques produisent trop de bruit (c'est-à-dire trop de faux positifs)"

Encore une fois, cette affirmation est vraie lorsque vous n'avez pas correctement personnalisé l'outil. Une fois que vous avez modifié les paramètres de PVS-Studio selon vos besoins, vous pouvez vous attendre à ce que le taux de faux positifs chute à 10-20%. Autrement dit, sur cinq avertissements, quatre indiqueront de véritables bogues ou du code qui deviendront très probablement la source de bogues à l'avenir. L'article " Caractéristiques de l'analyseur PVS-Studio par l'exemple des bibliothèques EFL Core, 10-15% de faux positifs " montre un exemple de personnalisation de l'analyseur.

Une autre source d'idées fausses est la tentation d'activer autant de diagnostics que possible, sans connaître leur objectif exact. Par exemple, si vous activez l'ensemble de règles MISRA, qui a été conçu pour les systèmes intégrés, lors de la vérification d'une application Windows classique, l'analyseur générera des centaines de milliers d'avertissements, dont aucun ne vous sera d'aucune utilité. Les diagnostics non pertinents sont particulièrement dangereux lorsque vous ne faites que commencer avec l'outil, car vous risquez de vous faire une mauvaise idée de ses capacités de diagnostic. L'article " Comment vérifier rapidement les avertissements intéressants donnés par l'analyseur PVS-Studio pour le code C et C ++? " Vous aidera à éviter la déception.

"L'intégration de l'analyse statique dans le processus de développement est trop coûteuse en termes d'efforts, de temps et d'argent"

Cette préoccupation est clairement illustrée par le commentaire suivant:

Malheureusement, les analyseurs statiques eux-mêmes ne sont rien d'autre que des jouets. C'est un sacré travail d'essayer de les intégrer à votre processus de travail de routine, et cela nécessite d'affecter une partie du personnel à l'examen et au filtrage des résultats de l'analyse. Toute tentative de placer ce fardeau sur les développeurs ordinaires est généralement vaine.

Ce n'est pas si horrible. Il existe au moins trois pratiques pour intégrer en douceur l'analyse statique, même dans les grands projets anciens.

Pratique 1. "Ratcheting", qui est bien expliqué par Ivan Ponomarev dans son article " Introduire l'analyse statique dans le processus, ne vous contentez pas de rechercher des bogues ".

Pratique 2. Pour aider nos utilisateurs à démarrer rapidement, nous vous recommandons d'utiliser la " base de suppression ". En résumé, l'idée est que vous exécutez l'analyseur et obtenez plusieurs avertissements. Étant donné que le projet est en développement depuis de nombreuses années et qu'il est toujours en vie, en évolution et rentable, vous ne recevrez probablement pas de nombreux avertissements indiquant des défauts critiques. En d'autres termes, la plupart des bogues critiques ont déjà été corrigés en utilisant d'autres moyens - plus chers - ou en réponse aux commentaires des utilisateurs. Dans ce cas, quels que soient les bogues détectés lors de la première vérification, ils peuvent être considérés comme une dette technique, ce qui serait déraisonnable de se précipiter pour les corriger immédiatement.

Vous pouvez demander à PVS-Studio de traiter ces avertissements comme non pertinents (retardant ainsi la résolution de la dette technique pour plus tard) et de ne plus les afficher. L'analyseur créera un fichier spécial stockant les informations sur les bogues actuellement non pertinents et émettra des avertissements uniquement pour le code fraîchement écrit ou modifié. Le mécanisme est assez intelligent. Par exemple, si vous ajoutez une ligne vide au début d'un fichier .cpp, l'analyseur comprendra que cette ligne ne fait aucune différence et restera silencieux. Le fichier de suppression peut être contrôlé par version. Il est grand, mais cela n'a pas d'importance car vous n'avez pas besoin de le contrôler souvent.

Après cela, chaque programmeur de votre équipe ne recevra que les avertissements déclenchés par du code fraîchement écrit ou modifié. À partir du lendemain, vous pourrez utiliser l'analyseur dans le cadre de votre travail de routine. Quant à la dette technique, vous pourrez y accéder plus tard et corriger progressivement les bugs et ajuster les paramètres de l'analyseur au besoin.

Pratique 3. Vous pouvez déléguer la tâche de configuration et d'intégration de PVS-Studio à notre équipe en établissant un contrat avec nous. Un exemple de cette pratique est décrit dans l'article " Comment l'équipe PVS-Studio a amélioré le code d'Unreal Engine ".

"Nous avons fait fonctionner l'analyseur mais nous n'avons rien trouvé d'intéressant"

Ce scénario est tout à fait possible mais cela ne signifie toujours pas que l'analyseur ne sera d'aucune utilité. Le problème est que les bogues ont déjà été trouvés et corrigés en utilisant d'autres moyens plus chers. C'est comme alimenter un texte déjà vérifié par un groupe de correcteurs à Microsoft Word pour voir si sa vérification orthographique intégrée pourrait trouver quelque chose. Il ne trouverait que quelques erreurs, voire aucune, mais cela ne signifie pas que la vérification orthographique de Word est inutile lors de l'écriture de nouveaux textes.

Ce sujet est abordé plus en détail dans l'article " Philosophie de l'analyse de code statique: nous avons 100 développeurs, l'analyseur a trouvé quelques bogues, l'analyseur est-il inutile? ".

"Un analyseur statique est un outil coûteux; nous ferions mieux d'embaucher un programmeur / testeur supplémentaire »

Ce que cet argument dit vraiment, c'est que la personne ne veut rien changer. Après tout, leur équipe s'est développée et embauche de nouveaux programmeurs et testeurs depuis un certain temps déjà, mais cela n'a pas aidé à atteindre un processus de développement plus mature. Cela dit, nous devons encore développer cet argument.

Tout d'abord, l'embauche d'une autre personne pour la recherche de bogues est beaucoup plus coûteuse que l'achat d'un analyseur statique. Il suffit de calculer la masse salariale annuelle du nouvel employé et d'ajouter les taxes et les dépenses lors de la configuration d'un nouvel espace de travail. Compte tenu des chiffres qui en résultent, l'argument selon lequel un analyseur logiciel est trop cher ne semble pas du tout un argument. En outre, un analyseur statique, contrairement aux humains, ne prendra pas de vacances, ne partira pas pour maladie ou ne quittera pas l'entreprise. Pour une grande équipe, disons 100 personnes, il faudrait embaucher non pas un, mais plusieurs nouveaux employés pour obtenir un résultat notable. Dans ce cas, l'achat d'un analyseur statique devient une solution encore plus favorable.

Deuxièmement, le meilleur résultat est obtenu grâce à la synergie entre les différentes techniques de détection de bogues utilisées en combinaison. Certains bogues sont mieux diagnostiqués par des tests unitaires, d'autres par des tests manuels, etc. Imaginez avoir 10 programmeurs travaillant sur un projet, avec beaucoup de tests unitaires mais pas un seul testeur. Les utilisateurs ne sont pas satisfaits de la qualité du projet, donc vous pensez engager un testeur, mais vous ne le faites pas parce que "nous ferions mieux d'embaucher un programmeur supplémentaire, qu'il y ait encore plus de tests unitaires!" ne pas être appelé une sage décision, n'est-ce pas? Dans ce scénario, le processus d'AQ est évidemment unidirectionnel et ne gagnerait qu'en ajoutant des tests manuels. Il en va de même pour l'analyse statique.

"L'analyse dynamique est meilleure que l'analyse statique"

Certains bogues sont mieux diagnostiqués par des analyseurs statiques, d'autres par des analyseurs dynamiques. Ces types d'outils se complètent , vous n'avez donc pas à en choisir un seul.

Par exemple, les analyseurs dynamiques ne peuvent pas détecter le code inaccessible et la plupart des bogues causés par les fautes de frappe. Certains des types d'analyses dynamiques de bogues qui ont du mal à trouver sont décrits dans l'article " Vérification du code de l'analyseur dynamique Valgrind par un analyseur statique ".

"Les tests unitaires sont meilleurs que l'analyse statique"

Si vous deviez choisir entre écrire des tests unitaires et utiliser une analyse statique, je dirais que les tests sont plus importants et précieux. Mais vous n'avez pas à choisir; vous devez utiliser à la fois les tests unitaires et l'analyse statique. Ces techniques fonctionnent très bien ensemble.

Voici les arguments pour utiliser l'analyse statique avec les tests unitaires:

Les tests eux-mêmes ne sont pas testés et contiennent souvent des erreurs. Dans nos articles, nous montrons de nombreux exemples de bogues trouvés dans les tests unitaires dans les projets réels. L'analyse statique peut trouver des bogues dans les tests qui, à leur tour, peuvent trouver des bogues dans le code principal.
Il est difficile de couvrir l'ensemble du code avec des tests, en particulier les parties qui traitent de la gestion des exceptions. Contrairement à eux, les analyseurs statiques vérifient l'intégralité du code.
Certains bogues sont extrêmement difficiles, si possible du tout, à détecter grâce à des tests unitaires. V597 (CWE-14) en est un exemple.
Certains bogues ne se manifestent que lorsque le programme fonctionne avec de grandes quantités de données, il est donc impossible de simuler de telles situations dans des tests unitaires. Un tel exemple est le débordement d'une variable 32 bits dans un programme 64 bits ( V108 , V127 ).
Lorsqu'un test échoue, l'erreur peut être trouvée plus facilement et plus rapidement en exécutant l'analyseur statique qu'en déboguant. Bien sûr, les tests unitaires trouveraient plus de bogues, mais quand vous pouvez les attraper en utilisant une technique moins chère (c'est-à-dire une analyse statique), pourquoi ne pas le faire?
On trouve des tas de bugs dans divers projets. Beaucoup d'entre eux sont fortement couverts par des tests mais, comme vous pouvez le voir, ils n'aident pas beaucoup. Il n'y a donc aucune raison de ne pas adopter l'analyse statique en plus des tests unitaires pour améliorer la qualité et la fiabilité de votre code.

"Les compilateurs gratuits contemporains peuvent trouver les mêmes bogues que PVS-Studio"

Bien sûr, les compilateurs évoluent et acquièrent de nouveaux avertissements, qui peuvent détecter des bogues. Mais vous ne pouvez pas vous attendre à beaucoup de compilateurs par rapport aux solutions propriétaires professionnelles telles que PVS-Studio.

Raisons d'opter pour PVS-Studio:

Support utilisateur efficace
Infrastructure hautement développée (intégration avec d'autres produits)
De puissantes capacités de diagnostic

Les deux premières raisons sont déjà suffisantes pour faire pencher la balance vers le choix de PVS-Studio, mais parlons également des diagnostics. Nous améliorons constamment notre produit pour garder une longueur d'avance sur les autres fournisseurs. Par exemple, notre outil peut détecter un bug intéressant décrit dans l'article " 31 février ".

Sachant que tout ce qui précède ne suffit pas à faire changer d'avis les sceptiques, nous vérifions de temps en temps les compilateurs pour montrer qu'ils ont aussi des bogues que PVS-Studio peut détecter:

PS

Si vous ne savez toujours pas si vous devez utiliser PVS-Studio, regardez simplement cette liste des bogues trouvés dans divers projets .

Pourquoi choisir l'analyseur statique PVS-Studio à intégrer dans votre processus de développement