Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>

BLOG

Faux positifs dans l'analyse de code statique

Faux positifs dans l'analyse de code statique Temps de lecture : 5 minutes

« 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 même s'il n'avait pas pensé à si 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 "Je souhaite que l'analyse statique attrape ____" (nommez votre bug 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 écrasants!" 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.

Qu'est-ce qu'un faux positif en analyse statique ?

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 «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, ils ne comprennent pas comment elle s'applique dans cette situation, ou ils ne pensent pas que c'est important en général (ou dans ce cas particulier). 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 découverte qu'un développeur pourrait ne pas comprendre à première vue.

Faux positifs dans l'analyse basée sur des modèles

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 réellement, 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 simplement que le motif a été trouvé, indiquant une faiblesse dans le code, une susceptibilité à avoir un défaut.

Quand je regarde une violation, je me demande si cette règle s'applique ou non à mon code. Si cela s'applique, je corrige le code. Si ce n'est pas le cas, je supprime la violation. Il est préférable de supprimer les violations d'analyse statique dans le code directement afin qu'il soit visible par les membres de l'équipe et que vous n'ayez pas à le revoir une deuxième fois. Sinon, vous réexaminerez constamment la même violation encore et encore; c'est comme essayer de vérifier l'orthographe 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 considéré comme 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-178B / C, Et plus encore.

Faux positifs dans l'analyse basée sur les flux

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 que cela ne soit pas important pour vous) n'est pas un faux positif. C'est vrai et c'est sans importance. Les messages d'un outil d'analyse de flux vont de «vrai et important» à «vrai et sans importance» et «vrai et improbable» à «faux». Il y a beaucoup de variations ici, et chacune doit être traitée différemment.

Il y a aussi un piège commun ici. Comme dans l'exemple nul ci-dessus, vous pouvez penser qu'une valeur nulle ne peut pas atteindre ce stade, mais l'outil a trouvé un moyen d'y parvenir. 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 y a à la fois puissance et 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 et de trouver des problèmes autour des points chauds. La faiblesse est qu'il doit faire des hypothèses pour essayer de parcourir le code, et plus il avance, plus il est probable qu'il produise 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 ++, pointTESTou Jtest qui a les deux types d'analyse statique, si vous créez un logiciel critique pour la sécurité

Guide gratuit: Comment choisir un outil d'analyse statique moderne

Détection des erreurs d'exécution

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.

Est-ce que ça vaut le temps?

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.

Livre blanc: Premiers pas avec l'analyse statique

« 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.

Écrit par

Arthur Hicken

Arthur est impliqué dans la sécurité logicielle et l'automatisation des tests chez Parasoft depuis plus de 25 ans, aidant à la recherche de nouvelles méthodes et techniques (dont 5 brevets) tout en aidant les clients à améliorer leurs pratiques logicielles.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.