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

Premiers pas avec l'analyse statique sans surcharger l'équipe

Premiers pas avec l'analyse statique sans surcharger l'équipe Temps de lecture : 8 minutes

Cet article est le premier de quelques-uns que j'écrirai pour aider les nouveaux utilisateurs à adopter des outils d'analyse statique dans leur processus de développement. La mise en route peut être délicate si vous n'avez pas pris le temps au début de vous assurer que vous avez identifié les bonnes stratégies à adopter pour votre projet.

En tant qu'architecte de solutions ici à Parasoft, nous recevons beaucoup de personnes qui recherchent de l'aide dans ce domaine, alors sachez que vous n'êtes pas seul! Et si vous souhaitez plus d'informations, vous pouvez télécharger et lire ce guide complet que j'ai aidé à mettre en place.

Je suppose que vos outils d'analyse statique sont installés et que toute configuration initiale a été mise en place. Après cela, la mise en route peut être délicate si vous n'avez pas pris le temps au début de vous assurer que vous avez identifié les bonnes stratégies à adopter pour votre projet. Ici, ce que j'entends par «démarrer», c'est mieux comprendre l'approche générale d'intégration de l'analyse statique dans un projet existant et comment augmenter le retour sur investissement de l'analyse statique au fil du temps.

Qu'est-ce que l'analyse statique?

En termes simples, l'analyse statique est le processus d'examen du code source et binaire sans exécution, généralement dans le but de trouver des bogues ou d'évaluer la qualité. Contrairement à l'analyse dynamique (par exemple Parasoft Insure ++), qui nécessite un programme en cours d'exécution pour fonctionner, l'analyse statique peut être exécutée sur le code source sans avoir besoin d'un exécutable.

Cela signifie que l'analyse statique peut être utilisée sur du code partiellement complet, des bibliothèques et du code source tiers. L'analyse statique est accessible au développeur, pour être utilisée lorsque le code est en cours d'écriture ou de modification, ou pour être appliquée sur n'importe quelle base de code arbitraire.

Analyse statique à l'appui de la sécurité

Dans le domaine de la sécurité des applications, l'analyse de code statique est appelée test de sécurité d'application statique (SAST). L'analyse statique peut prendre en charge la détection des vulnérabilités de sécurité, ainsi que la détection des bogues, les mesures de qualité et la conformité aux normes de codage.

Analyse statique à l'appui des normes de sécurité fonctionnelle et de codage

Les outils d'analyse statique sont également mandatés (ou dans certains cas, «fortement recommandés») par des normes de sécurité fonctionnelle comme ISO 26262 ou EN 50128, pour leur capacité à détecter les défauts difficiles à trouver et à améliorer la sécurité des logiciels. Cela revient bien sûr à la sécurité, bien sûr, car les outils d'analyse statique aident également les équipes logicielles à se conformer aux normes de codage utilisées principalement pour valider le codage sécurisé, comme CERT ou même MISRA.

Introduction de l'analyse statique dans votre projet

Un grand avantage des outils d'analyse statique est qu'ils peuvent être introduits et utilisés à n'importe quelle étape d'un projet, efficaces même si un projet est incomplet et partiellement codé. Le plus grand défi avec l'introduction de l'analyse statique est qu'une grande quantité de code peut produire un grand nombre d'avertissements. Par conséquent, lors de l'intégration de l'analyse statique dans un projet, l'objectif doit être de rendre l'équipe productive le plus tôt possible et de minimiser la possibilité pour l'équipe d'être submergée par tous les avertissements d'analyse statique. Ce n'est pas pour diminuer l'importance de ces avertissements, mais la plupart des développeurs n'ont pas le luxe de réparer le code existant ou hérité, du moins pas immédiatement.

L'accent doit être mis sur l'intégration des outils dans les processus quotidiens afin d'optimiser l'accès et la convivialité, puis de traiter les bogues les plus critiques et les vulnérabilités de sécurité. Une fois que l'équipe devient plus compétente, vous pouvez alors vous concentrer sur l'optimisation des outils et des processus pour augmenter le retour sur investissement.

Commencez avec la fin en vue

Pour tirer le meilleur parti de l'analyse statique, il est important de comprendre l'objectif final. Si l'objectif est une meilleure sécurité, par exemple, qui façonnera le centre de l'analyse et de la correction, ou si l'objectif est de se conformer à une norme de codage telle que MISRA C, l'objectif deviendra de satisfaire la norme de codage et de la prouver aux entités de certification si nécessaire. .

Lors de la première adoption de l'analyse statique, il est facile de tomber dans le piège que plus c'est mieux (c'est-à-dire que plus d'analyse et plus d'avertissements signifie que vous tirez le meilleur parti de l'outil). C'est un piège commun. Au lieu de cela, restez concentré sur l'objectif final.

Si la sécurité est au centre des préoccupations, concentrez-vous sur l'amélioration de la sécurité et réduisez la distraction des autres types d'avertissements. Bien sûr, les bogues critiques sont toujours importants à traquer, mais ils ne doivent pas détourner l'attention de l'objectif principal. Au fil du temps, au fur et à mesure que l'équipe deviendra plus compétente, vous serez en mesure d'intégrer d'autres objectifs secondaires, tels que l'amélioration de la qualité globale ou l'application des normes de codage. Au fur et à mesure que l'analyse statique fait partie de la routine quotidienne de chaque développeur, il sera en mesure d'analyser les résultats plus rapidement et de corriger les bogues plus efficacement. À ce stade, les objectifs secondaires seront atteints plus efficacement, au lieu d'être simplement accablants.

Stratégies pour l'introduction de l'analyse statique à chaque étape de la maturité du produit

Une fois que vous comprenez votre objectif principal sur lequel vous concentrer, vous devez identifier la maturité du produit en cours de développement, car elle a un impact sur la façon dont l'analyse statique peut être adoptée. Considérez les principales étapes de développement ci-dessous et identifiez la place de votre projet afin de comprendre quelle approche d'adoption vous convient le mieux.

Projet existant - en développement actuel

Le scénario le plus courant est une organisation logicielle qui décide d'utiliser l'analyse statique et la déploie dans ses projets actuels.

Chaque projet peut choisir d'adopter les outils au début d'un sprint ou au début d'une mise à jour majeure d'une nouvelle fonctionnalité. En réalité, les équipes logicielles travaillent toujours - même si un produit est «fini», une autre version ou variante est en cours. L'aspect clé de ce scénario d'adoption est qu'il existe un corps important de code existant et un nouveau code est développé quotidiennement. L'approche d'intégration recommandée est appelée "une ligne dans le sable», Ce qui signifie améliorer le nouveau code au fur et à mesure de son développement, tout en reportant les avertissements moins critiques comme dette technique. Nous en reparlerons plus dans un instant.

Projet existant - Produit sur le marché de la maintenance

L'adoption d'une analyse statique pour un produit mature peut avoir des objectifs différents de ceux d'un projet encore en cours de développement. Il s'agit d'un produit qui se trouve dans les années les plus anciennes du cycle de vie du développement logiciel, dans lequel peu de nouveau code est écrit, uniquement pour corriger les bogues persistants et les vulnérabilités de sécurité. La principale approche pour adopter une analyse statique pour ces projets est appelée «reconnaître et reporter.«Dans cette approche, étant donné que peu de nouveau code est en cours de développement, tous les bogues découverts et les vulnérabilités de sécurité s'ajoutent à la dette technique existante.

Projet Greenfield

Bien que les équipes logicielles ne prennent pas souvent un nouveau départ, un nouveau produit et projet est le point idéal pour intégrer de nouveaux outils et techniques dans le processus de développement.

Dans ces projets, peu de code existant spécifique au projet existe, mais il peut toujours s'appuyer sur des logiciels tiers et open source. Les développeurs peuvent intégrer l'analyse statique dans leurs environnements de développement dès le début, garantissant un haut niveau de qualité lors de l'écriture du code. Cela permet l'adoption de normes de codage et garantit que les avertissements critiques d'analyse statique sont traités au fur et à mesure qu'ils surviennent, ajoutant ainsi moins de bogues et de vulnérabilités à la pile de dettes techniques. L'approche de l'adoption dans ce cas porte bien son nom "greenfield. »

Approches d'adoption de l'analyse statique: comment gérer les premiers rapports d'analyse statique

Une fois qu'un outil d'analyse statique a été installé dans le projet, il y a généralement un rapport assez long de violations et d'avertissements signalés par l'outil. Cela peut être accablant, en particulier dans les grandes bases de code, de sorte que la façon dont ces rapports initiaux sont gérés influence directement le succès de l'intégration de l'outil dans le projet.

Tous les avertissements ne sont pas critiques, donc tout n'a pas besoin d'être traité immédiatement. Apprendre ce qu'il faut aborder immédiatement et ce qu'il faut différer est la clé du succès. Comme mentionné ci-dessus, la maturité et la taille du produit ont une influence directe sur l'approche, décrite ci-dessous plus en détail.

Ligne dans l'approche de sable

Comme son nom l'indique, dans cette approche, les développeurs décident qu'après l'analyse initiale, ils ne laisseront plus d'avertissements et de violations critiques entrer dans la base de code. En d'autres termes, ils s'engagent à analyser chaque avertissement critique pour décider de sa véracité et à mettre en œuvre un correctif en temps opportun, s'il s'agit effectivement d'un bogue.

L'équipe peut également décider d'ajouter des avertissements critiques déjà découverts dans le code existant à ajouter à la liste des bogues dans leur outil de rapport. Des exemples de ces types d'avertissement peuvent être des vulnérabilités de sécurité critiques telles que des injections SQL ou des erreurs de mémoire graves telles que des dépassements de mémoire tampon. Dans la plupart des cas, les avertissements moins sérieux peuvent être reportés pour une analyse ultérieure. Vous pensez peut-être: «Cela ne fait-il pas qu'aggraver notre dette technique? Et si vous l'êtes, vous avez raison! Mais à ce stade, nous sommes d'accord avec ça. Tous les bogues potentiels dans ces avertissements étaient déjà dans la pile de dettes techniques. Au moins maintenant, ils sont identifiés et beaucoup plus faciles à corriger ultérieurement.

Reconnaître et différer l'approche

Dans le cas où un produit est déjà sur le marché et en cours de maintenance, il est toujours avantageux d'identifier les bogues persistants et les vulnérabilités de sécurité dans le code, mais il n'est pas possible pour les développeurs d'analyser (et encore moins de corriger) tous ces avertissements.

Dans un tel cas, il est logique d'examiner les rapports les plus critiques et de décider d'un plan d'action. Le reste des avertissements sont reconnus, car l'équipe logicielle reconnaît qu'ils existent, mais ils sont pour la plupart reportés à une date ultérieure. (Cela ajoute à nouveau à la dette technique de l'organisation, mais comme mentionné ci-dessus, ces bogues existent déjà techniquement en tant que dette technique.) Cette approche diffère de l'approche en ligne dans le sable en ce qu'après avoir identifié les avertissements clés, vous reportez simplement le reste, sans nécessairement aucune analyse.

Approche Greenfield

Un projet avec peu de code existant est un point de départ idéal pour l'analyse statique. Dans ce cas, les équipes logicielles peuvent enquêter sur tous les avertissements qui surviennent et corriger les bogues trouvés. Contrairement aux autres approches, il n'y a que quelques avertissements à gérer, afin que les développeurs puissent s'attaquer à la charge de travail supplémentaire. C'est également le moment idéal pour implémenter et appliquer une norme de codage via les outils, car les violations peuvent être identifiées et corrigées directement dans l'EDI et avant que tout code ne soit soumis au contrôle de version (ce que vous pouvez également faire dans les autres scénarios décrits ici) .

L'adoption de l'analyse statique dans les trois grandes étapes de maturité se différencie par la manière dont elles traitent l'arriéré d'alertes, comme illustré ci-dessous:

L'adoption de l'analyse statique dans les trois grandes étapes de maturité: Dans un projet greenfield, la plupart des avertissements signalés font l'objet d'une enquête et sont corrigés avec peu d'entrer dans la pile de la dette technique. Projets en développement ont tendance à avoir un arriéré d'avertissements qui sont pour la plupart différés, seuls les avertissements critiques étant traités, et produits en maintenance ont tendance à différer la plupart des avertissements.

Configuration contre filtrage

L'une des principales différences entre les outils d'analyse statique open source ou légers et les outils d'analyse statique avancés commerciaux est la possibilité de configurer quel jeu de vérificateurs est activé pour l'analyse et de filtrer les résultats rapportés en fonction de la catégorie d'avertissement, du nom du fichier, de la gravité et autres. les attributs. Cela permet de ne pas être submergé - les développeurs peuvent se concentrer uniquement sur les types d'avertissements qui les intéressent et réduire la quantité d'informations fournies à tout moment.

Il y a aussi une différence à noter entre configuration des vérificateurs   filtrage des résultats. Bien qu'au départ, il puisse sembler préférable de limiter le nombre de règles dans la configuration globale, le filtrage doit souvent être utilisé à la place, pour limiter la portée du reporting plutôt que d'éliminer complètement le vérificateur. Si une règle qui s'avère plus tard importante est désactivée dans la configuration, il n'y aura pas d'historique dans le référentiel d'avertissement, vous ne pourrez donc pas savoir si l'erreur a été introduite par des modifications récentes ou déjà dans le code avant l’adoption de l’analyse statique.

Je recommanderais d'utiliser la configuration pour simplement limiter l'ensemble des règles à celles qui sont prévisibles comme utiles pour l'équipe logicielle. Encore une fois, commencez avec l'objectif final à l'esprit: si l'amélioration de la sécurité est l'objectif principal, il est logique d'activer toutes les règles liées à la sécurité, de désactiver les règles moins importantes et d'activer l'une des normes de codage sécurisé intégrées telles que CERT C. Ensuite, si vous utilisez une solution d'analyse statique avancée telle que le test Parasoft C / C ++, vous pouvez tirer parti de ses outils de gestion intégrés pour gérer les données produites à partir des rapports d'analyse statique et orienter le développement futur.

Résumé

Les outils d'analyse statique offrent aux entreprises de logiciels la possibilité de détecter et de suivre les bogues des vulnérabilités de sécurité sans avoir besoin d'exécuter du code. Ces outils peuvent être appliqués au code existant, hérité et tiers et offrent de la qualité.

L'adoption de l'analyse statique varie dans une certaine mesure en fonction de la maturité du projet. Un grand corps de code entraîne de nombreux avertissements. C'est tout à fait gérable et le succès de l'adoption dépend de la manière dont les équipes décident de s'attaquer aux résultats. Différentes techniques sont introduites pour chaque niveau de maturité majeur d'un projet et comment ces outils peuvent être intégrés dans le flux de travail quotidien des développeurs, des chefs d'équipe et des gestionnaires.

Dans mon prochain article, je parlerai de l'intégration de l'analyse statique dans vos flux de travail quotidiens, alors assurez-vous de revenir pour cela! Ou abonnez-vous au blog en remplissant votre nom dans la case juste en dessous de cet article, pour être averti lorsqu'il sortira.

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

Billy McMullin

En tant qu'architecte de solutions chez Parasoft, Billy aide les équipes à élaborer des stratégies et à établir des priorités à mesure qu'elles adoptent des pratiques de développement et de test de logiciels modernes dans leur organisation.

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