Qu’est-ce que le codage sécurisé ?

Le codage sécurisé, également appelé programmation sécurisée, est la pratique consistant à écrire du code source capable de se défendre contre les cyberattaques provenant d’acteurs malveillants. Intégrer la sécurité dans le code permet de limiter les vulnérabilités et de concevoir des logiciels suffisamment robustes et résilients pour résister aux cybermenaces.

La programmation sécurisée est un élément essentiel du cycle de développement logiciel sécurisé (SSDLC). Contrairement au SDLC traditionnel où la sécurité n’entre en ligne de compte qu’au cours de la phase de test, le SSDLC intègre la cybersécurité à chaque étape du processus de développement logiciel. La sécurité du code n’est pas une question secondaire, un complément optionnel ou un aspect distinct : c’est un élément essentiel de la conception de logiciels sécurisés.

Le codage sécurisé fait également partie de la sécurité des applications. Alors que la programmation sécurisée se concentre sur l’intégration de la cybersécurité dans le code, la sécurité des applications couvre un large éventail de mesures de sécurité, des protections matérielles aux défenses logicielles, et couvre l’ensemble du SDLC.

L’exploitation des vulnérabilités est devenue la principale cause d’attaques, selon le rapport X-Force Threat Intelligence Index 2026 d’IBM. L’adoption d’une approche plus proactive et préventive, telle que le codage sécurisé, permet de détecter les menaces avant qu’elles ne s’aggravent.

La programmation sécurisée offre les avantages suivants :

• Rentabilité : il est moins coûteux de corriger les failles de sécurité avant le déploiement qu’après la mise en production.

• Sécurité des données : des mesures de protection des données sensibles sont appliquées au niveau du code source, garantissant ainsi la conformité aux réglementations de protection des données.

• Détection précoce et prévention : les vulnérabilités sont détectées et éliminées pendant le développement, empêchant leur propagation en phase de production.

• Économies de temps et d’efforts : le code sécurisé permet de gagner un temps et des efforts considérables associés à la réponse aux incidents et à la résolution pour les systèmes actifs.

Les vulnérabilités de sécurité dans le code sont généralement dues à des défauts de conception et d’architecture des logiciels, ou encore à des erreurs de configuration ou de programmation. Les acteurs malveillants exploitent souvent ces vulnérabilités pour lancer des attaques.

Voici quelques vulnérabilités classiques que la programmation sécurisée cherche à résoudre, selon la liste des risques de sécurité des applications web de l’Open Worldwide Application Security Project (OWASP) :

• Échecs d’authentification

• Contrôles d’accès défectueux

• Défaillances cryptographiques

• Attaques par injection

• Conception non sécurisée

• Journalisation et alertes des échecs

• Erreurs de configuration de la sécurité

• Défaillances logicielles ou d’intégrité des données

Les cybercriminels profitent des faiblesses des mécanismes d’authentification pour voler les identifiants des utilisateurs et mener des activités malveillantes. Les échecs d’authentification comprennent des politiques de mots de passe faibles, l’absence de méthodes d’authentification fortes, une gestion de session inappropriée et une protection insuffisante contre les techniques de piratage de mots de passe telles que les attaques par force brute, qui permettent aux attaquants de trouver les bons mots de passe en plusieurs tentatives, ou le bourrage d’identifiants, qui permet d’accéder aux comptes d’un utilisateur via des paires nom d’utilisateur/mot de passe compromises.

Le contrôle d’accès détermine qui est autorisé à accéder aux données ou aux ressources, et quelles actions cette personne peut effectuer. Des contrôles défaillants ou appliqués incorrectement peuvent entraîner un accès non autorisé et un abus de privilèges. Les menaces peuvent impliquer de modifier les requêtes API et les paramètres d’URL pour contourner les contrôles d’accès ou des références directes d’objets directs non sécurisées permettant de référencer directement des données ou des ressources en utilisant leurs identifiants uniques, sans vérifier les autorisations.

Les failles des méthodologies cryptographiques peuvent exposer des données sensibles et entraîner des violations de données. Les défaillances cryptographiques englobent des algorithmes de chiffrement obsolètes ou faibles, des protocoles de gestion des clés inadéquats, l’utilisation de clés codées en dur et la transmission ou le stockage de données sans un chiffrement approprié.

Les attaques par injection sont l’un des types de vulnérabilités de sécurité les plus courants. Des entrées malveillantes, qu’il s’agisse de code, de commandes, de requêtes ou de scripts, sont insérées dans un programme ou une page web afin de lancer des logiciels malveillants, modifier des données ou voler des informations privées, entre autres actions malveillantes. Le cross-site scripting (scripts intersites), le cross-site request forgery (falsification des requêtes intersites) et le server-side request forgery (falsification des requêtes côté serveur) sont quelques-unes des attaques par injection les plus courantes.

Le cross-site scripting (XSS) déploie du code ou des scripts non approuvés sur des sites web de confiance, qui sont ensuite exécutés par des utilisateurs peu méfiants. Cela se produit généralement lorsqu’une application ne parvient pas à accéder aux données fournies par les utilisateurs, à les filtrer, à les nettoyer ou à les valider.

Le processus de cross-site request forgery (CSRF ou XSRF) envoie des requêtes non autorisées à un site web depuis un utilisateur authentifié. Cette méthode profite de la confiance qu’un site a dans le navigateur web d’un utilisateur authentifié, en utilisant des liens ou des scripts qui trompent le navigateur pour qu’il envoie des requêtes malveillantes à un site cible.

La méthode de server-side request forgery (SSRF) manipule les URL envoyées à un serveur. Lorsque le serveur capte la requête manipulée sans d’abord valider l’URL, cette requête peut être utilisée pour se connecter à des services internes tels que des bases de données ou des fichiers de lecture, la configuration du serveur et d’autres métadonnées.

La conception non sécurisée concerne les vulnérabilités causées par des failles dans la logique commerciale ou l’architecture de l’application. Elle intervient plus tôt dans le cycle de développement durable, pendant la phase de planification, lors de la définition des besoins et de l’élaboration du schéma directeur du système. Des facteurs tels que l’absence d’évaluation des risques, une utilisation limitée de modèles de conception sécurisés et d’architectures de référence, ainsi qu’une modélisation des menaces minimale pour analyser systématiquement les vulnérabilités de sécurité potentielles dans l’architecture prévue sont autant d’éléments qui contribuent à affaiblir la sécurité d’une conception.

Des alertes et des journaux inadéquats ou inefficaces peuvent conduire à des attaques et des brèches non détectées, ce qui permet aux acteurs malveillants de causer de graves dommages. Certains échecs de journalisation et d’alertes impliquent des événements critiques qui ne sont pas enregistrés ou qui sont enregistrés de manière incohérente, un stockage de journaux non sécurisé qui peut être sujet à la falsification ou à un accès non autorisé, des alertes insuffisantes pour des attaques actives en temps réel ou en temps quasi réel, consigner les messages qui sont peu clairs ou qui manquent de détails ou de contexte, ainsi que les journaux qui contiennent des données sensibles sans les masquer ou les nettoyer.

Cette vulnérabilité se produit lorsque les paramètres de sécurité de la pile d’applications, notamment les services cloud, les bases de données, les cadres des exigences, les bibliothèques, les systèmes d’exploitation et les serveurs web ne sont pas configurés correctement. Les erreurs de configuration de sécurité concernent les mises à jour de sécurité désactivées, les autorisations trop étendues, les identifiants par défaut non modifiés et les fonctionnalités inutiles toujours activées.

Ces défaillances sont liées à l’absence de protections contre l’autorisation ou le traitement de données non valides ou non autorisées provenant de sources externes. Parmi les exemples, citons l’application automatique des mises à jour logicielles sans valider leur intégrité, l’utilisation de sources non autorisées pour les dépendances comme des bibliothèques et des plugins tiers, ainsi que les pipelines CI/CD qui extraient du code ou d’autres artefacts de développement logiciel sans les vérifier.

Certaines technologies d’IA générative peuvent contribuer à la programmation sécurisée. Par exemple, les plateformes de codage basées sur l’IA agentique telles que Claude Code et IBM Bob peuvent détecter des vulnérabilités et proposer des correctifs pour le code non sécurisé en temps réel. Les outils de génération de code par IA peuvent également aider à restructurer le code pour améliorer la sécurité.

Bien qu’ils puissent automatiser et accélérer le développement de logiciels, les assistants de codage basés sur l’IA ont tout de même besoin de directives pour générer du code sécurisé. Les programmeurs doivent fournir des prompts clairs qui précisent non seulement les fonctionnalités, mais aussi les exigences de sécurité. Par exemple, un prompt générique tel que « créer une fonction de connexion » peut être développé en ajoutant « créer une fonction de connexion qui vérifie le format et la longueur attendus des entrées de l’utilisateur », afin d’inclure des instructions de codage sécurisées. Le guide de l’Open Source Security Foundation contient des exemples d’instructions pour aider les assistants d’IA à prendre en compte la sécurité du code.

Les équipes d’ingénierie logicielle peuvent également fournir un contexte qui oriente l’IA générative vers la production de code plus sécurisé. La génération augmentée de récupération (RAG) relie les outils de développement alimentés par l’IA à des normes internes de codage sécurisé. Pour les équipes qui ne disposent pas de lignes directrices définies, les règles de sécurité de l’IA de Secure Code Warrior servent de point de départ pour un code généré par l’IA plus sûr.

Comme les assistants d’IA, les agents de codage basés sur l’IA tirent avantage des conseils. Project CodeGuard propose un ensemble de règles et un cadre de compétences qui intègre directement les pratiques de codage sécurisées dans les workflows agentiques. Un agent de codage basé sur l’IA peut utiliser ces règles et compétences lors de la phase de planification dans le cadre de ses objectifs et pendant la phase d’exécution, lors de l’écriture du code.

Le code produit par l’intelligence artificielle elle-même peut introduire des vulnérabilités, de sorte que la dernière décision en matière de précision et de sécurité incombe toujours aux programmeurs humains. Les mesures d’IA générative doivent également être associées aux bonnes pratiques de codage sécurisé ci-dessous afin de créer de multiples niveaux de protection.

Les bonnes pratiques en matière de codage sécurisé englobent diverses stratégies de programmation défensive visant à renforcer la sécurité des logiciels. Les entreprises peuvent être confrontées à la nécessité de trouver un équilibre entre codage sécurisé et vitesse de distribution. Toutefois, bon nombre de ces pratiques intègrent la sécurité au code sans sacrifier la rapidité de distribution, comme intégrer la sécurité dès la phase de conception, établir des directives de codage sécurisé, former les développeurs afin qu’ils soient équipés pour identifier et corriger les failles de sécurité au fur et à mesure du codage, ou encore automatiser l’analyse du code et des tests pour détecter les vulnérabilités.

Bien qu’il soit impossible de mentionner toutes les bonnes pratiques de codage sécurisé existantes, cette liste sert de point de départ. De même, combiner ces pratiques peut améliorer la posture de sécurité d’une entreprise :

• Suivre les normes de codage sécurisé

• Intégrer la sécurité dans la conception

• Valider et nettoyer les entrées et encoder les sorties

• Mettre en œuvre des protocoles cryptographiques robustes

• Authentifier et autoriser

• Établir des mécanismes robustes de journalisation et de gestion sécurisée des erreurs

• Effectuer des tests de sécurité approfondis

• Intégrer la sécurité dans les révisions de code

Ces normes constituent des guides fondamentaux pour intégrer efficacement les techniques de codage sécurisé dans les workflows de développement existants. Elles fournissent une base commune pour la programmation sécurisée dans les projets logiciels.

Le guide du développeur de l’OWASP est une référence pour les programmeurs afin de les aider à naviguer et à créer un code source sécurisé. Le guide décrit les pratiques de codage sécurisé indépendantes de la technologie, les principaux points de sécurité du code soulignés dans des listes de contrôle migrées depuis le guide de référence des pratiques de codage sécurisé de l’OWASP (archivé).

L’OWASP fournit également une série de fiches récapitulatives pour la mise en œuvre des principes de codage sécurisé et la lutte contre un large éventail de vulnérabilités du code.

Créées par le Software Engineering Institute de l’université Carnegie Mellon, les normes de codage SEI CERT  offrent des directives pour une programmation sécurisée dans les langages de programmation Android, C, C++, Java et Perl. Les normes contiennent des règles, des recommandations et des exemples de codes conformes et non conformes. Les règles et recommandations comportent des évaluations des risques correspondantes classées selon la gravité, la probabilité et le coût de la résolution afin d’aider les équipes d’ingénierie logicielle à prioriser leurs efforts.

Parallèlement à son cadre de cybersécurité pour la sécurité de l’information et la gestion des risques de cybersécurité, le National Institute of Standards and Technology (NIST) a également publié son cadre de développement logiciel sécurisé. Le cadre repose sur des pratiques de développement logiciel sécurisées de haut niveau et basées sur les résultats, ce qui en fait un complément idéal aux normes plus techniques de l’OWASP et du SEI CERT.

L’intégration d’une conception sécurisée dans le schéma directeur d’un système s’aligne sur l’approche « shift left » qui consiste à intégrer la sécurité plus tôt dans le processus de développement logiciel. Elle tient compte des moyens pour sécuriser les logiciels avant même que la première ligne de code ne soit écrite.

Des évaluations complètes des risques et une modélisation des menaces peuvent aider à mettre en lumière les vulnérabilités potentielles de sécurité dans l’architecture logicielle. Cette étape implique également les équipes de sécurité pour une collaboration pratique et des conseils sur les exigences de sécurité et leur gestion au niveau du code source.

Pour plus d’informations sur l’intégration de la sécurité dans la conception, les équipes peuvent consulter les fiches de référence de l’OWASP sur la conception sécurisée des produits et la modélisation des menaces, ainsi que son Cadre de sécurisation dès la conception.

L’un des principes fondamentaux du codage sécurisé est de ne jamais faire confiance à une entrée, comme le démontrent les attaques par injection. La validation et la désinfection côté serveur permettent de s’assurer que les entrées ne présentent aucun risque de sécurité avant leur traitement.

Les équipes d’ingénieurs logiciels peuvent placer toute la logique de validation et de nettoyage dans un fichier ou un emplacement central sécurisé afin de maintenir la cohérence et de permettre un accès et des mises à jour rapides et faciles. Ils peuvent également utiliser les modules de validation et de nettoyage intégrés dans les langages et les cadres de programmation, mais ceux-ci doivent être mis à jour régulièrement pour traiter les nouvelles vulnérabilités découvertes.

La validation des entrées vérifie que le type de données, le format, la longueur, l’étendue, la taille et les autres contraintes sont corrects. Cette étape peut impliquer de faire correspondre les entrées à des modèles approuvés ou de les comparer à un ensemble autorisé de caractères ou de valeurs.

Le nettoyage des entrées implique de les nettoyer et de les convertir en un format sûr. Il doit être adapté à un langage ou cadre de programmation.

En HTML, par exemple, l’échappement des caractères spéciaux comme &, <, >, " et ’ peut aider à prévenir les attaques XSS. Des bibliothèques comme DOMPurify peuvent contribuer au nettoyage du HTML.

Pour les bases de données, associer des requêtes paramétrées à des instructions préparées peut aider à prévenir les attaques d’injection SQL, puisque les entrées sont traitées comme des données plutôt que comme du code SQL pouvant être exécuté par inadvertance. Les requêtes paramétrées définissent d’abord tout le code SQL, avec des balises pour les entrées ou paramètres, puis transmettent chaque paramètre à la requête ultérieurement. Les instructions préparées sont des instructions SQL précompilées, ce qui signifie que les commandes SQL injectées ne peuvent pas modifier l’intention d’une requête ou son exécution.

L’encodage des sorties permet aux données d’être affichées en toute sécurité sous forme de texte afin qu’elles ne soient pas interprétées comme du code. De nombreux cadres sont dotés d’une protection par encodage des sorties par défaut, ou de fonctions d’encodage et d’échappement automatiques. L’OWASP Java Encoder prend en charge l’encodage contextuel des sorties pour différents contextes, comme le placement de variables dans une URL, un code CSS ou JavaScript en ligne, ainsi que l’insertion de variables dans une valeur d’attribut HTML, une propriété CSS ou entre deux balises HTML.

Appliquée correctement, la cryptographie protège la confidentialité, l’intégrité et la disponibilité des informations.

Les programmeurs doivent utiliser des algorithmes actuels et puissants lors du chiffrement des données en transit et au repos. L’AES est considéré comme la référence absolue en matière de chiffrement symétrique, avec des modes authentifiés et une clé 256 bits offrant un niveau de sécurité élevé. En matière de chiffrement asymétrique, l’ECC avec une courbe sécurisée ou le RSA avec un remplissage aléatoire activé et une clé d’au moins 2048 bits offrent une sécurité robuste.

Pour protéger les mots de passe, des algorithmes de hachage doivent être appliqués et un sel, c’est-à-dire une chaîne distincte générée aléatoirement, est ajouté au mot de passe dans le cadre du processus de hachage. Un algorithme de hachage est une fonction mathématique unidirectionnelle qui convertit les données en une valeur unique, plus courte et de longueur fixe, qui ne peut être décodée ou inversée. Les algorithmes de hachage modernes comprennent Argon2id et scrypt.

Au lieu de créer les leurs, les développeurs doivent adopter des implémentations fiables, prises en charge et maintenues de bibliothèques cryptographiques telles que Bouncy Castle, Libsodium, OpenSSL et Tink.

Les clés ne doivent pas être codées en dur dans le code source, enregistrées dans les systèmes de contrôle de version, stockées dans des variables d’environnement ou exposées dans des journaux. Les solutions et technologies de gestion des clés peuvent aider à automatiser le cycle de gestion des clés, de la génération, la distribution et le stockage à l’utilisation, la rotation, la révocation et la destruction.

En matière de protection de la couche de transport, les équipes d’ingénierie logicielle doivent utiliser des protocoles tels que Hypertext Transfer Protocol Secure (HTTPS) ou HTTP Strict Transport Security (HSTS) et la dernière version de TLS. La mise en cache des données sensibles doit être désactivée et le stockage inutile de données sensibles doit être évité.

L’authentification et l’autorisation sont des pratiques de codage sécurisées cruciales pour vérifier l’identité d’une entité et s’assurer qu’elle dispose du bon niveau d’accès.

L’authentification à étapes (MFA) est l’une des meilleures défenses contre les attaques liées aux mots de passe. D’autres mécanismes incluent la limitation de la connexion pour empêcher les pirates de deviner trop souvent les mots de passe et le verrouillage des comptes pour bloquer les tentatives de connexion pendant une certaine période après plusieurs échecs de connexion.

Pour l’authentification sans mot de passe, les développeurs peuvent envisager des protocoles tels qu’OpenID Connect (OIDC) et Security Assertion Markup Language (SAML). Les normes ouvertes FIDO et FIDO2 facilitent l’authentification sans mot de passe via des clés d’accès et peuvent être utilisées pour authentifier des applications, des services en ligne et des sites web.

Une fois qu’une session authentifiée a été établie, elle doit être maintenue grâce à des identifiants de session sécurisés ou à des tokens. Les identifiants de session doivent être générés à l’aide d’un générateur de nombres pseudo-aléatoires à forte sécurité cryptographique. Comme pour toute autre entrée utilisateur, les identifiants de session ou les tokens doivent être validés avant traitement, les valeurs non valides étant filtrées.

Définir un délai d’expiration pour chaque session limite la durée pendant laquelle les acteurs malveillants peuvent détourner des sessions actives et lancer des attaques. Les équipes d’ingénierie logicielle peuvent utiliser les fonctionnalités intégrées de gestion des sessions fournies par les cadres de développement web.

Les programmeurs peuvent utiliser des protocoles d’autorisation comme OAuth, qui fonctionnent en tandem avec le protocole d’authentification OIDC. En termes de contrôle d’accès, le contrôle d’accès basé sur les rôles (RBAC) est un modèle populaire, où les utilisateurs accordent l’accès en fonction de leur rôle prédéfini. D’autres options plus robustes et prenant en charge des autorisations plus précises incluent le contrôle d’accès basé sur les attributs (ABAC) et le contrôle d’accès basé sur les relations (ReBAC). L’ABAC analyse les attributs des utilisateurs, des objets et des actions comme le nom d’un utilisateur, le type d’une ressource ou l’heure de la journée, afin de déterminer si l’accès sera accordé. Le ReBAC accorde l’accès en fonction des relations entre les ressources.

Même si des protocoles et des modèles de contrôle d’accès sont en place, les autorisations doivent toujours être validées pour chaque demande et des contrôles d’accès doivent être effectués pour chaque objet auquel une entité tente d’accéder. Le refus de l’accès par défaut et l’application du moindre privilège sont également des principes de codage sécurisés essentiels en matière d’autorisation.

Les journaux et les messages d’erreur peuvent être de précieuses sources d’informations pour aider les acteurs malveillants à concevoir des attaques. Cela signifie que les journaux et les erreurs doivent être traités avec le plus grand soin.

Les erreurs d’application, les événements système liés aux modifications apportées à la configuration et aux actions d’administration ou privilégiées, ainsi que les événements d’échec dans les domaines de l’authentification, de l’autorisation, de la validation des entrées et de la gestion des sessions doivent tous être enregistrés, car ils peuvent indiquer des tentatives de violation. Des informations suffisantes doivent être incluses, telles que les détails de l’utilisateur (identité, rôles et autorisations) ainsi que le contexte de l’erreur ou de l’événement (cible, action et résultat), pour faciliter l’analyse et le débogage.

Les journaux doivent être écrits sur des dispositifs en lecture seule et stockés dans un emplacement sécurisé avec un accès restreint et une détection d’altération intégrée. Si des journaux doivent être envoyés à d’autres systèmes, un protocole de transmission sécurisé doit être utilisé.

Les données sensibles ne doivent pas être enregistrées et doivent être nettoyées ou supprimées des journaux. Toute autre information critique, telle que les chaînes de connexion à la base de données, les chemins de fichiers, les noms et adresses des réseaux internes, les identifiants de session ou les tokens, doit être cryptée, hachée ou masquée.

Les bibliothèques de journalisation doivent être mises à jour périodiquement pour s’assurer que les faiblesses de sécurité sont corrigées, comme le démontre la vulnérabilité Log4Shell qui affecte la bibliothèque de journalisation open source largement déployée Log4j et permet aux hackers d’exécuter presque n’importe quel code sur les systèmes affectés.

La gestion des erreurs va de pair avec la journalisation, car les informations sur les erreurs apparaissent généralement dans les journaux. De même, les erreurs non gérées peuvent servir de point d’entrée aux acteurs de la menace.

Les développeurs peuvent envisager de créer un gestionnaire d’erreur global qui renvoie une réponse générique ou un code d’erreur pour les erreurs inattendues, puis enregistre plus de détails sur l’erreur côté serveur. Cela permet d’éviter de divulguer des informations à des pirates tout en traitant les erreurs en toute sécurité et en fournissant les informations nécessaires aux programmeurs pour qu’ils puissent approfondir leurs recherches.

Toutes les mesures de sécurité intégrées au code source doivent être vérifiées. Les équipes de QA et de développement peuvent se référer au Guide de test de sécurité web et à la Norme de vérification de la sécurité des applications de l’OWASP comme base pour tester la sécurité du code. Des outils automatisés peuvent également faciliter ce processus.

Les tests statiques de sécurité des applications (SAST) appliquent des règles prédéfinies pour repérer des schémas dans le code qui indiquent des vulnérabilités probables. Le SAST est parfois appelé test en « boîte blanche », tandis que les outils SAST sont également appelés analyseurs de code statique, car ils analysent le code sans avoir à exécuter l’application.

Les outils SAST excellent lorsqu’il s’agit de signaler les vulnérabilités courantes du code et peuvent déterminer le numéro de ligne exact et le fichier des vulnérabilités qu’ils détectent. Ils s’intègrent également de façon fluide à la plupart des IDE et des environnements CI/CD. Cependant, ils sont susceptibles de générer des faux positifs.

Le test dynamique de sécurité des applications (DAST) adopte une approche externe, évaluant les applications dans leurs environnements d’exécution en utilisant des attaques simulées pour imiter les actions d’acteurs de la menace réels. C’est pourquoi le DAST est souvent qualifié de test en boîte noire, car les testeurs n’ont pas besoin de connaître le fonctionnement interne ou le code source d’un système ni d’y accéder. Le DAST produit généralement moins de faux positifs que le SAST.

Le couplage des tests SAST et DAST permet de dresser un tableau plus complet des vulnérabilités potentielles. Pour des tests de sécurité encore plus complets, les tests SAST et DAST peuvent être combinés avec d’autres méthodes, telles que le test interactif de sécurité des applications (IAST) qui évalue à la fois le contexte du code et le comportement à l’exécution pour signaler les vulnérabilités en temps réel, et l’analyse de composition logicielle (SCA), qui analyse les logiciels afin de garantir la sécurité et la mise à jour des composants.

La plupart des révisions de code se concentrent sur la qualité, examinant le code pour s’assurer qu’il respecte les directives stylistiques, les problèmes logiques, le flux optimal et la couverture des tests et des cas limites. Mais la sécurité doit également faire partie du processus de révision du code.

Les révisions de code sécurisées constituent la deuxième ligne de défense après les analyseurs de code statique. Les réviseurs de code humains apportent une expertise, un jugement et des informations sur les vulnérabilités de sécurité du code que les outils automatisés manquent souvent de prendre en compte.

Pour une approche plus structurée, les réviseurs peuvent consulter l’aide-mémoire sur la révision de code sécurisée de l’OWASP.