La revue de code de sécurité expliquée : ce qu’un relecteur recherche dans un diff, et pourquoi

Une revue de sécurité du code consiste à lire délibérément le code source dans le but précis de trouver les manières de lui faire faire quelque chose que son auteur n'avait pas prévu. Cette définition paraît évidente jusqu'à ce qu'on la compare à ce que la plupart des équipes pratiquent réellement : une revue fonctionnelle, avec une liste de contrôle de sécurité à portée de main. L'aide-mémoire OWASP sur la revue sécurisée du code (OWASP Secure Code Review Cheat Sheet) trace la frontière avec précision : une revue de sécurité se distingue d'une revue fonctionnelle en ce qu'elle cible la validation des entrées, l'authentification, l'autorisation, l'implémentation cryptographique et les vecteurs d'attaque, plutôt que l'exactitude fonctionnelle. Un diff qui fonctionne parfaitement peut malgré tout ouvrir à un attaquant un chemin vers le système, et une seule de ces deux revues le cherche.

Ce qui rend le sujet digne d’un article aujourd’hui plutôt qu’en 2020, c’est qu’un modèle de langage peut lire un diff avec compétence, à moindre coût et en continu — ce qui change l’économie de la revue sans changer une seule des dimensions examinées. La checklist est plus ancienne que les modèles et n’a pas bougé. Ce qui a bougé, c’est la fréquence à laquelle vous pouvez vous permettre de l’appliquer.

Ce qu’un évaluateur recherche réellement à la lecture

L’aide-mémoire OWASP organise le travail en six domaines, et ce qui est utile dans cette liste, c’est que chaque domaine est une question plutôt qu’une catégorie. Les catégories invitent à cocher des cases ; les questions produisent des constats.

Entrées et injection. La question n'est pas de savoir si le code dispose d'un assainisseur ; elle est de savoir si quoi que ce soit atteint un interpréteur — shell, SQL, moteur de templates, évaluateur d'expressions — et à quelle couche cette exigence est censée être appliquée. Un diff qui ajoute une requête paramétrée, c'est bien ; un diff qui ajoute une requête paramétrée dans une fonction dont les autres appelants passent des chaînes brutes est un diff qui a déplacé le problème.

Authentification et session. Qui est l'appelant, et comment le code l'a-t-il établi ? Le bug récurrent n'est pas une vérification de mot de passe défaillante, c'est une session qui survit à un changement de privilèges — l'élévation a lieu, le jeton conserve ses anciennes revendications, et une heure plus tard, les privilèges sont toujours là.

Autorisation.Contrôles au niveau de l’objet, systématiquement, sur chaque route. Ce qu’il faut spécifiquement rechercher dans un diff, c’est une nouvelle route qui n’hérite pas du garde-fou dont bénéficient ses routes sœurs, car le middleware est enregistré par routeur et une route ajoutée sous un autre routeur ne sera tout simplement pas couverte.

Cryptographie. Primitive, mode, longueur de clé et emplacement de la clé. Deux questions permettent de repérer la plupart des constats réels : toute personne capable de lire ce code peut-elle aussi lire la clé, et cette comparaison est-elle de celles qui ne doivent pas révéler de timing.

Logique métier. Si la séquence peut être réordonnée, rejouée ou pilotée par des valeurs choisies par le client. Un prix, une quantité, un rôle ou une transition d’état qui provient du client et n’est pas recalculé côté serveur constitue un constat, quelle que soit la validation appliquée.

Configuration et secrets.Ce que le diff embarque qui n'aurait jamais dû se trouver dans un dépôt, et si les valeurs par défaut sont sûres là où le code s'exécute réellement. Un indicateur de débogage dont la valeur par défaut est true est un constat sur la production, pas sur l'indicateur.

Revue de référence versus revue des différences

OWASP distingue deux modes, et les confondre est une source courante à la fois d’efforts inutiles et de fausse assurance. Une revue de référence examine l’ensemble de la base de code de manière exhaustive, et c’est l’outil approprié pour une nouvelle application ou une version majeure, l’intégration d’un système hérité, répondre à une exigence de conformité ou réaliser l’analyse post-incident après qu’un problème s’est déjà produit. Une revue basée sur les différences ne se penche que sur ce qui a changé, et c’est l’outil approprié pour les demandes de fusion, les commits, l’achèvement des fonctionnalités et la validation continue.

La distinction compte parce que les deux produisent un travail différent. Une revue de référence se termine par un backlog ; une revue de diff se termine par une décision de fusion. Mener la première en continu est trop coûteux, et mener la seconde sur une base de code qui n’a jamais connu la première, c’est ainsi que les équipes accumulent une fausse impression de couverture : chaque modification passe la revue, et la concaténation SQL préexistante reste là, sans être touchée.

Techniques, et ce que chacune détecte

OWASP répertorie quatre techniques de revue, et elles se distinguent par le type de preuves que le réviseur suit plutôt que par leur degré de rigueur. L'analyse de motifs de code suit des formes familières : l'appel de fonction dangereux, la désérialisation d'entrées non fiables, le contrôle de longueur manquant. C'est rapide, et c'est exactement ce qu'un outil déterministe fait bien. L'analyse de flux de données suit une valeur depuis son point d'entrée jusqu'à son point d'utilisation, ce qui est le seul moyen de déterminer si l'assainisseur appliqué trois fonctions plus tôt s'applique encore ici. La revue fondée sur les menaces part de la capacité d'un attaquant et progresse vers l'avant, ce qui permet de repérer l'écart entre deux composants individuellement corrects. La revue de la logique métier lit le flux de travail plutôt que les lignes, en demandant quelle séquence d'opérations légitimes produit un état illégitime.

Seul le premier de ces quatre est bien servi par un scanner, et seuls le premier et le deuxième le sont par une passe de modèle non guidée. Ce n’est pas un argument contre les modèles ; c’est un argument pour dire au relecteur quelle technique vous voulez, car une invite qui demande des « problèmes de sécurité » produira de manière fiable une analyse de motifs et s’arrêtera.

Ce que l’IA a changé, et ce qu’elle n’a pas changé

Les recherches sur le code rédigé par IA ont rendu le goulot d’étranglement de la revue plus aigu plutôt que de le créer. L’étude de la NYU sur les suggestions de GitHub Copilot, publiée à IEEE S&P en 2022, a constaté qu’environ 40 % des extraits générés contenaient un schéma exploitable dans 18 catégories CWE. Les travaux de Stanford sur le comportement des développeurs, publiés à ACM CCS en 2023, ont mis en évidence un effet plus lourd de conséquences : les développeurs utilisant des assistants étaient plus convaincus que leur code était sûr tout en produisant du code mesurablement moins sûr. Plus de production et plus de confiance, c’est un problème de revue.

Un modèle de langage en tant que relecteur modifie une variable dans cette équation — le débit. Il peut lire chaque pull request, à un coût par token plutôt que par siège, et on peut lui poser explicitement les six questions ci-dessus. Il ne change pas les questions et n’acquiert pas les deux propriétés qui rendent une revue digne de confiance : le déterminisme et la capacité d’exécuter le code. Le même diff examiné deux fois peut produire des constats différents, les niveaux de gravité varient d’une exécution à l’autre, et le relecteur ne peut pas prouver qu’un chemin signalé est atteignable.

OrcaCode Review est la forme produit de cette idée, et il vaut la peine de l'examiner de près, car les choix de conception révèlent les modes de défaillance. Une revue qui isole le cas défaillant sous la forme d'un commentaire précis et reproductible — cette clé varie encore dans le temps, si bien qu'un débit réessayé génère une nouvelle clé et peut entraîner une double facturation, voici la modification d'une seule ligne — fait le travail d'un relecteur. Une revue qui signale un « problème de sécurité potentiel » sans reproduction fait de l'analyse de motifs avec une précision inférieure à celle du détecteur de motifs. Et un moteur de règles et de barrières publié sous licence ouverte formule une affirmation implicite qui mérite d'être vérifiée : que le jugement du relecteur devrait lui aussi être examinable.

L'agencement à deux couches qui fonctionne

Étant donné un scanner déterministe et un relecteur probabiliste, la répartition qui tient à l’épreuve de la pratique consiste à confier à chacun le travail pour lequel il est réellement efficace. Le scanner s’exécute à chaque push : quelques secondes, aucun modèle, aucune variance, et il détecte les secrets, les appels d’API dangereux, la désérialisation non sécurisée et les imports hallucinés. Le relecteur s’exécute à chaque pull request : quelques minutes, assisté par un modèle, et il détecte la logique entre les lignes — si le contrôle d’autorisation s’exécute avant la récupération, si la clé d’idempotence est liée à une valeur stable, si la nouvelle route a hérité du garde.

Puis la couche que tout le monde saute : la porte. Un constat qui ne bloque pas une fusion est une notification, et les notifications, on les lit le vendredi. La porte doit être étroite et elle doit être absolue — les constats critiques bloquent, tout le reste laisse un commentaire — et la dérogation doit être consignée par écrit, car la valeur d'une porte ne tient pas à ce qu'elle arrête le premier constat, mais à ce qu'elle rende visible chaque contournement.

Examiner la modification, pas l’ensemble de la base de code

La discipline pratique pour une revue de diff est une courte séquence, et sa valeur tient à ce qu’elle peut être enseignée en un après-midi. Lisez le diff pour ce qu’il ajoute à la surface d’attaque plutôt que pour ce qu’il modifie. Pour chaque nouveau point d’entrée, suivez l’entrée un niveau au-delà de l’endroit où le diff s’arrête — la vulnérabilité se trouve généralement dans la fonction qu’il appelle, que l’auteur n’a pas lue. Pour chaque nouvelle route, vérifiez l’enregistrement du garde. Pour chaque nouvelle dépendance, vérifiez si elle existe et si quelqu’un d’autre a publié le nom. Pour chaque nouvelle valeur de configuration, demandez à quelle valeur elle est définie par défaut là où elle sera réellement déployée.

Rien de tout cela n’exige de bien connaître le langage, ce qui explique que la méthode passe à l’échelle auprès de relecteurs qui ne sont pas spécialistes de la sécurité. En revanche, elle exige que le relecteur voie le diff plutôt que le fichier, car toute la méthode repose sur la connaissance de ce qui est nouveau.

Et la limite honnête : une revue de diff ne peut pas trouver le défaut qui était déjà là avant le diff. Si l’application n’a jamais fait l’objet d’une revue de référence, le travail de sécurité à plus forte valeur disponible n’est pas un meilleur relecteur — c’est une passe délibérée sur la base de code, dans les zones qui touchent à l’argent, à l’identité et à l’accès aux fichiers, avec les six questions ci-dessus. Après cela, chaque revue de diff ultérieure protège quelque chose qui a déjà été examiné une fois. Avant cela, chaque revue de diff protège un inconnu.