PREUVE / Feuillet de consultation
OWASP ASVS et pentest : transformer un référentiel en critères vérifiables
Mis à jour le
Transformer une référence en demande vérifiable
ASVS fournit des exigences de vérification de la sécurité applicative. Le WSTG propose un guide de tests web. Ces documents peuvent aider à structurer une mission, mais ils n’ont pas le même rôle. Une clause « pentest OWASP » reste trop vague pour acheter une prestation comparable. Demandez au client et au cabinet quelle version, quels contrôles et quelles preuves sont attendus. Le nom OWASP ne constitue pas une certification du SaaS.
La consultation doit distinguer le catalogue d’exigences, les techniques d’examen et les scénarios métier. Un cabinet peut utiliser plusieurs références tout en adaptant son travail à votre architecture. Le CTO fournit les fonctions sensibles et les règles de droits. L’acheteur confirme la forme de couverture qui lui permet de décider. Cette préparation évite de découvrir après l’audit que le client attendait une matrice absente du devis.
Fixer la version et les identifiants
La version 5.0.0 d’ASVS a été publiée le 30 mai 2025. Les identifiants peuvent changer entre versions ; le projet recommande de les citer avec la version. Dans votre contrat, utilisez une référence explicite plutôt que « dernière version » sans date. La matrice restera compréhensible si le référentiel évolue pendant la période de vente. Conservez également la version de votre application évaluée.
Une ancienne consultation ne doit pas être renumérotée automatiquement avec le nouveau catalogue. Examinez les correspondances et les changements avec le cabinet. Un identifiant semblable peut porter une exigence différente. La matrice doit indiquer le texte utile, la référence et le mode de vérification prévu. Le commercial n’a pas à interpréter seul ces écarts lorsqu’il répond à un questionnaire du grand compte.
Sélectionner une couverture pertinente
Les exigences retenues dépendent du produit, du risque et des informations disponibles. Une vérification dynamique ne peut pas nécessairement établir toutes les propriétés du code ou de l’organisation. Demandez quels contrôles sont examinés par test, revue documentaire ou revue de code. Les exclusions et les éléments non applicables doivent être justifiés. Un tableau rempli sans preuve ne constitue pas une couverture démontrée.
La sélection doit conserver les parcours sensibles : authentification, droits, séparation des organisations, gestion des données et opérations métier selon votre SaaS. Il peut être pertinent d’ajouter des scénarios qui ne se résument pas à une ligne ASVS. Le référentiel sert de langage commun ; il ne remplace pas la compréhension du fonctionnement de l’application et des attentes du client.
Définir les statuts de la matrice
Prévoyez des états compréhensibles : vérifié sans écart observé, écart constaté, non vérifié et non applicable avec justification. Évitez un seul mot « conforme » qui recouvre des situations différentes. Chaque écart doit renvoyer à un constat stable. Les preuves sensibles restent dans le rapport technique ; la synthèse peut présenter la couverture et les réserves nécessaires à la décision d’achat.
Le cabinet doit expliquer les limites de temps et d’accès. Si un rôle manque ou si une fonction est indisponible, le contrôle concerné peut rester non vérifiable. Cette situation n’autorise pas à cocher une réponse positive dans le questionnaire client. Votre équipe peut préparer un complément ou une nouvelle session, puis mettre à jour la matrice avec sa date et le résultat réellement obtenu.
Utiliser les résultats dans le développement
Rattachez les constats aux tâches de correction et aux critères internes de recette. Une exigence versionnée peut aider les développeurs à comprendre la propriété attendue, mais le scénario observé reste essentiel. Après correction, le retest indique les contrôles revérifiés. Les autres lignes ne deviennent pas automatiquement validées parce qu’un composant partagé a été modifié.
Pour les futurs changements, conservez les contrôles pertinents dans votre démarche de développement. Une matrice ponctuelle ne prouve pas que chaque livraison ultérieure a été examinée. Le dossier de vente doit mentionner le contexte du rapport et les évolutions susceptibles de réduire sa représentativité. Si l’acheteur exige un niveau ou une couverture spécifique, faites confirmer cette demande avant de commander le cabinet.
Grille de vérification avant commande
Pour « OWASP ASVS et pentest : transformer un référentiel en critères vérifiables », conservez les réponses suivantes dans votre dossier achat. Une case vide devient une demande de clarification. Elle ne doit pas être interprétée comme un engagement inclus dans le prix ou comme une preuve déjà disponible.
- Distinguer catalogue d’exigences ASVS et méthode de test WSTG. Demandez au candidat de préciser sa proposition, les éléments nécessaires et les limites. Conservez sa réponse avec la version de la consultation pour que le CTO et la direction commerciale puissent vérifier l’offre retenue.
- Sélectionner niveau et exigences pertinents avec identifiants versionnés. Demandez au candidat de préciser sa proposition, les éléments nécessaires et les limites. Conservez sa réponse avec la version de la consultation pour que le CTO et la direction commerciale puissent vérifier l’offre retenue.
- Exiger matrice de couverture et éléments hors périmètre, sans déclarer une certification OWASP. Demandez au candidat de préciser sa proposition, les éléments nécessaires et les limites. Conservez sa réponse avec la version de la consultation pour que le CTO et la direction commerciale puissent vérifier l’offre retenue.
| Décision | Pièce à conserver | Responsable à désigner |
|---|---|---|
| Périmètre et exclusions acceptés | Version de la consultation et réponse détaillée du candidat, avec les interfaces et rôles concernés | Responsable technique de l’application |
| Format de preuve attendu | Confirmation du grand compte sur les documents, la langue et les conditions de revue | Interlocuteur commercial avec l’équipe sécurité client |
| Traitement des résultats | Plan de correction, critères de recette et conditions de retest proposées au devis | Équipe de développement et décideur de risque |
| Autorisation et diffusion | Mandat validé et droits de partage du rapport ou de la synthèse expurgée | Personne habilitée à engager la mission |
La consultation doit conserver les hypothèses qui peuvent changer le prix ou la date : accès non prêts, fonction indisponible, nouvelle version ou extension du périmètre. Demandez au cabinet comment une modification sera approuvée. Le rapport doit refléter la prestation effectivement réalisée. Une correction future, une disponibilité souhaitée et l’accord du grand compte restent des éléments à confirmer, chacun par son responsable.
Sources primaires consultées
Vérification éditoriale : 1er octobre 2026. Les conseils de consultation de ce feuillet sont une application pratique à discuter avec vos responsables et le cabinet.