01Top 10 : un vocabulaire commun, pas un standard
L'OWASP Top 10 est un document de sensibilisation : il nomme les principales catégories de risques pour les applications web, dérivées d'analyses de données et d'enquêtes auprès de la communauté. L'édition actuelle 2025 – la huitième au total – s'appuie sur des données portant sur plus de 2,8 millions d'applications testées et prend en compte 589 CWE ; les catégories « Software Supply Chain Failures » (A03) et « Mishandling of Exceptional Conditions » (A10) font leur apparition, tandis que « Broken Access Control », qui englobe désormais aussi le SSRF, reste en première position. Pour les équipes de développement, le Top 10 convient comme point d'entrée et vocabulaire commun avec le management et les auditeurs – il n'est pas conçu comme liste d'exigences vérifiables ni comme catalogue de tests. Pour cela, l'OWASP renvoie elle-même à l'ASVS et au WSTG.
02ASVS 5.0 : des exigences de sécurité vérifiables
L'Application Security Verification Standard (ASVS) traduit la notion d'« application sécurisée » en exigences concrètes et vérifiables. La version 5.0.0 (publiée le 30 mai 2025) compte 345 exigences réparties en 17 chapitres – de l'autorisation à OAuth/OIDC en passant par la cryptographie – et trois niveaux : le niveau 1 comme porte d'entrée dans l'utilisation de l'ASVS, le niveau 2 comme niveau de sécurité standard complet, le niveau 3 pour les applications à fort besoin de protection. Les exigences étant également disponibles dans des formats lisibles par machine (CSV et JSON), elles peuvent être reprises directement dans les backlogs et les critères de definition of done – et servir de référentiel objectif dans les appels d'offres et les contrats fournisseurs.
03Cheat Sheets et Developer Guide : diffuser le savoir dans l'équipe
La Cheat Sheet Series fournit des guides compacts et orientés mise en œuvre sur des sujets précis – du stockage des mots de passe à la gestion des secrets en passant par la prévention des injections – dans actuellement 120 cheat sheets maintenues en continu (état : juillet 2026). Des vues d'index relient les sheets à l'ASVS, au Top 10 et aux Proactive Controls, de sorte que l'aide à la mise en œuvre adaptée se trouve directement pour chaque exigence – idéal pour l'onboarding des nouvelles développeuses et des nouveaux développeurs et comme référence lors des revues de code. L'OWASP Developer Guide, l'un des plus anciens projets OWASP (publié pour la première fois en 2002, actuellement en version 4.x), se veut délibérément un guide d'orientation : il ne duplique aucun contenu, mais sert d'ouvrage d'introduction et de synthèse à travers l'écosystème OWASP.
04WSTG : dériver des cas de test pour la vérification
Le Web Security Testing Guide (WSTG) est la méthodologie de référence pour les tests de sécurité des applications web. La version stable actuelle 4.2 (décembre 2020) identifie chaque scénario de test par un identifiant unique au format WSTG-<catégorie>-<numéro> ; la version 5.0 est en cours d'élaboration publique sur GitHub et doit être considérée comme un travail en cours. Les équipes utilisent le WSTG pour dériver des plans de test pour les releases, structurer les tests de sécurité internes et définir de manière traçable le périmètre des tests d'intrusion externes – les identifiants de test stables créent un langage commun entre développement, testeurs et prestataires.
05Outils : Dependency-Check, Dependency-Track et ZAP
Au niveau des outils, l'écosystème met à disposition des briques open source prêtes à l'emploi. Dependency-Check (projet phare de l'OWASP), outil d'analyse de composition logicielle, vérifie les dépendances d'un projet par rapport aux vulnérabilités publiquement connues de la NVD et s'intègre au build via CLI, Maven, Gradle, Jenkins ou Azure DevOps. Dependency-Track (également projet phare) élève cela au niveau du portefeuille : la plateforme évalue en continu les SBOM CycloneDX, prend en charge VEX et rend visibles les risques liés aux vulnérabilités, aux versions et aux licences sur l'ensemble des applications – avec la nouvelle catégorie du Top 10 « Software Supply Chain Failures », une brique qui gagne encore en importance. Le scanner DAST ZAP complète le dispositif par des tests dynamiques automatisés dans la pipeline CI ; il n'est plus un projet OWASP depuis 2023 et est poursuivi depuis 2024 sous le nom « ZAP by Checkmarx », mais reste open source et gratuit.
06Piloter la maturité avec SAMM – et tout articuler
Le Software Assurance Maturity Model (SAMM, version 2 ; release actuelle du modèle v2.2.0 de juillet 2024) ne mesure pas des applications individuelles, mais le processus de développement : cinq fonctions métier (Governance, Design, Implementation, Verification, Operations) avec 15 pratiques de sécurité et trois niveaux de maturité chacune – mesurable, orienté action et neutre tant sur le plan technologique que sur celui des processus. Un assessment SAMM montre où en est l'organisation et fournit une feuille de route priorisée. Il en résulte l'articulation au quotidien : les exigences passent de l'ASVS au backlog, les Cheat Sheets et le Developer Guide soutiennent la mise en œuvre et l'onboarding, le WSTG structure la vérification, Dependency-Track, Dependency-Check et ZAP automatisent les contrôles dans la pipeline – et SAMM rend les progrès mesurables et pilotables à l'échelle de toutes les équipes.