Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>

Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>
Aller à la section
Un faux positif survient lorsqu'un outil d'analyse statique prétend à tort qu'une règle statique a été enfreinte. Cet article aborde en détail les faux positifs et l'analyse de code statique.
Aller à la section
Aller à la section
« Trop de faux positifs » est probablement l'excuse la plus courante pour éviter l'analyse statique. Mais l'analyse statique n'a pas besoin d'être si bruyante.
Il y a des années, le plus grand défi de logiciel d'analyse statique essayait de trouver de plus en plus de choses intéressantes à vérifier. Dans le produit CodeWizard original de Parasoft au début des années 90, nous avions une trentaine de règles basées sur des éléments du livre de Scott Meyers, C ++ efficace. C'est ce que j'aime à penser comme "Effrayé tout droit pour les programmeurs. J'en ai parlé une fois à Scott, et bien qu'il n'y ait pas pensé de cette façon, cela lui a fait bien rire.
Depuis lors, les chercheurs en analyse statique ont constamment travaillé pour repousser les limites de ce qui peut être détecté, en élargissant ce que l'analyse statique peut faire et en identifiant les défauts plutôt qu'un simple morceau de code faible. Mais il souffre toujours de faux positifs. L'analyse statique a changé l'orientation de l'utilisateur, du durcissement du code à la recherche de bogues, ce qui est formidable, mais maintenant l'un des obstacles les plus courants rencontrés par les utilisateurs avec l'analyse de code statique est d'essayer de donner un sens aux résultats qu'ils obtiennent.
Bien que les gens disent : « J'aimerais que l'analyse statique attrape ____ » (nommez votre bogue introuvable préféré). Il est beaucoup plus courant d'entendre : "Wow, j'ai beaucoup trop de résultats !" ou "L'analyse statique est bruyante !" ou "Les faux positifs de l'analyse statique sont accablants !" Ainsi, en tant qu'organisation de test de logiciels, il est de notre devoir de continuer à résoudre ce problème pour nos clients, de continuer à fournir des outils et des fonctionnalités qui vous aident à trier les résultats que vous obtenez et à comprendre quels problèmes représentent le plus de risques.
Les outils d'analyse statique profitent aux développeurs en trouvant des bogues, des vulnérabilités de sécurité et en codant des écarts-types qui sont autrement fastidieux à trouver ou à appliquer.
Les outils d'analyse statique et de test de sécurité des applications statiques (SAST) offrent aux équipes de développement les avantages suivants.
L'analyse statique et le SAST ne sont pas des solutions miracles. En fait, Parasoft encourage les clients à utiliser l'analyse statique en conjonction avec d'autres méthodes de test comme les tests unitaires, les tests de régression, etc. Les solutions d'analyse statique comme Parasoft ont d'excellents retours sur investissement, cependant, il est logique d'en comprendre les limites.
Dans le contexte de l'analyse statique, un faux positif se produit lorsqu'un outil d'analyse statique signale à tort qu'une règle d'analyse statique a été violée. Bien sûr, cela peut être subjectif. Parfois, les développeurs tombent dans le piège d'étiqueter tout message d'erreur qu'ils n'aiment pas comme un faux positif, mais ce n'est pas vraiment correct.
Dans de nombreux cas, ils ne sont tout simplement pas d'accord avec la règle, ne comprennent pas comment elle s'applique à la situation ou ne pensent pas que ce soit important en général. j'appellerais ça bruit, plutôt qu'un faux positif. La chose amusante que j'ai trouvée ici est que plus l'outil est intelligent, plus il est susceptible de produire une conclusion qu'un développeur pourrait ne pas comprendre à première vue.
L'analyse statique basée sur des modèles n'a pas réellement de faux positifs. Si l'outil signale qu'une règle d'analyse statique a été violée alors qu'elle ne l'était pas, cela indique un bogue dans la règle car la règle ne doit pas être ambiguë. Si la règle n'a pas de modèle clair à rechercher, c'est une mauvaise règle.
Je ne dis pas que chaque violation de règle signalée indique la présence d'un défaut. Une violation signifie que le modèle a été trouvé, indiquant une faiblesse dans le code, une susceptibilité à avoir un défaut.
Quand je regarde une violation, je me demande si oui ou non cette règle s'applique à mon code. Si c'est le cas, je corrige le code. Si ce n'est pas le cas, je supprime la violation. Il est préférable de supprimer directement les violations d'analyse statique dans le code afin qu'il soit visible pour les membres de l'équipe et que vous n'ayez pas à le revoir une seconde fois. Sinon, vous passerez constamment en revue la même violation encore et encore ; c'est comme essayer de vérifier l'orthographe mais sans jamais ajouter vos mots "spéciaux" à son dictionnaire.
La beauté de la suppression dans le code est qu'elle est indépendante du moteur d'analyse statique. N'importe qui peut regarder le code et voir que le code a été revu et que ce modèle est jugé acceptable dans ce code. Ceci est particulièrement utile si vous devez prouver la conformité à une norme de codage. Et si vous avez effectivement besoin de conformité, il est facile d'utiliser une configuration existante pour ces normes telles que CWE, MISRA, IEC 62304, DO-178Cet plus encore.
Avec l'analyse basée sur les flux, les faux positifs ne sont pas seulement inhérents à la méthode, mais également pertinents - et doivent être traités. L'analyse de flux ne peut pas éviter les faux positifs pour la même raison que les tests unitaires ne peuvent pas générer des cas de test unitaires parfaits. L'analyse doit déterminer le comportement attendu du code. Parfois, il y a trop d'options pour savoir ce qui est réaliste; parfois, vous n'avez tout simplement pas assez d'informations sur ce qui se passe dans d'autres parties du système.
La chose importante ici est que le vrai faux positif est quelque chose qui est complètement faux. Par exemple, supposons que l'outil d'analyse statique que vous utilisez indique que vous lisez un pointeur nul. Si vous regardez le code et voyez que c'est réellement impossible, alors vous avez un faux positif.
D'un autre côté, si vous n'êtes tout simplement pas inquiet des valeurs nulles dans ce morceau de code parce qu'elles sont gérées ailleurs, alors le message, bien qu'il ne soit pas important pour vous, n'est pas un faux positif. C'est vrai et ça n'a pas d'importance. Les messages d'un outil d'analyse de flux vont de « vrai et important » à « vrai et sans importance » et de « vrai et improbable » à « faux ». Il y a beaucoup de variations ici et chacune doit être traitée différemment.
Il y a un piège commun ici aussi. Comme dans l'exemple nul ci-dessus, vous pouvez croire qu'une valeur nulle ne peut pas arriver à ce point, mais l'outil a trouvé un moyen d'y arriver. Si c'est important pour votre application, assurez-vous de vérifier et éventuellement de vous protéger contre cela.
Il est essentiel de comprendre qu'il existe à la fois une puissance et une faiblesse dans l'analyse des flux. La puissance de l'analyse de flux est qu'elle parcourt le code et essaie de trouver des points chauds, puis de trouver des problèmes autour des points chauds. La faiblesse est qu'il doit faire des hypothèses pour essayer de traverser le code, et plus il traverse, plus il est susceptible de produire un chemin improbable.
Le vrai problème est que si vous commencez à penser que vous avez nettoyé tout le code parce que votre analyse de flux est propre, vous vous trompez. Vraiment, vous avez trouvé des erreurs et vous devriez en être reconnaissant. L'absence d'erreurs d'analyse de flux signifie simplement que vous n'avez rien trouvé, pas que le code est propre. Il est préférable de vous assurer que vous utilisez un outil tel que Test C / C ++, pointTEST, ou Jtest qui a les deux types d'analyse statique, si vous créez un logiciel critique pour la sécurité
Malgré toute affirmation contraire, chaque outil d'analyse statique produit des faux positifs et passe à côté de vrais défauts, de faux négatifs. Il y a des compromis à faire entre les défauts manquants et l'obtention d'un trop grand nombre de rapports.
Les outils d'analyse statique doivent plutôt être évalués en fonction de ce qu'ils trouvent, de la qualité de leur présentation et du nombre de défauts qu'ils manquent. Les outils conçus pour réduire les faux positifs ont inévitablement des faux négatifs plus élevés. Est-ce que ça vaut le coup de passer à côté de vrais bugs pour avoir moins de rapports ?
Voici quelques éléments à prendre en compte lorsque vous pesez l'équilibre entre les faux positifs et les faux négatifs.
Ainsi, la première étape consiste à configurer votre analyse de code de manière appropriée et à réduire le bruit inutile. Assurez-vous que les bons contrôleurs fonctionnent avec le bon code. Par exemple, si vous ne résolvez pas un problème à partir d'un vérificateur particulier, désactivez-le. Ou si vous avez du code hérité qui est sur le terrain depuis de nombreuses années et que seul un bogue signalé peut vous forcer à apporter des modifications, pourquoi s'embêter à exécuter une analyse dessus ?
Cependant, s'il vous arrive d'exécuter une analyse statique sur une grande base de code et de récupérer une énorme liste de violations, ne vous laissez pas submerger. Il ne faut pas longtemps pour apprendre à hiérarchiser les résultats en fonction du risque et de l'impact et se concentrer d'abord sur la priorité la plus élevée. De nombreuses plaintes concernant les outils d'analyse statique proviennent d'impressions d'outils et de capacités d'ancienne génération.
Les organisations doivent déterminer leurs propres risques et les coûts associés. Le compromis idéal est d'avoir le moins de faux positifs possible tout en minimisant les faux négatifs.
Un moyen efficace, mais souvent négligé, de compléter l'analyse de flux est la détection des erreurs d'exécution. La détection des erreurs d'exécution vous aide à trouver des problèmes beaucoup plus compliqués que l'analyse de flux ne peut détecter, et vous avez la certitude que la condition s'est réellement produite. La détection des erreurs d'exécution n'a pas de faux positifs comme l'analyse statique. Quand il trouve un défaut, c'est parce qu'il l'a effectivement observé pendant l'exécution - il n'y a aucune hypothèse impliquée.
Votre ensemble de règles d'exécution doit correspondre étroitement à votre ensemble de règles d'analyse statique. Les règles peuvent trouver les mêmes types de problèmes, mais l'analyse d'exécution dispose d'un grand nombre de chemins d'exécution disponibles. En effet, au moment de l'exécution, les stubs, l'installation, l'initialisation, etc. ne posent pas de problème comme ils le sont pour l'analyse de flux. La seule limite est qu'elle est aussi bonne que votre suite de tests car elle vérifie les chemins que votre suite de tests exécute. Si vous programmez en C ou C ++, en particulier dans des appareils embarqués comme l'IoT, jetez un œil à Assurer ++ - il peut trouver plus de bogues à l'exécution que tout autre outil. Au lieu de vous enliser dans des problèmes délicats tels que des problèmes de thread, des fuites de mémoire et des conditions de concurrence, vous pouvez les trouver avec précision au moment de l'exécution.
Mon approche des faux positifs est la suivante: s'il faut 3 jours pour corriger un bogue, il vaut mieux passer 20 minutes à regarder un faux positif… tant que je peux le marquer et ne plus jamais avoir à le regarder. Il s'agit de le regarder dans le bon contexte. Par exemple, disons que vous avez un problème avec les threads. Les problèmes avec les threads sont extrêmement difficiles à découvrir. Si vous souhaitez trouver un problème lié aux fils de discussion, il vous faudra peut-être des semaines pour le localiser. Je préférerais écrire le code de telle manière que les problèmes ne puissent pas se produire en premier lieu. En d'autres termes, j'essaie de faire passer mon processus de la détection à la prévention.
L'analyse statique, lorsqu'elle est déployée correctement, n'a pas à être une expérience bruyante et désagréable. Découvrez comment nous faisons les choses différemment à Parasoft, en particulier en utilisant toute la puissance de PAO Parasoft pour gérer les résultats avec des analyses intelligentes qui vous permettent de rester concentré sur les risques liés à votre logiciel plutôt que de rechercher des problèmes sans importance.
« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Tous droits réservés.
Des tests Java plus intelligents grâce à l'IA pour plus de rapidité, de couverture et de conformité