Un réviseur de code sécurisé est un professionnel de la sécurité qui examine le code source des applications afin de repérer les faiblesses susceptibles d'être exploitées une fois le logiciel en exécution, et qui aide les développeurs à les corriger avant la mise en production. Le rôle évolue au plus près du code, en lisant la manière dont une application est réellement construite plutôt que la façon dont elle se comporte une fois déployée. C'est une discipline ciblée au sein de la sécurité applicative, qui s'intéresse à la logique, au traitement des données et aux frontières de confiance exprimées directement dans le code source, et qui repose sur un réviseur capable de lire de nombreux langages et frameworks avec un état d'esprit axé sur la sécurité.
Au quotidien, le travail combine la lecture manuelle du code et le tri des résultats produits par des outils automatisés. Un réviseur observe comment une application valide les entrées, gère l'authentification et les autorisations, traite les données sensibles, construit ses requêtes et s'appuie sur des composants tiers, en recherchant les schémas qui mènent à l'injection, aux défaillances du contrôle d'accès, à l'exposition non sécurisée de données et à d'autres classes de faiblesses similaires. Les outils d'analyse statique font remonter des problèmes potentiels à grande échelle, mais une grande partie de la valeur réside dans la distinction entre les véritables résultats et les faux positifs, dans le suivi des données à travers le programme pour confirmer si une faille est atteignable, et dans l'évaluation de sa gravité réelle. Le réviseur rédige ensuite chaque problème dans des termes exploitables par un développeur, souvent en pointant la ligne précise, en expliquant le risque et en proposant une approche concrète plus sûre.
Le rôle exige la perspective d'un développeur associée aux réflexes d'un attaquant. Un bon réviseur lit couramment le code dans les langages utilisés par une équipe, comprend les frameworks courants et leurs comportements par défaut, et sait comment les catalogues de faiblesses reconnus, tels que la liste CWE et les recommandations de l'OWASP, se traduisent dans du code réel. Tout aussi importante est la capacité à raisonner sur les frontières de confiance, les flux de données et les hypothèses qu'un morceau de code formule à l'égard de ses appelants. Comme le résultat est une recommandation que d'autres ingénieurs doivent accepter et appliquer, la clarté de l'écriture, la justesse de la priorisation et un ton collaboratif comptent autant que la profondeur technique ; un résultat que les développeurs comprennent et corrigent vaut plus qu'un résultat simplement exact.
On entre couramment dans la revue de code sécurisé en venant du développement logiciel, ce qui apporte l'aisance de lecture et d'écriture du code que le rôle exige, ou d'un parcours plus large en sécurité applicative après avoir acquis une expertise sur la manière dont les vulnérabilités apparaissent dans le code source. L'évolution tend à s'orienter vers la revue de systèmes plus complexes et à plus haut risque, l'élaboration de normes de codage sécurisé et de processus de revue à l'échelle d'une organisation, le mentorat des développeurs et le réglage des outils qui soutiennent la revue à grande échelle. Le rôle est voisin de l'ingénieur en sécurité applicative, qui pilote un programme plus large de tests et d'outillage tout au long du cycle de vie du logiciel, et de l'ingénieur en sécurité produit, qui s'intègre à une équipe produit pour sécuriser un produit spécifique de bout en bout. Il complète l'ingénieur DevSecOps, qui automatise les contrôles de sécurité au sein des pipelines de livraison, et le Security Champion, un développeur qui porte la sensibilisation à la sécurité au sein d'une équipe ; la revue de code sécurisé fournit la lecture approfondie et experte du code source sur laquelle ces rôles s'appuient et qu'ils renforcent.