PREUVE / Analyse d’actualité

OWASP ASVS 5.0 publié le 30 mai 2025 : versionner les exigences

Publié le 1er octobre 2026

Une version publiée, pas une certification

OWASP a publié ASVS 5.0.0 le 30 mai 2025. La page officielle de release présente cette version comme la première de la série 5 et indique des correspondances avec la version 4.0.3. Pour un éditeur qui prépare une vente, l’intérêt est de fixer un langage de vérification partagé avec son cabinet et son acheteur. Cette publication ne crée pas une certification OWASP de votre logiciel et n’impose pas automatiquement de refaire tous les audits existants.

L’événement date de 2025 ; cette analyse est publiée le 1er octobre 2026. Il faut distinguer l’ancienneté de la référence et celle de votre application. Un rapport peut avoir utilisé une version précédente selon la consultation de l’époque. La question commerciale est alors de savoir si ses contrôles et sa couverture répondent encore à la demande actuelle du grand compte.

Ce que cela change dans une consultation

Notre conseil pratique est de nommer la version dans le cahier des charges et dans la matrice de couverture. Une mention « selon OWASP » ne précise ni les exigences retenues ni la méthode. Demandez au cabinet quels contrôles peuvent être vérifiés par des tests dynamiques et lesquels nécessitent d’autres informations. Les exclusions doivent être expliquées avant commande, surtout si le client attend un niveau de couverture particulier.

Pour une migration de matrice, conservez les anciennes références et examinez les correspondances. Ne remplacez pas les identifiants par une nouvelle numérotation sans vérifier leur sens. Le CTO doit pouvoir relier chaque contrôle au comportement attendu et aux preuves disponibles. Le commercial dispose d’une synthèse qui indique la version retenue sans annoncer une conformité globale non démontrée.

Décision à prendre côté éditeur

Si une revue grand compte est en cours, demandez la version attendue par l’acheteur. Comparez cette attente avec le rapport existant et les changements intervenus sur le produit. Un complément ciblé peut être discuté avec le cabinet ; une nouvelle mission peut aussi être nécessaire selon les écarts. Cette décision relève du périmètre réel et de la clause, pas de la seule existence d’une nouvelle release.

Préparez un registre des exigences retenues avec leur référence, leur état et le responsable de la preuve. Un contrôle non vérifié reste distinct d’un contrôle sans écart observé. Les corrections planifiées ne deviennent pas positives dans la matrice avant validation. Le retest doit rattacher ses résultats aux constats et aux contrôles concernés.

Questions à poser avant signature

Quelle version figurera dans le rapport ? Comment les contrôles non applicables seront-ils justifiés ? Quels accès et documents sont nécessaires ? Le cabinet produit-il une matrice lisible par l’équipe sécurité du client ? La pièce amendée après correction conserve-t-elle les mêmes références ? Ces questions permettent de comparer les offres sans demander une promesse d’absence de vulnérabilité.

Le format de partage doit aussi être prévu. Une matrice peut révéler des détails internes dans ses commentaires. Préparez une synthèse adaptée au destinataire, avec les limites utiles à sa décision. Les secrets et données réelles restent hors du dossier commercial.