8 bonnes pratiques éprouvées de revue de code pour les développeurs

La revue de code orientée sécurité consiste à vérifier dans quelle mesure le code résiste aux menaces externes. Le code peut présenter des faiblesses de sécurité intrinsèques qui compromettent l’application ou les blocs de code environnants. Les revues par les pairs sont un processus manuel qui complète les méthodes de test automatisées afin d’assurer une couverture de sécurité complète. Une revue de code sécurisée peut repérer les faiblesses de sécurité et les erreurs de logique liées au fonctionnement d’une application. Elle protège ainsi l’application contre la perte de données et de propriété intellectuelle, qui pourrait nuire au chiffre d’affaires et à la réputation de l’entreprise.

Pour améliorer la qualité et la sécurité des logiciels, l’une des meilleures approches consiste à mettre en place un processus formel de revue manuelle du code. Comme des erreurs peuvent survenir pendant l’écriture du code, faire appel à plusieurs personnes aux expertises complémentaires permet de déceler des problèmes que le programmeur initial pourrait ne jamais remarquer. De plus, même si chaque personne est susceptible de commettre des erreurs, un groupe d’experts peut repérer un bogue ou une faille de sécurité que les outils automatisés de revue de code pourraient manquer.

Malgré les avantages d’une revue de code par les pairs, il peut parfois être difficile de réunir rapidement un groupe de pairs pour effectuer la tâche. Pour y remédier, la définition de pratiques de revue de code peut guider le processus vers le résultat souhaité : un code de haute qualité et sécurisé. Voici huit règles de revue de code que vous pouvez intégrer au processus de développement logiciel de votre entreprise.

1. Ajouter des commentaires pendant la création du code source

La première pratique consiste à ajouter des commentaires non fonctionnels dans certaines parties du code afin d’expliquer aux personnes chargées de la revue l’intention derrière un bloc de code. Les commentaires permettent de communiquer les raisons d’une décision ou d’une modification, sans obliger l’équipe de revue à les deviner. Bien utilisés, ils aident les personnes expérimentées à comprendre l’objectif et la méthode de l’ensemble de la séquence de code. De plus, l’adoption et le respect d’un guide de style garantissent la lisibilité du code pour toute l’équipe.

2. Ne pas supposer que le code fonctionne sans le tester

Le développement de code passe par des essais et des erreurs successifs. Le développeur écrit quelques lignes, compile le code, et celui-ci ne fonctionne pas. Tester le fonctionnement et les résultats des nouvelles sections de code peut considérablement réduire le temps de revue par la suite. Il est également beaucoup plus facile de corriger une petite partie du code lorsque l’on sait que le reste fonctionne correctement. Le développement piloté par les tests (TDD) consiste notamment à écrire des tests unitaires avant d’implémenter le code. Cette approche permet de vérifier au préalable des blocs de fonctions spécifiques et laisse aux personnes chargées de la revue le soin de se concentrer sur leur intégration au reste du code.

3. Exécuter des suites de tests sur le code proposé

Pour valider un ensemble donné de procédures, vous pouvez utiliser des suites de tests automatisées afin d’écrire des tests unitaires pour chaque bloc de code. Une suite de tests regroupe des fonctions connues et évalue le code par rapport à un résultat positif attendu. Autre outil permettant d’évaluer la manière dont le code exécute des actions spécifiques, les suites de tests accélèrent la validation des sections qui effectuent une ou plusieurs tâches prédéfinies. En cas d’échec, elles peuvent indiquer au développeur la partie à modifier.

4. Veiller à ce que les pull requests soient courtes et poursuivent un seul objectif

Les pull requests (PR) désignent un processus standardisé permettant de demander une revue de code par les pairs. Lorsque le développeur a terminé la première modification du code, la PR lance le processus de revue. Pour gagner en efficacité et accélérer la revue manuelle, le développeur doit créer des PR accompagnées d’instructions précises à l’intention des personnes chargées de la revue. Plus une PR est complexe, plus la revue peut prendre du temps, au risque de détourner leur attention de son objectif principal. En effet, la taille idéale d’une PR est inférieure à 250 lignes, car les personnes chargées de la revue peuvent détecter 70 à 90 % des défauts en moins d’une heure.

5. Toujours exécuter des outils automatisés de vérification du code

Avant la revue par les pairs, le développeur peut utiliser des outils de revue de code tels que des scanners, des outils automatisés de vérification du code ou des analyseurs de code statiques pour évaluer la qualité du code après les modifications. Ces outils détectent les erreurs de formatage évidentes, comme les erreurs dans les noms de fonctions ou les problèmes d’espacement. Les scanners et les linters s’appuient sur des règles prédéfinies et fonctionnent comme un correcteur orthographique pour repérer rapidement les erreurs dans le code. Leur utilisation retire ces tâches du processus de revue manuelle par les pairs, ce qui permet à l’équipe de se concentrer sur les erreurs de style ou d’interprétation.

Par exemple, les outils de revue de code Java peuvent détecter les bogues et les problèmes de sécurité dans le code Java et fournir des conseils concrets pour aider les développeurs à les corriger rapidement. Snyk Code fournit des recommandations sur la qualité du code directement dans votre IDE, pour une expérience de développement sans friction.

6. Examiner l’ensemble du code et des PR

Le code étant séquentiel, les personnes chargées de la revue doivent évaluer l’ensemble du code et des PR pour en vérifier la cohérence. La modification d’une section peut avoir des répercussions importantes sur les sous-routines qui suivent. L’équipe de revue de code par les pairs doit donc tenir compte de l’ensemble du code et de toutes les PR lors de son évaluation. Les PR plus importantes attirent naturellement davantage l’attention. Toutefois, une erreur dans une petite PR peut avoir des conséquences encore plus graves qu’un ensemble de défauts dans une PR volumineuse.

7. Définir des limites de temps de revue et de lignes de code à vérifier

La revue de code est un processus long et fastidieux, mais essentiel. Il est donc important de limiter le temps qu’une personne ou une équipe consacre à l’examen de chaque ligne de code. Parmi les bonnes pratiques dans ce domaine, citons le fait de veiller à ce que les membres de l’équipe ne consacrent pas plus d’une heure à une revue, ou à ce que l’équipe n’examine pas plus de quelques centaines de lignes sur une période donnée. Cette approche définit les attentes de l’équipe de revue de code et l’aide à vérifier minutieusement la partie du code associée à la PR. En organisant les revues de manière efficace pour toute l’équipe, les développeurs peuvent recevoir des commentaires précieux et améliorer rapidement la qualité de leur code.

8. Effectuer une revue de code orientée sécurité

Une autre bonne pratique consiste à effectuer une revue de code sécurisée. Alors que les outils automatisés vérifient le formatage et les noms, puis comparent le code à des fonctions standard connues, les revues manuelles évaluent le style, l’intention et le résultat fonctionnel du code. Un troisième type d’évaluation, la revue de code orientée sécurité, examine la robustesse du code du point de vue de la sécurité.

Le code peut présenter des vulnérabilités intrinsèques qui compromettent l’application ou les blocs de code environnants. Une revue de code sécurisée peut repérer ces vulnérabilités et les erreurs de logique liées au fonctionnement de l’application. Le développeur doit pouvoir écrire du code dans un environnement qui le protège contre les attaques externes, dont les conséquences peuvent aller du vol de propriété intellectuelle à la perte de chiffre d’affaires ou de données.

Heureusement, il existe des outils de test de sécurité des applications statiques (SAST), comme Snyk Code, qui peuvent détecter les vulnérabilités avant la revue du code ou pendant l’analyse du code. Il existe également des bonnes pratiques de codage sécurisé pour protéger le code source et faciliter une revue de code sécurisée. On peut notamment limiter l’accès au code, imposer un chiffrement fort et mettre en place une gestion des secrets afin d’éviter la diffusion à grande échelle des mots de passe et des éléments codés en dur.

En résumé : comment effectuer une revue de code

Les développeurs peuvent continuer à affiner et à optimiser leur code sans fin, mais ils risquent malgré tout de ne pas détecter toutes les erreurs ou failles de sécurité. En mettant en place un processus de revue de code par les pairs, les équipes de développement peuvent s’assurer que leurs logiciels sont correctement testés avant le déploiement en production. Combiner la revue automatisée, les étapes de revue manuelle par les pairs et les pratiques de revue de code sécurisée est le moyen le plus efficace de livrer rapidement un code de haute qualité et sécurisé.

Consultez notre page Ressources de sécurité pour découvrir les solutions et outils de Snyk qui aident les développeurs à créer du code fiable et sécurisé.