En bref : évaluez votre programme de sécurité applicative par rapport à OWASP ASVS.
L'OWASP ASVS est un critère d'évaluation, pas une certification. Sa valeur dépend de ce que vous mesurez avec, et des preuves que vous pouvez fournir lorsqu'on vous demande à quel niveau votre application correspond.
- Il n'existe pas de certification officielle OWASP ASVS. La valeur d'une affirmation de niveau dépend de la vérification qui la sous-tend, c'est pourquoi les acheteurs et les auditeurs demandent de plus en plus comment elle a été vérifiée.
- Les organisations l'utilisent principalement de quatre manières : en tant que base de développement sécurisée, périmètre de test d'intrusion, exigence d'approvisionnement et feuille de route axée sur les écarts.
- L'adoption se heurte à des problèmes de périmètre et de propriété, et non de connaissances en matière de sécurité. De nombreuses exigences s'avèrent inapplicables ou appartiennent à une autre équipe.
- La version est importante. ASVS 5.0 a remanié les niveaux en 2025, donc chaque réclamation et chaque contrat doivent indiquer la version, par exemple.
v5.0.0. - Automatisez ce que vous pouvez, vérifiez le reste. Les résultats de l'analyseur, mis en correspondance avec les identifiants d'exigences OWASP ASVS, permettent de maintenir à jour une partie du référentiel ; les revues de conception et les tests couvrent le reste.
Presque toutes les équipes de sécurité applicative ont entendu parler de la vérification de sécurité des applications OWASP. Standard, plus connue sous le nom d'OWASP ASVS. Beaucoup moins d'entreprises sont capables d'affirmer avec certitude le niveau de certification atteint par leurs applications, ou de le prouver à un auditeur ou à un client. C'est précisément dans cette lacune que réside la valeur, ou la faiblesse, de l'OWASP ASVS.
Cet article ne résume pas standard, Parce que le standard Elle le fait très bien. Elle examine comment les organisations utilisent réellement OWASP ASVS, où l'adoption crée des frictions, comment standard a mûri en 18 ans, et comment comparer votre propre programme à celui-ci.
Qu'est-ce que l'OWASP ASVS, en un paragraphe
Lancé en 2008, OWASP ASVS est un catalogue d'exigences de sécurité pour les applications web et les API, chaque exigence étant rédigée de manière à pouvoir être vérifiée objectivement. Les exigences sont regroupées en trois niveaux cumulatifs, ce qui permet d'adapter l'effort de vérification au niveau de risque de l'application. Contrairement aux référentiels organisationnels tels que l'ISO 27001, OWASP ASVS fonctionne au niveau des exigences concrètes que les développeurs, les testeurs et les acheteurs peuvent utiliser. La version actuelle, ASVS 5.0, a été lancé en direct lors de la conférence Global AppSec EU à Barcelone en mai 2025.
18 ans sur l'échelle de maturité
OWASP ASVS a beaucoup évolué depuis 2008. La version 4.0 (2019) a restructuré… standard autour du modèle à plusieurs niveaux, et la version 4.0.3 (2021) est devenue la version citée par les équipes d'approvisionnement pendant des années. ASVS 5.0 nous l'avons modernisé : environ 350 exigences réparties en 17 chapitres, un niveau 1 simplifié conçu pour abaisser la barrière à l'entrée, de nouveaux chapitres sur la sécurité des interfaces Web et les jetons autonomes, et un site Web dédié.
La tendance observée sur ces 18 années est claire : le standard a mûri plus vite que son adoption. De nombreuses organisations font encore référence aux exigences de la version 4.x dans leurs contrats et audits, alors que ces exigences ont évolué.
Qui utilise OWASP ASVS, et dans quel but ?
Cinq utilisations concrètes, leurs avantages et leurs points faibles.
| Utilisez le | Qui l'utilise | Ce qu'il offre | Là où ça casse |
|---|---|---|---|
| Base de développement sécurisée | Développeurs et architectes | Une définition concrète de « suffisamment sécurisé », utilisable comme critère d'acceptation | Des centaines d'exigences, dont beaucoup ne sont pas applicables ou appartiennent à une autre équipe. |
| périmètre du test d'intrusion et de l'audit | Testeurs et auditeurs | Des rapports qui associent les résultats aux identifiants des exigences et qui indiquent la couverture, et non pas une simple liste de bogues. | Les résultats ne sont comparables que si l'oscilloscope précise à la fois le niveau et la version. |
| Achats et contrats | Équipes de gestion des risques des acheteurs et des fournisseurs | Une exigence claire dans les appels d'offres et les contrats : « le système livré doit être conforme au niveau 2 de la norme ASVS ». | Aucune certification officielle n'est fournie ; l'acheteur doit donc définir les preuves qu'il acceptera. |
| GRC et preuves de conformité | Équipes de conformité | Correspondances avec des référentiels tels que l'ISO 27001 et le PCI DSS pour la préparation aux audits | Reste souvent technique standard que les outils GRC ne suivent pas |
| Analyse des écarts et feuille de route | Responsables de la sécurité des applications | Une liste d'écarts par niveau pouvant être comblée par phases | Elle devient rapidement obsolète à moins d'être revérifiée, tout comme le code et le standard Change |
Là où son adoption crée des frictions
Les témoignages les plus utiles sur l'adoption d'OWASP ASVS proviennent des équipes qui l'ont expérimentée. Le rapport de SoftwareMill sur ce sujet en est un exemple détaillé. mise en œuvre du niveau 2 d'ASVS dans un système existant, une plateforme de microservices mature sur Kubernetes. Quatre leçons se dégagent, et elles correspondent à ce que l'on observe dans l'ensemble du secteur.
Il n'y a pas de certificat à la fin. L'OWASP ne certifie pas les niveaux ASVS. Dans le cadre de ce projet, la vérification combinait des tests d'intrusion à un audit interne basé sur une grille d'auto-évaluation, renouvelée chaque année. Toute mention de « niveau 2 OWASP ASVS » fait référence à un processus de vérification, et les acheteurs apprennent à s'informer sur ce processus.
Le contrôle du périmètre demande plus de travail que la sécurité. Sur les 267 exigences de niveau 2 examinées par l'équipe, plus de la moitié étaient déjà satisfaites et 80 n'étaient pas applicables. Certaines exigences ne relevaient pas de l'équipe : la gestion des identités était assurée par une autre équipe interne, qui devait se soumettre à sa propre vérification ASVS. Un niveau ASVS est associé à un système, et les systèmes transcendent les frontières des équipes.
Les versions dérivent. Entre les versions 4.0.3 et 5.0, certaines exigences ont changé de niveau. Une exigence de validation JSON signalée par l'équipe est passée du niveau 1 au niveau 3 dans la nouvelle version. Un référentiel qui ne fixe pas sa version mesure une cible évolutive.
La question du GRC reste ouverte. OWASP ASVS a été conçu pour être utilisé dans le cadre de contrats : l’acheteur définit un niveau requis et le vendeur prouve que le logiciel y répond. En pratique, de nombreuses organisations utilisent encore OWASP ASVS principalement comme outil d’ingénierie et de test. Les équipes de conformité l’intègrent à des référentiels plus larges, mais le lien entre l’identifiant d’une exigence et la preuve qui la justifie est souvent manuel, ce qui complique la production de rapports continus.
Comment évaluer votre programme de sécurité applicative par rapport à OWASP ASVS ?
Un référentiel pratique ne commence pas par l'exigence 1.1.1. Il commence par decisquestions sur la portée.
- Classez vos applications par niveau et attribuez-leur un niveau cible. Le niveau 1 comme base pour tout, le niveau 2 pour les applications qui traitent des données sensibles, le niveau 3 uniquement pour les systèmes critiques.
- Épingler la version. Effectuez une comparaison avec la version 5.0.0 et citez les identifiants des exigences correspondantes afin que les résultats restent comparables dans le temps.
- Visez avant de marquer. Indiquez par écrit que les exigences ne sont pas applicables et désignez un responsable pour chaque exigence qui dépasse les limites de l'équipe.
- Automatisez la couche vérifiable. Résultats de l'analyseur de cartes (code, infrastructure en tant que code, pipelines) aux identifiants d'exigence OWASP ASVS, de sorte qu'une partie du benchmark est mise à jour à chaque analyse au lieu d'une fois par an.
- Vérifiez le reste à la main. L'architecture, la logique métier et les exigences de processus nécessitent des revues de conception, une modélisation des menaces et des tests.
- Transformer les lacunes en une feuille de route progressive. Combler les lacunes de niveau 1 dans l'ensemble du portefeuille avant de faire passer les applications individuelles au niveau 2.
- Revérifier régulièrement et après des changements importants. Une vérification annuelle est un minimum courant. Des données continues issues de vos outils permettent de raccourcir considérablement la durée de l'examen annuel.
Au-delà de l'application : ASVS et SPVS
OWASP ASVS couvre l'application. Il ne couvre pas la pipeline qui le fabrique et l'expédie, et c'est là que se concentrent désormais bon nombre des attaques les plus dévastatrices contre la chaîne d'approvisionnement. C'est cette faille que… OWASP Secure Pipeline Vérification Standard (SPVS) Il s'agit d'un ensemble de contrôles basés sur la maturité, couvrant les phases de planification, de développement, d'intégration, de mise en production et d'exploitation, qui a atteint la version 1.0 en octobre 2025.
Les deux standardLes deux fonctionnent par paire : ASVS pour ce que vous construisez, SPVS pour la manière dont vous le construisez.
Comment Xygeni associe les résultats à OWASP ASVS
OWASP ASVS est l'un des standardXygeni se concentre principalement sur ce sujet, ainsi que sur les SPV. SAST, IaC et CI/CD Les détecteurs sont associés à l'exigence ASVS à laquelle ils correspondent. Cela modifie la signification d'une détection : il ne s'agit plus simplement d'un « problème dans ce fichier », mais d'une preuve en faveur ou en défaveur d'une exigence spécifique de votre test de performance.
Ces résultats se traduisent en Xygeni ASPM, où elles sont priorisées avec les résultats provenant du reste de votre pile d'analyse. Pipeline conclusions de Xygéni CI/CD Sécurité et IaC chèques Étendez cette logique au-delà du code. Savoir quelles exigences vos outils mettent déjà en évidence vous permet de concentrer la vérification manuelle sur celles qui nécessitent réellement une intervention humaine.
Visualisez vos résultats mis en correspondance avec les exigences OWASP ASVS
Un référentiel mis à jour une fois par an décrit l'application de l'année précédente. Démo pour voir la carte de Xygeni SAST, IaC et CI/CD résultats conformes aux exigences OWASP ASVS, ou commencer gratuitement et analysez vos premiers dépôts dès aujourd'hui.
QFP
Existe-t-il une certification officielle OWASP ASVS ?
Non. OWASP ne certifie pas les niveaux ASVS. Les organisations les vérifient par le biais de tests d'intrusion, d'audits et d'auto-évaluations ; les preuves à l'appui d'une affirmation de niveau sont donc aussi importantes que l'affirmation elle-même.
Qu'est-ce qui a changé dans ASVS 5.0 ?
La version 5.0, publiée en mai 2025, comporte environ 350 exigences réparties en 17 chapitres, un niveau 1 simplifié, de nouveaux chapitres tels que la sécurité des interfaces Web et des directives mises à jour sur la cryptographie et l'authentification.
Quel niveau OWASP ASVS mon application doit-elle cibler ?
Le niveau 1 constitue la base de toute application, le niveau 2 convient à la plupart des applications métier qui traitent des données sensibles, et le niveau 3 est destiné aux systèmes critiques où une violation aurait de graves conséquences.
Quelle est la différence entre OWASP ASVS et SPVS ?
OWASP ASVS définit les exigences de sécurité de l'application elle-même. SPVS définit des contrôles vérifiables pour les pipeline qui le conçoit, le teste et le livre.
