Le VAPT expliqué : évaluation des vulnérabilités et pentest

Définition

La partie évaluation des vulnérabilités (VA) est étendue. Elle combine le scan automatisé et l'analyse pour identifier, sur les actifs convenus, les correctifs manquants, les composants obsolètes, les services exposés, les configurations faibles et les problèmes web courants. La partie test d'intrusion (PT) est approfondie. Un testeur travaille manuellement sur des cibles sélectionnées, généralement des applications web, des API et des applications mobiles : il valide les constatations et teste l'authentification, la gestion des sessions, le contrôle d'accès entre rôles, l'exposition des données et la logique métier. Ensemble, la VA apporte la couverture et le PT apporte la confiance quant à ce qui est réellement exploitable. Une mission VAPT doit se conclure par un rapport écrit qui consigne le périmètre, la méthode, les constatations classées par gravité avec leurs preuves, les recommandations de remédiation et, si cela a été convenu, le résultat d'un contre-test après correction. Les demandes font parfois référence à des référentiels comme l'OWASP Top 10 ou les recommandations OWASP Mobile Application Security ; ce sont des points de repère utiles sur ce qu'examinent les testeurs.

Public concerné

Le VAPT est couramment demandé par ou pour :

• Les équipes SaaS, fintech et e-commerce dont les grands clients demandent un rapport VAPT récent lors de l'achat
• Les entreprises qui se connectent à un partenaire, une banque ou un prestataire de paiement exigeant des preuves de tests de sécurité avant l'intégration
• Les équipes produit qui préparent le lancement public d'une application web ou mobile
• Les organisations qui ont modifié leur hébergement, leur authentification ou leurs flux de paiement et souhaitent une vérification indépendante

Ce qu'il aide à clarifier

Un VAPT bien cadré permet de clarifier :

• Quelles applications, API et quels environnements le demandeur s'attend réellement à voir testés
• Si l'exigence mentionne un type d'auditeur ou une accréditation spécifique à confirmer avant de choisir un prestataire
• Quelles constatations sont des risques validés et lesquelles sont des observations de scanner
• Quelle remédiation doit être effectuée avant de pouvoir partager un rapport en toute confiance

Ce qui est inclus

• Obtenir par écrit l'exigence exacte du demandeur : actifs, profondeur, format du rapport et éventuels critères applicables au prestataire
• Lister les cibles : domaines, URL des applications, chemins de base des API, versions des applications mobiles et environnements (préproduction ou production)
• Préparer des comptes de test pour chaque rôle utilisateur afin que les tests de contrôle d'accès soient pertinents
• Confirmer l'autorisation écrite, la fenêtre de test, les contacts désignés et les conditions d'arrêt
• Informer les fournisseurs d'hébergement, de CDN ou de WAF si leurs conditions l'exigent
• Convenir des niveaux de gravité, du format du rapport et de la manière dont les preuves seront partagées
• Réserver du temps pour corriger les constatations et demander un contre-test des problèmes convenus

Ce qui n'est pas inclus

• Une déclaration selon laquelle un VAPT rend une application sécurisée ou conforme
• L'affirmation qu'un prestataire satisfait à une exigence d'accréditation ou de référencement spécifique sans l'avoir vérifié au regard de cette exigence
• Le test de systèmes tiers sans l'autorisation de leur propriétaire
• Un conseil juridique ou réglementaire sur ce qu'exige une règle particulière

Quand le choisir

Commandez un VAPT lorsqu'une contrepartie identifiée en demande un, avant un lancement important ou après des changements majeurs dans la façon dont les utilisateurs se connectent, paient ou accèdent aux données. Si la demande émane d'une relation réglementée, lisez attentivement l'exigence : certaines imposent un auditeur accrédité ou référencé (en Inde, certains régulateurs et contreparties font référence aux auditeurs référencés par le CERT-In), un périmètre particulier ou un cycle de tests fixe. Confirmez d'abord ces détails avec le demandeur, car un rapport qui ne correspond pas à l'exigence pourrait devoir être refait. Cet article constitue une information générale et non un conseil juridique ou réglementaire.

Notre approche

Prenez la liste de contrôle du demandeur comme point de départ, puis ajoutez les systèmes qui portent le plus de risque pour votre activité, même si personne ne les a mentionnés. Testez dans un environnement de préproduction qui reflète la production lorsque c'est possible, et convenez à l'avance de la manière dont les tests en production seront gérés s'ils sont nécessaires. Notre service Application Security Review couvre les tests d'applications web et d'API avec des constatations écrites classées par gravité et des recommandations de remédiation ; les périmètres plus larges, multi-environnements ou réseau, sont traités par notre service Penetration Testing. Dans les deux cas, le périmètre, l'autorisation et les modalités de rapport sont confirmés par écrit avant le début des travaux. Après la livraison, corrigez d'abord les constatations de gravité élevée et critique, consignez les décisions concernant les risques acceptés et demandez un contre-test. Partagez ensuite une synthèse pour la direction ou une lettre sur l'état de la remédiation plutôt que le rapport technique complet, sauf si le demandeur a spécifiquement besoin de ce niveau de détail et dispose d'un moyen sécurisé de le recevoir.

Application Security Review

Foire aux questions

Articles connexes