Préparer son premier pentest : le guide pour les équipes tech

Vous avez signé avec un prestataire pentest. Le kick-off est dans deux semaines. Et maintenant ?

On réalise des pentests applicatifs pour des éditeurs SaaS toute l’année. Le constat est toujours le même : la qualité du test dépend autant de votre préparation que de la compétence du pentester. Un périmètre flou, des comptes pas créés, un staging en retard de trois mois sur la prod, et vous payez pour un rapport qui ne couvre pas vos vrais risques.

Le périmètre, c’est 80% du travail

Le périmètre détermine ce que le pentester va tester. Trop large et vous diluez l’effort. Trop restreint et vous passez à côté de vos vraies failles.

Pour un SaaS, le scope typique couvre :

• L’application web que vos clients utilisent
• Les APIs (REST, GraphQL, webhooks). Si votre front consomme une API, cette API est dans le scope
• L’authentification : login, SSO, MFA, gestion des tokens
• Le modèle d’autorisations : isolation entre tenants, escalade de privilèges, qui peut voir quoi
• Les fonctionnalités sensibles : paiement, upload de fichiers, export de données, invitations

Ce qui ne rentre généralement pas dans un premier pentest : l’infra cloud (c’est un audit cloud séparé), les apps mobiles (c’est un audit mobile dédié), les outils internes qui ne sont pas exposés sur Internet.

Concentrez-vous sur ce que vos clients touchent. Si un attaquant compromet votre application, ce sont leurs données qui sont exposées.

Choisir le type de test

Trois approches existent.

Black box : le pentester attaque depuis l’extérieur, sans compte. Il simule un attaquant qui découvre l’app. Le problème : il passe du temps à chercher des points d’entrée au lieu de tester en profondeur. Et surtout, il ne verra jamais les IDOR entre tenants, l’escalade de privilèges, les fuites de données post-authentification. Pour un SaaS multi-tenant, c’est là que sont les vrais risques.

Grey box : le pentester a des comptes avec différents rôles. Il teste ce qu’un client malveillant ou un compte compromis pourrait faire. C’est le scénario d’attaque le plus réaliste pour un SaaS.

White box : le pentester a aussi le code source et l’architecture complète. C’est une revue de code combinée avec un pentest. Couverture maximale, mais plus long et plus cher.

Chez nous, tous les audits incluent un accès au code source, quel que soit le mode. Quand on trouve une vulnérabilité, on remonte à la ligne de code concernée. Ça élimine les faux positifs et ça donne à vos devs un correctif qu’ils peuvent appliquer directement. C’est ce qui distingue un vrai pentest d’un rapport de scanner.

Les accès : préparez-les 3 jours avant, pas le jour J

C’est le point qui fait perdre le plus de temps. Le pentester arrive au kick-off, les comptes ne sont pas créés, le WAF bloque son IP, le staging est down. Sur une mission de 7 jours, perdre 2 jours c’est 30% du budget qui part en fumée.

Des comptes dédiés. Ne recyclez pas des comptes existants. Créez des comptes spécifiques pour le pentest, ça permet d’identifier et nettoyer les actions du pentester après la mission.

Pour un SaaS multi-tenant, il faut au minimum :

• 2 comptes sur le même tenant avec des rôles différents (admin + utilisateur standard). Le pentester vérifie que l’utilisateur ne peut pas faire ce que seul l’admin devrait pouvoir faire.
• 2 comptes sur des tenants différents. Le pentester vérifie que le client A ne peut pas accéder aux données du client B. C’est le test le plus critique pour un SaaS.
• 1 compte avec le rôle le plus bas possible.

La documentation API. Si vous avez un Swagger, un OpenAPI, ou une collection Postman, partagez-la. Le pentester couvrira 100% de vos endpoints au lieu de les découvrir à l’aveugle. Si vous n’avez pas de doc, on peut mapper les endpoints depuis le code source.

L’accès au repo Git. En lecture seule, sur GitHub, GitLab ou Bitbucket. On s’en sert pour valider chaque finding et proposer des correctifs applicables.

Les accès réseau. Si votre app est derrière un WAF ou une IP whitelist, ajoutez l’IP du pentester avant le kick-off. Testez que ça fonctionne vous-même.

Staging ou production ?

La question revient à chaque mission.

Le staging est plus sûr. Le pentester peut tester de manière agressive (injections, fuzzing) sans risquer de corrompre des données client réelles. C’est ce qu’on recommande pour un premier pentest.

Mais votre staging doit refléter la production. Si le code a divergé depuis trois mois, les résultats du pentest ne valent rien. Un auditeur SOC 2 le notera aussi.

La production garantit que les résultats reflètent l’état réel. Mais il y a des risques : corruption de données, notifications envoyées aux vrais clients, alertes déclenchées dans votre monitoring.

Ce qu’on fait en pratique : staging avec un jeu de données réaliste pour la majorité des tests, puis un passage rapide en production en fin de mission pour confirmer les findings critiques sur le vrai environnement. On définit précisément ce qui est autorisé et ce qui ne l’est pas pendant le call de cadrage.

Prévenez vos équipes

Ne lancez pas un pentest sans prévenir :

Ops / SRE : ils vont voir du trafic anormal dans les logs. S’ils ne savent pas qu’un pentest est en cours, ils vont bloquer l’IP du pentester ou lancer une procédure d’incident pour rien.

Devs : pas de refactoring majeur de l’authentification ou du modèle de données pendant le test. Les hotfixes restent OK, prévenez juste le pentester. On recommande un channel Slack dédié entre votre équipe et le pentester pour signaler les changements.

Support client : si le pentest touche à la production, le support pourrait recevoir des tickets liés aux actions du pentester.

Comment ça se passe concrètement

Notre méthodologie suit 5 phases. Voilà ce que ça donne sur une mission type.

Phase 1 : cadrage. Un call de 30 minutes avec votre CTO ou lead dev. On définit le périmètre, les fonctionnalités critiques, les rôles utilisateur, les contraintes techniques. Vous recevez une proposition détaillée avec un prix fixe sous 24h.

Phase 2 : reconnaissance. On cartographie la surface d’attaque. Stack technique, endpoints, flux d’authentification, points d’entrée. Tout est documenté avant de lancer les tests.

Phase 3 : tests d’intrusion. C’est le coeur de la mission. On suit la méthodologie OWASP WSTG sur 8 vecteurs d’attaque :

• Injection (SQL, NoSQL, SSTI)
• Contrôles d’accès (IDOR, escalade de privilèges)
• Authentification et sessions
• Logique métier (race conditions, contournement de workflows)
• XSS, SSRF, configuration de sécurité, exposition de données sensibles

Chaque test est manuel. On n’exporte pas des résultats de Burp Scanner ou de Nessus. Si on trouve une faille CVSS 9.0+, on vous notifie immédiatement sans attendre le rapport.

Phase 4 : rapport. Un PDF structuré avec un résumé exécutif pour la direction et des findings techniques détaillés pour les devs. Chaque vulnérabilité est documentée avec sa preuve d’exploitation (requêtes HTTP, screenshots), son score CVSS 3.1, sa classification CWE et OWASP, et un correctif de code applicable. On mappe aussi chaque finding aux référentiels de conformité (SOC 2, ISO 27001, NIS2, DORA, PCI DSS) pour que votre auditeur puisse exploiter le rapport directement, sans traduction.

Phase 5 : restitution. On présente les résultats à votre équipe technique et à la direction. On priorise les corrections en fonction de l’impact business réel, pas juste du score CVSS. Un CVSS 6.5 qui expose les données de tous vos tenants est plus urgent qu’un CVSS 7.0 qui nécessite un scénario d’exploitation improbable.

Pour le format Pentest Rapide, on compresse les phases 1 à 4 en 48h ouvrées sur un périmètre cadré.

Lire le rapport sans le ranger dans un tiroir

Le rapport est livré. C’est maintenant que le vrai travail commence.

Chaque finding contient un score CVSS de 0 à 10. Les sévérités : Critical (9-10), High (7-8.9), Medium (4-6.9), Low (0.1-3.9). Mais le score seul ne suffit pas. Le contexte métier compte plus que le chiffre.

Votre pentester devrait vous aider à prioriser. Pendant la restitution, posez la question : “Si on ne peut en corriger que trois ce mois-ci, lesquels ?” La réponse est rarement les trois CVSS les plus élevés.

Pour la remédiation :

• Critical et High : correction sous 30 jours. Si c’est exploitable en production avec des données client en jeu, corrigez dans la semaine.
• Medium : planifiez dans vos prochains sprints, correction sous 60-90 jours.
• Low : intégrez dans le backlog, corrigez quand vous touchez au code concerné.

Si vous préparez un SOC 2, documentez chaque remédiation avec la date du finding et la date de correction. L’auditeur veut voir ce cycle.

Le retest, c’est la moitié de la valeur

Après correction, demandez un retest. Chez nous, le retest est inclus dans les 30 jours suivant la livraison du rapport.

Le retest vérifie que les corrections fonctionnent, qu’il n’y a pas de contournement possible, et que les fixes n’ont pas ouvert de nouvelles failles. Sans retest, vous avez un rapport qui documente vos failles mais aucune preuve qu’elles sont corrigées. C’est le rapport de retest que vos clients enterprise, vos investisseurs, et votre auditeur SOC 2 veulent voir.

Les erreurs qui coûtent cher

Périmètre trop ambitieux. “On veut tout tester” avec 5 jours de budget. Le pentester survole chaque fonctionnalité sans rien creuser. Mieux vaut un test approfondi sur vos 10 fonctionnalités critiques.

Confondre pentest et scan de vulnérabilités. Un scan automatisé (Nessus, Qualys, OWASP ZAP) trouve les vulnérabilités connues et les mauvaises configurations. Un pentest trouve les failles de logique métier, les IDOR entre tenants, les chaînes d’exploitation. Si votre prestataire vous livre un export de scanner avec des CVE et sans preuves d’exploitation, ce n’est pas un pentest.

Ne rien corriger et recommencer un an plus tard. On voit des équipes faire un pentest annuel, recevoir 15 findings, n’en corriger aucun, et repayer l’année suivante pour retrouver les mêmes 15 findings plus 10 nouveaux. Si vous n’avez pas les ressources pour tout corriger, réduisez le périmètre du prochain test et concentrez vos efforts.

Déployer un refactoring pendant le test. Un dev pousse une réécriture de l’auth le mercredi. Le pentester a passé lundi et mardi sur l’ancien système. Ses findings sont obsolètes. Communiquez.

Checklist

Avant le kick-off, vérifiez chaque point.

Périmètre

• Scope validé avec le prestataire : URLs, fonctionnalités, exclusions
• Type de test choisi (grey box dans 90% des cas)
• Environnement choisi (staging iso-production recommandé)

Accès

• Comptes de test créés pour chaque rôle
• Comptes sur des tenants différents pour l’isolation
• Accès au repo Git en lecture seule
• Documentation API partagée (Swagger, Postman)
• IP du pentester whitelistée et testée

Organisation

• Équipes prévenues (ops, dev, support)
• Channel de communication dédié
• Politique de déploiement communiquée
• Dates confirmées

Après

• Responsable de la remédiation identifié
• Retest planifié dans les 30 jours

---

Si vous préparez votre premier pentest, demandez un devis gratuit. On travaille exclusivement avec des éditeurs SaaS et on limite nos missions à 4 par mois. Réponse le jour même, rapport livré sous 48h ouvrées pour le Pentest Rapide, 5 à 10 jours pour un audit complet.