Faire préciser la demande avant de commander un test
Demandez au client le périmètre attendu, les documents à transmettre, les exigences concernant le prestataire et les critères de traitement des vulnérabilités. Un rapport, une attestation de réalisation et un compte rendu de contre-test répondent à des questions différentes.
- Le client veut-il évaluer tout le SaaS ou seulement l'API et les parcours qu'il utilise ?
- Attend-il un test authentifié avec plusieurs rôles, des vérifications inter-tenant ou une revue externe sans compte ?
- Quelle ancienneté du test accepte-t-il ? Le produit a-t-il changé depuis ?
- Quelles exigences prévoit-il pour le prestataire, la méthode et les preuves de correction ?
- Qui valide le dossier côté client et avant quelle date ?
Si la demande vient d'un questionnaire sécurité, récupérez la question exacte et ses critères. Une case « pentest réalisé » ne précise ni la couverture attendue ni les conditions d'acceptation.
Transformer la demande en périmètre testable
Pour un SaaS B2B, fournissez les URL, la documentation API, les rôles et les opérations sensibles. Préparez deux tenants fictifs et plusieurs comptes autorisés pour vérifier la séparation des données et des privilèges. L'hébergement chez un fournisseur cloud ne prouve pas la sécurité de votre application.
| Attente | Périmètre à préciser | Preuve attendue |
|---|---|---|
| Séparation des données clients | Deux tenants, objets de test, lecture et modification | Résultats des essais autorisés et refusés, limites de couverture |
| Maîtrise des accès support | Rôles support et administrateur, exports, opérations sensibles | Matrice des droits et constats vérifiables |
| Accès via le SSO | Connexion, sessions, désactivation et révocation convenues | Scénarios testés et comportement observé |
| Correction des vulnérabilités | Constats concernés, version corrigée et fenêtre de contre-test | État de chaque correction avec date et périmètre vérifiés |
Les surfaces de pentest SaaS B2B et le cadrage du pentest API détaillent ces contrôles. Le devis doit aussi préciser ce qui est exclu, l'environnement autorisé et les conditions d'intervention.
Réserver du temps pour les corrections et la revue du client
- Cadrage : valider le périmètre, l'autorisation de test et les critères du destinataire.
- Préparation : fournir les accès, les données fictives et un contact disponible pendant la mission.
- Tests et rapport : tester les scénarios convenus puis restituer les constats et leurs limites.
- Corrections : prévoir la disponibilité de votre équipe et prioriser les actions selon le risque.
- Contre-test : vérifier les corrections convenues et documenter les éléments non vérifiés.
- Revue client : transmettre les pièces appropriées et obtenir son retour sur les critères d'acceptation.
Un délai de livraison du rapport commence après la fin des tests. Il ne couvre pas à lui seul les corrections ni la validation du client. La méthodologie et les livrables permettent de distinguer ces étapes.
Choisir le document selon le destinataire
Commencez par convenir des pièces nécessaires. Une synthèse explique le périmètre, les principaux risques et le traitement des constats. Une attestation décrit la réalisation de la mission. Le rapport technique contient les preuves et les détails utiles aux développeurs ; son partage demande un destinataire et un canal convenus.
Une attestation ne certifie pas l'absence de failles. Elle doit préciser les dates, le périmètre et les limites. Si des corrections ont été vérifiées, indiquez la version et la date du contre-test. Gardez distincts les états corrigé, partiellement corrigé, non corrigé et non vérifié.
Notre rapport d'exemple fictif en PDF montre la structure d'un livrable. Il ne constitue pas une preuve pour votre produit et ne présume pas de l'acceptation par votre acheteur.
Exemple fictif de message de cadrage
Notre client demande un pentest du portail et de son API avant une signature prévue dans six semaines. Il souhaite une synthèse du périmètre et des preuves de correction des constats prioritaires. Nous disposons d'une préproduction, de deux tenants fictifs et de comptes lecteur, gestionnaire et support. Pouvez-vous préciser les accès nécessaires, le calendrier des tests et les conditions du contre-test ?
Adaptez ce message à votre situation. L'échéance de six semaines est illustrative. Ne transmettez pas de mot de passe, de jeton ou de rapport sensible dans le premier formulaire de contact.
Questions fréquentes
Un pentest est-il obligatoire pour signer un contrat SaaS ?
Il peut être demandé par votre client dans sa revue de sécurité ou dans le contrat. Cette demande ne constitue pas à elle seule une obligation générale pour tous les SaaS. Faites préciser le produit concerné, les critères d'acceptation, la date du test et les documents attendus.
Faut-il transmettre le rapport technique complet au client ?
Demandez quels documents sont nécessaires. Une synthèse ou une attestation de réalisation peut répondre à certaines demandes, mais le client peut exiger davantage. Si un partage du rapport complet est convenu, définissez le destinataire, les restrictions d'accès et le canal de transmission. Le rapport contient des détails d'exploitation sensibles.
Une attestation de pentest garantit-elle que le produit est sécurisé ?
Non. Une attestation décrit une mission, ses dates, son périmètre et, si cela a été vérifié, l'état des corrections. Elle ne garantit pas l'absence de vulnérabilités et ne remplace pas les critères de sécurité du client.
Combien de temps prévoir avant la signature ?
Prévoyez le cadrage, la préparation des accès, les tests, le rapport, les corrections, le contre-test et la revue du client. Le calendrier dépend du périmètre et de la disponibilité des équipes. Les 48 à 72 heures annoncées pour la livraison du rapport chez Laucked commencent après la fin des tests.
Référence : NIST SP 800-115, planification et restitution des évaluations de sécurité. Les critères d'acceptation et les documents transmis restent à convenir avec votre client.