Secure Coding – éviter les vulnérabilités avant qu'elles n'apparaissent

Le CWE Top 25 de MITRE classe les catégories de faiblesses logicielles les plus dangereuses ; l'édition 2025 s'appuie sur 39 080 enregistrements CVE couvrant la période de juin 2024 à juin 2025, pondérés par fréquence et sévérité CVSS moyenne. En tête figurent le Cross-Site Scripting (CWE-79), l'injection SQL (CWE-89) et le Cross-Site Request Forgery (CWE-352) – des schémas connus depuis des décennies, qui restent pourtant les causes les plus fréquentes des CVE réelles. Deux blocs se distinguent par ailleurs : les erreurs mémoire comme Out-of-bounds Write/Read et Use After Free (surtout dans les bases de code C/C++), ainsi que pas moins de quatre faiblesses d'autorisation (CWE-862, CWE-863, CWE-284, CWE-639). Pour le secure coding, la conclusion est claire : la plupart des vulnérabilités suivent des schémas connus et évitables – et peuvent être traitées de manière ciblée.

L'OWASP Top 10 regroupe des faiblesses individuelles en catégories de risques ; l'édition 2025 est la version publiée actuelle et s'appuie sur des données de test issues d'environ 2,8 millions d'applications. Broken Access Control reste en première position et englobe désormais aussi le Server-Side Request Forgery ; les nouveautés sont A03 « Software Supply Chain Failures », extension de l'ancienne catégorie « Vulnerable and Outdated Components », ainsi que A10 « Mishandling of Exceptional Conditions ». Injection (A05), Security Misconfiguration (A02) et Cryptographic Failures (A04) restent bien représentées. Le Top 10 se prête bien à la sensibilisation et à la priorisation – mais il ne remplace pas un catalogue d'exigences complet pour le développement.

L'OWASP Application Security Verification Standard traduit le secure coding en exigences vérifiables. La version 5.0.0 (publiée en mai 2025) comprend environ 350 exigences réparties en 17 chapitres – de l'encodage et de la sanitization à Secure Coding and Architecture, en passant par l'autorisation, la gestion des sessions et la cryptographie. Les trois niveaux ont été redéfinis par rapport à la 4.x et ordonnés par priorité : L1 constitue le point d'entrée avec environ 20 pour cent des exigences (première ligne de défense critique), L2, niveau cible pour la plupart des applications, en ajoute environ 50 pour cent, et L3 regroupe les mesures de défense en profondeur restantes. En pratique, l'ASVS sert de référentiel d'exigences pour le développement et les achats, tout comme d'étalon de contrôle pour les revues de code et les tests d'intrusion.

Quatre pratiques couvrent une grande partie de la cartographie des vulnérabilités. Premièrement, la validation des entrées : vérifier toutes les entrées côté serveur au moyen de listes d'autorisation (type, longueur, plage de valeurs, syntaxe permise) – cela réduit la surface d'attaque, mais ne remplace pas l'encodage. Deuxièmement, l'encodage de sortie contextuel et les requêtes paramétrées : ils neutralisent à la racine les classes d'injection comme le XSS et l'injection SQL. Troisièmement, l'autorisation selon le principe « deny by default » : chaque contrôle d'accès aux objets et aux fonctions effectué côté serveur et de manière centralisée (policy ou middleware) plutôt que par des vérifications dispersées – précisément contre les classes CWE-862 et CWE-639, bien placées dans le classement CWE. Quatrièmement, la gestion des secrets : aucun identifiant ni aucune clé dans le code source ou les dépôts, mais des coffres de secrets centralisés avec rotation et permissions minimales, complétés par un secret scanning dans la pipeline.

Le secure coding n'est efficace que s'il est ancré dans le processus de développement. Le SAST analyse le code source dès la pull request et détecte des schémas comme les points d'injection ou les secrets codés en dur ; le DAST teste l'application en fonctionnement et identifie les problèmes de configuration et d'exécution – les deux se complètent, mais ne se remplacent pas. Les revues de code de sécurité manuelles restent indispensables pour les failles de logique comme l'absence d'autorisation, car les outils automatisés détectent rarement ce type d'erreurs. Le cadre organisationnel est fourni par le NIST Secure Software Development Framework (SP 800-218, version 1.1) avec quatre groupes de pratiques, de la préparation de l'organisation à la réaction aux vulnérabilités ; les niveaux ASVS et les classes CWE fournissent le référentiel de fond pour les quality gates et les métriques.

Standards et outils échouent sans développeuses et développeurs capables de les appliquer. Un accompagnement efficace est spécifique aux rôles et à la stack : des formations alignées sur les classes de vulnérabilités réellement trouvées dans son propre code plutôt que des formations annuelles génériques, complétées par des security champions dans les équipes comme premier point de contact. Tout aussi importante est la logique de la « paved road » : des bibliothèques validées, des paramètres par défaut sécurisés des frameworks et des modèles qui font de l'option sécurisée la plus simple – l'OWASP Top 10 Proactive Controls 2024 (C1–C10) offre pour cela une liste de priorités compacte et proche des développeurs. Le programme devient mesurable grâce à des indicateurs comme le taux de récurrence des différentes classes de vulnérabilités et le délai de correction.