Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

Une stratégie d'analyse statique saine

Par Arthur Hicken

13 mars 2017

4  min lire

Dans le cadre de ma série sur le 7 habitudes de programmeurs très performants, aujourd'hui, je vais discuter de quelques façons de m'assurer que l'analyse statique est efficace et durable.

Politique

Pour commencer par le début, il est préférable de commencer par votre politique d'analyse statique. Certaines personnes se demandent pourquoi cela est important, mais c'est en fait crucial pour une initiative d'analyse statique réussie. Votre politique couvrira des choses comme les règles que vous devez exécuter, quand vous pouvez les ignorer ou quand vous devez les corriger, comment les suppressions sont effectuées, etc. Vous devez également décider quel code doit être analysé, c'est-à-dire tout ce code hérité. vous venez de vous asseoir, dont nous discuterons sous peu.

Sans une politique cohérente, l'analyse statique se transforme rapidement en un bugfinder occasionnellement exécuté, réduisant la valeur que vous en retirez. Si vous travaillez dans une entreprise de conformité comme le médical ou l'automobile, vous devez quand même effectuer une analyse statique, alors autant faire les choses correctement et obtenir une certaine valeur.

Sélection d'outils

Obtenir le bon outil est important. L'outil doit fonctionner dans votre éditeur de code (IDE), avec les langues que vous utilisez, sur le système d'exploitation que vous utilisez. L'outil doit prendre en charge à la fois l'exécution du serveur et dans l'EDI, dans l'IDE (pour les développeurs) et les rapports basés sur le Web (pour les gestionnaires). Vous devez être en mesure de configurer l'outil pour qu'il applique uniquement les règles souhaitées (pas uniquement celles que le fournisseur de l'outil souhaite que vous exécutiez). Les outils matures sont livrés avec des configurations de départ prêtes à l'emploi pour vous permettre de lancer des initiatives industrielles telles que MISRA, OWASP, CWE et PCI.

Pouvoir étendre l'outil avec vos propres règles, idées et meilleures pratiques sera également important pour votre succès à long terme. Et n'oubliez pas le support technique - quelqu'un peut-il examiner les problèmes liés aux règles bruyantes et vous aider à les résoudre? Allez-vous utiliser l'open source et faire les correctifs vous-même? Utilisez-vous normalement les services des fournisseurs pour vous aider à démarrer rapidement votre projet et à aller dans la bonne direction?

Tout cela et bien d'autres sont tous des éléments à prendre en compte lors de la sélection d'un outil. Ne tombez pas dans le piège du bake-off - il fournit peu d'informations utiles pour savoir si un outil fera vraiment ce dont vous avez besoin, et les outils d'analyse statique fonctionnent simplement différemment.

Sélection de règle

Comme mentionné ci-dessus, il est facile de tomber dans le piège de simplement activer les règles de l'outil d'analyse statique dont vous disposez. Certains vendeurs l'encouragent activement, d'autres l'exigent même! Les besoins en tests logiciels de chacun sont différents. Une configuration par défaut peut vous aider à démarrer, mais pour réussir, vous devez la personnaliser.

Certaines choses à faire incluent la désactivation des règles bruyantes et l'obtention de niveaux de gravité correspondant à vos propres pratiques réelles (vous ne voulez pas qu'un outil dise que quelque chose est critique lorsque vous pensez que sa gravité est faible). Un indice non évident est de désactiver les règles que vous aimez mais que vous ne prévoyez pas de corriger aujourd'hui. Lorsque vous avez le temps de résoudre les violations, activez la règle, pas avant. Les ignorer lorsqu'ils sont signalés ne fera qu'engendrer de la frustration et de mauvaises habitudes en apprenant aux développeurs que toutes les règles n'ont pas d'importance.

Les règles que vous exécutez doivent se rapporter aux problèmes que vous rencontrez sur le terrain, aux problèmes auxquels vous pouvez raisonnablement vous attendre, aux problèmes de sécurité, aux éléments trouvés lors de la révision du code et à tout élément de conformité - des règles que vous DEVEZ exécuter.

Suppressions

Même lorsque vous avez exactement les bonnes règles, le contexte rend parfois une analyse statique particulière sans importance dans une partie du code, alors qu'elle est toujours critique dans une autre. Vous avez ici quelques choix, dont le moins précieux est d'être frustré et de désactiver la règle. C'est un mauvais choix si vous savez que la règle peut apporter de la valeur dans certains domaines. Si votre outil ne vous permet pas de configurer et de supprimer correctement, vous avez choisi le mauvais outil - revenez à l'étape 2 ci-dessus.

Un autre piège dans lequel certains tombent est de s'engager dans une certaine gestion manuelle des résultats et de diffuser ceux jugés importants. Cela demande beaucoup de travail, n'est pas évolutif, ni maintenable, et vous finirez par corriger les choses qui sont moins importantes tout en manquant celles qui sont plus importantes. Vous avez besoin d'un processus basé sur les données qui vous aidera à évaluer les violations qui doivent être corrigées et celles qui peuvent être ignorées en toute sécurité, puis un moyen de les signaler afin qu'elles ne reviennent pas. Idéalement, cela peut être fait par les développeurs directement dans l'EDI où se trouve le code, ainsi que par les gestionnaires, les architectes, etc., dans une interface utilisateur Web.

Certains placent ces suppressions dans un système séparé. Cela a l'avantage de ne jamais changer le code, mais comporte le risque de nécessiter une retouche lorsque vous branchez ou refactorisez, ou s'il y a un problème de synchronisation. D'autres modifient le code sous la forme d'un commentaire spécial. Bien que cela nécessite un changement de code, il est persistant et précis, et documente également les suppressions - ce qui est génial si jamais vous êtes audité. Pensez à vos besoins et choisissez la méthode qui convient le mieux à votre environnement. Si votre outil ne prend pas en charge les deux, revenez à l'étape 2.

Code hérité

Le code hérité est lié aux suppressions. Il est important de décider comment vous souhaitez gérer l'ancien code. Encore une fois, cela dépend de vos besoins, mais j'ai décrit quelques méthodes ci-dessous.

Certaines organisations choisissent de ne corriger les violations d'analyse statique dans le code hérité que s'il existe un rapport de bogue de champ en suspens qui touche ces lignes de code - rien d'autre dans le fichier ne doit être touché. Si vous avez un code vraiment ancien ou si le risque de changement est élevé, c'est une politique tout à fait raisonnable. Cela minimisera les risques.

Une autre idée est de tout réparer dans un fichier lorsque vous y êtes de toute façon. Cela entraîne un certain risque de changement, mais si vous avez une bonne suite de tests unitaires (nous en reparlerons la prochaine fois), vous n'avez pas à vous inquiéter autant. Du côté positif, tout code que vous toucherez sera à jour avec les dernières normes de code requises et les meilleures pratiques. Le code périmé sera moins périmé qu'il ne l'était.

Vous pouvez également utiliser une méthode hybride ou simplement ignorer tout l'ancien code avant une certaine date et utiliser simplement une analyse statique à l'avenir. Déterminez ce que vous pouvez réaliser et faites-le de cette façon. Pensez tout d'abord aux risques et aux avantages de la stratégie que vous proposez.

L'analyse statique est l'un des outils les plus précieux de votre arsenal qualité / sécurité logicielle. Bien faire les choses apporte une grande valeur, mais se tromper peut condamner une génération de codeurs de votre organisation à utiliser d'anciens processus de qualité et de sécurité dépassés. Si vous avez des questions, faites-le moi savoir dans les commentaires ci-dessous - je suis toujours heureux de discuter de la façon de faire fonctionner 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.

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.