Faux positifs dans l'analyse de code statique

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

Analyse de code statique : avantages et limites

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.

Bénéfices

Les outils d'analyse statique et de test de sécurité des applications statiques (SAST) offrent aux équipes de développement les avantages suivants.

• Meilleure qualité de code. L'analyse statique aide à éliminer les défauts au début du développement, offrant une meilleure qualité de code dès le moment de la création tout en améliorant la qualité en aval dans les étapes ultérieures du développement.
• Code plus sécurisé. En plus de la détection des défauts, l'analyse statique et SAST améliorent la sécurité en détectant les vulnérabilités qui entraînent des risques de sécurité. Des solutions comme Parasoft appliquent des pratiques et des normes de codage plus sécurisées que d'autres.
• Conformité aux normes de codage de l'industrie et de l'organisation. L'application manuelle des normes de codage est fastidieuse, voire impossible. L'analyse statique automatise la vérification, l'application et la conformité des normes de codage. Cela inclura les normes de sécurité et de sécurité de l'industrie telles que MISRA et les normes de sécurité telles que OWASP Top 10, CWE Top 25 et SEI CERT C/C++.
• Améliorer la productivité. Les tests d'analyse statique au début de la mise en œuvre et dans l'IDE du développeur et/ou dans le flux de travail CI/CD de l'équipe favorisent la qualité du code et accélèrent le développement en déplaçant les tests plus à gauche. De plus, Parasoft intègre AI/ML pour organiser automatiquement les problèmes d'analyse statique identifiés et améliorer encore la productivité.
• Réduisez les risques et les coûts. L'application d'une analyse statique réduit considérablement les problèmes de sûreté et de sécurité signalés sur le terrain. Les organisations reconnaissent également une augmentation de la fiabilité des produits, ce qui réduit les coûts de maintenance et favorise une réputation de haute qualité.

Limites

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.

• Faux positifs. Chaque analyse statique peut interpréter par erreur une construction de codage obscure et signaler une erreur. Ces erreurs de rapport sont des faux positifs et sont inévitables avec l'analyse statique, comme indiqué ci-dessous.
• Faux négatifs. Semblables aux faux positifs, les outils peuvent manquer de vraies erreurs dans le code source. Ces défauts manqués sont des faux négatifs et sont traités plus en détail ci-dessous.
• Portée et contexte limités. La portée de l'analyse statique est limitée au code source mis à disposition au moment de l'analyse. Plus il y a de code, meilleurs sont la portée et les résultats. L'analyse statique manque également de contexte en termes de ce que le code est conçu pour faire. Il analyse la source sur la base d'un ensemble de règles ou de vérificateurs, qui ne comprennent pas nécessairement l'intention du programmeur.
• Performances de l'outil. L'analyse statique, selon la profondeur de l'analyse, peut prendre du temps pour analyser de grandes bases de code. Bien que le matériel de serveur moderne ait rendu cela moins préoccupant, les développeurs limitent généralement l'analyse à grande échelle aux versions logicielles. Les outils d'analyse statique modernes comme C/C++test ont atténué ce problème dans une certaine mesure avec une analyse incrémentielle effectuée dans les IDE, par exemple. Les violations de code sont signalées pour correction uniquement à l'ingénieur qui développe son code à mesure que des étapes incrémentielles sont effectuées lors de chaque compilation et génération de code.
• Coût. Les outils commerciaux d'analyse statique coûtent de l'argent pour obtenir une licence. Cependant, les outils d'analyse statique ont d'excellents retours sur investissement pour les petits ou grands projets et organisations.

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

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

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 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é

Faux positifs et faux négatifs dans l'analyse de code statique

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.

• Utilisez les capacités des outils pour hiérarchiser les résultats. Les faux positifs sont inhérents aux outils d'analyse statique, mais la plupart ont développé des outils sophistiqués pour traiter les résultats. Les outils d'analyse statique regroupent les rapports par gravité et ont la capacité d'ignorer et/ou de filtrer rapidement et facilement les résultats indésirables.

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 faux positifs ne durent pas éternellement. Tous les résultats qui ne présentent pas d'intérêt peuvent être filtrés pour ne plus jamais être signalés. Si le type d'erreur n'est pas une priorité élevée à corriger, la classe entière d'erreur peut être supprimée des futurs rapports. Si des rapports individuels s'avèrent être de vrais faux positifs, ils peuvent être marqués comme tels. L'essentiel est que, avec un peu d'effort, le bruit disparaisse à mesure que les développeurs s'habituent à utiliser les outils.
• Les faux négatifs ont un impact sur la qualité et la sécurité des produits. Les faux négatifs, en revanche, sont inconnus car ils ne sont pas détectés et leur existence peut ne pas être révélée tant qu'un client n'a pas le produit en main. C'est avec cet objectif que les développeurs doivent peser l'impact des faux positifs sur leur charge de travail : cela vaut-il la peine de passer à côté de défauts importants ?

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.

• Renforcer la confiance dans les capacités des outils. Les faux positifs peuvent sembler problématiques au début, mais la recherche et la correction de vrais défauts renforcent la confiance dans les outils au fil du temps. Au contraire, les erreurs réelles manquantes qui sont détectées plus tard dans les tests reflètent mal les outils utilisés pendant le développement. Les développeurs veulent des outils auxquels ils peuvent faire confiance, et mettre l'accent sur la réduction des faux positifs au prix de défauts réels manquants n'en vaut pas la peine.

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.

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