Qu’est-ce que l’analyse statique de code ?

Également appelée « analyse de code source », l’analyse statique de code identifie les erreurs logiques et les fuites de mémoire avant l’exécution des applications, ce qui réduit le temps de débogage. Elle recherche automatiquement les erreurs de syntaxe et les failles de sécurité cachées qui pourraient échapper à l’œil humain. Elle garantit le respect des normes de codage et contribue à assurer la conformité réglementaire au sein d’équipes de grande taille, tout en accélérant globalement le développement.

L’analyse statique, par opposition à l’analyse dynamique, a lieu avant l’exécution du code. La seconde consiste à exécuter l’application et à observer son comportement. À l’inverse, la première traite le code source comme un jeu de données structurel, qu’elle analyse pour identifier les problèmes avant même que l’application ne soit compilée, packagée ou déployée. Cette approche modélise le comportement du programme en se basant sur sa structure. Ces deux techniques sont essentielles pour une pratique globale d’assurance qualité au sein d’un cadre DevOps ou DevSecOps.

L’analyse statique de code comporte trois étapes principales.

L’analyseur lit le code source et le décompose en tokens. Ceux-ci sont transmis à un analyseur syntaxique qui les évalue au regard des règles grammaticales d’un langage de programmation spécifique et les restructure en un arbre de syntaxe abstraite (AST) hiérarchique. L’AST représente la structure du logiciel dans un format lisible par machine.

L’analyseur établit un graphe de flux de contrôle (CFG) pour cartographier les chemins d’exécution, combiné à une analyse du flux de données permettant de suivre l’évolution des valeurs des variables, de leur initialisation à leur utilisation.C’est au cours de cette étape que l’analyseur peut détecter des erreurs telles que le code mort (code qui ne sera jamais exécuté).

À l’aide de l’AST et des modèles de flux, l’outil vérifie la conformité du code aux directives de codage et aux heuristiques. Celles-ci vont des simples conventions de nommage à des contrôles de sécurité plus sophistiqués, tels que l’analyse de contamination, qui identifie les entrées utilisateur contaminées susceptibles d’entraîner des injections SQL.

Aux débuts de l’informatique, l’exécution du code était coûteuse, et les développeurs ne pouvaient se permettre de gaspiller des ressources de calcul pour le débogage. La vérification reposait entièrement sur l’intelligence humaine, avec des revues de code manuelles et fastidieuses.

La création de Lint en 1978 par Stephen C. Johnson aux Bell Labs marque les débuts de l’analyse statique moderne de code. Lint a été développé pour le système d’exploitation Unix et conçu pour analyser le code source et signaler les constructions suspectes avant la compilation.

Lint identifiait le code problématique à supprimer sans modifier la logique du programme, ce qui permettait d’économiser une puissance de calcul précieuse. S. Johnson a baptisé Lint en référence aux peluches qui s’accumulent dans le filtre des sèche-linge, car son outil éliminait le code indésirable et problématique (les « peluches », « lint » en anglais) sans altérer la logique (la structure du vêtement).

À mesure qu’Internet s’est développé au cours des années 1990 et 2000, le besoin de pallier les failles de sécurité s’est accru. De nouveaux outils ont vu le jour pour répondre à cette demande, tout comme des formes d’analyse plus complexes qui transposaient le code en modèles mathématiques afin de suivre l’évolution des variables. De nouveaux cadres, tels que les tests statiques de sécurité des applications (SAST), ont émergé pour contrer ces menaces, tandis que des méthodes comme les tests dynamiques de sécurité des applications (DAST) permettaient de procéder à leur évaluation lors de l’exécution.

Bien que mathématiquement précises, ces techniques souffraient de taux élevés de faux positifs en raison de leur capacité limitée à comprendre le contexte. L’essor du machine learning et des grands modèles de langage (LLM) dans les années 2020 a marqué le début d’une nouvelle ère dans l’analyse de code, où les modèles pouvaient être entraînés sur des milliards de lignes. Ce processus leur a permis de déduire l’intention des développeurs et le contexte sémantique.

Traditionnellement, l’analyse statique de code était un processus de contrôle effectué avant la mise en production, mais aujourd’hui, elle est réalisée tout au long du cycle de développement logiciel (SDLC). Cette philosophie dite « shift left » consiste à déplacer les tests « vers la gauche », plus près de la phase de création du code.

Aujourd’hui, les outils d’analyse de code tels que SonarQube, ESLint et GitHub Advanced Security font partie intégrante des workflows des développeurs. Ils s’exécutent au sein d’environnements de développement intégrés (IDE) pour signaler les erreurs en temps réel, au fur et à mesure que les développeurs saisissent leur code. Ils font également office de points de contrôle automatisés au sein des pipelines d’intégration continue et de déploiement continu (CI/CD).

Les assistants de codage modernes, alimentés par le machine learning, ont permis une analyse décentralisée du code, à la fois rapide et largement invisible, permettant ainsi aux développeurs de détecter les erreurs à un stade précoce et d’améliorer la qualité du code en temps réel. IBM Bob, par exemple, dispose d’un workflow « Review » (Examen) qui s’exécute dans un panneau distinct et recherche automatiquement les « code smells » (indices de mauvaise qualité du code) tout en signalant les violations des normes de codage, que les utilisateurs peuvent ensuite ignorer ou laisser Bob résoudre automatiquement.

L’analyse peut également être effectuée de manière proactive grâce à des prompts stratégiques. Par exemple, plutôt que de demander à un assistant de codage de « trouver des bogues », les développeurs peuvent lui demander d’examiner des référentiels en gardant à l’esprit des objectifs spécifiques. Pour l’examen de l’architecture, on peut lui demander d’analyser l’organisation des répertoires, les points d’entrée, les relations entre les composants et la pile technologique globale, le tout générant une documentation détaillée. Un prompt analysant la conception de la base de données peut identifier des objectifs de modernisation. Des prompts spécialisés peuvent examiner la conception de la base de données, analyser la migration et effectuer un examen complet de la dette technique, avec des recommandations sur la manière la plus stratégique de résoudre les problèmes.