Pentesting Priorisé par 95% des Entreprises, Mais 32% Testées
Origines et historique
J'ai passé trop de temps à gérer des tests d'intrusion faciles à oublier pendant que les équipes se concentraient sur des sujets plus « glamour ». Autrefois, un pentest restait souvent un rendez-vous ponctuel, programmé juste avant une mise en production. Aujourd'hui ce modèle montre ses limites face au cloud, aux microservices et aux APIs : l'inventaire s'éparpille, les actifs deviennent éphémères et les périmètres de test ne suivent pas. Selon des enquêtes récentes, 95% des entreprises déclarent prioriser le pentesting, mais à peine 32% de leurs surfaces d'attaque seraient réellement couvertes¹.
Plusieurs facteurs expliquent cet écart.
- L'inventaire se complexifie : instances éphémères, fonctions serverless, IoT, comptes cloud multiples et endpoints dynamiques créent une surface mouvante difficile à maintenir.
- Les périmètres de test sont souvent trop étroits : environnements de staging, APIs internes et artefacts cloud sont fréquemment exclus des scans par souci de temps ou de coût.
- Le budget et la cadence sont mal adaptés : beaucoup d'entreprises privilégient des audits uniques plutôt que des cycles réguliers et intégrés.
Des approches alternatives apparaissent : plateformes crowdsourcées, programmes de bug bounty et pentesting continu, mais leur adoption dépend fortement de la maturité sécurité et de l'inventaire de chaque organisation²³.
Fonctionnement technique
Types de pentest et méthodologies
On peut résumer les approches classiques en trois catégories, chacune utile selon l'objectif.
- Black-box : le testeur part sans informations internes. Ce mode simule une attaque externe réaliste mais peut être long pour trouver une voie d'accès.
- Grey-box : informations partielles fournies (comptes de test, schémas API). Bon compromis entre efficacité et réalisme, souvent privilégié pour les tests intégrés dans des pipelines.
- White-box : accès complet (code source, architecture, logs). Idéal pour trouver des enchaînements complexes et des problèmes logiques profonds.
Le choix se fait en fonction du risque métier, des coûts et de la criticité des actifs.
Technique et outils appropriés
- Reconnaissance et inventory
- Outils : amass, subfinder, Shodan, et les APIs cloud pour lister buckets, instances et fonctions.
- Construisez une cartographie automatique de votre surface d'attaque. Parfois il faut écrire des scripts pour corréler noms de domaines, comptes cloud et endpoints d'API. Exemple de commande basique pour la découverte de sous-domaines :
``bash ./subfinder -d yourdomain.com -o subdomains.txt `
Analyse automatiséeOutils : Nessus, OpenVAS, Qualys pour la découverte; SonarQube pour le SAST; OWASP ZAP pour le DAST.Les scanners servent à identifier rapidement des vulnérabilités connues, mais ils produisent des faux positifs et ratent les enchaînements logiques.Exploitation manuelleTechniques : SQLi, SSRF, CSRF, contournements d'authorisation, business logic abuse. L'objectif est de valider l'impact réel et de reproduire des chaînes d'attaque.Exécution simple pour tester un endpoint :
`bash curl -X POST -d 'user_id=1' https://yourapi.com/resource?id=2 ``
- Post-exploitation et pivoting
- Illustrer le chemin d'attaque jusqu'à des assets critiques. Sur Windows, des outils comme Mimikatz restent utiles pour démontrer des escalades de privilèges; sur Linux, l'enchaînement de comptes et de clefs privées peut permettre des pivots.
- Des outils et scripts pour établir des tunnels ou pivoter sur des sous-réseaux sont souvent nécessaires pour montrer la portée réelle d'une intrusion.
- Reporting et remédiation
- Priorisez les découvertes en combinant CVSS et criticité business. Un 9.8 CVSS sur un composant peu exposé peut être moins urgent qu'une faille 6.x dans un endpoint d'API public essentiel.
- Intégrez des tickets de remédiation, des vérifications post-correctif et une attestation de correction.
Mesurer la couverture
Une mesure simple aide à objectiver le progrès :
Couverture (%) = (actifs testés / actifs pertinents) x 100
Le chiffre de 32% reflète souvent un inventaire incomplet ou mal maintenu¹. Pour s'améliorer, automatisez la discovery via les APIs cloud et l'analyse des manifests d'infrastructure (Terraform, CloudFormation). N'oubliez pas d'inclure les environnements non productifs : ils servent souvent de point d'entrée pour une attaque vers la production.
Complétez la métrique de couverture par des indicateurs de criticité : nombre d'attack paths identifiés, temps moyen de correction, et pourcentage d'actifs exposés publiquement.
Intégration CI/CD et tests automatisés
Idée de pipeline pragmatique :
- Pré-commit : scans SAST et SCA rapides pour filtrer vulnérabilités triviales.
- Build stage : exécuter des DAST sur environnements éphémères déployés par Terraform ou CloudFormation.
- Pré-production : pentest grey-box planifié pour vérifier la logique applicative et les enchaînements.
- Production : monitoring, détection d'anomalies et programmes continus comme bug bounty ou pentest permanent.
La principale erreur est d'exécuter ces étapes sur des environnements qui ne reproduisent pas fidèlement la production. Répliquer les configurations, secrets et policies IAM est coûteux, mais indispensable.
Études de cas
1) Couverture insuffisante d'actifs cloud et fuite de données
Dans une grande entreprise SaaS ayant migré vers AWS, la portée du pentest excluait les buckets S3 et plusieurs APIs internes. Des buckets non chiffrés et mal configurés ont fini par exposer des données clients. Le constat : inventaire IAM incomplet, absence de tests sur les policies de stockage et endpoints internes ignorés. La solution a été d'automatiser l'inventaire cloud, d'ajouter des audits périodiques sur les policies IAM et d'inclure les storage dans le périmètre des tests.
2) Contournement d'authentification via logique métier
Sur une plateforme e-commerce, une API mobile hors périmètre a permis de contourner l'authorization côté serveur, menant à des commandes frauduleuses et une compromission massive de comptes. Correctifs appliqués : renforcement des contrôles côté serveur, tests grey-box réguliers sur toutes les APIs et automatisation des audits d'API dans le pipeline.
3) Programme de pentest continu et amélioration des métriques
Une société a adopté un modèle de pentest continu et observé en un an une baisse de 45% du MTTR et une augmentation de la couverture des actifs critiques de 35% à 78%². Les facteurs décisifs ont été un inventaire dynamique, une priorisation fondée sur la criticité business et un processus de remédiation avec validation post-correctif.
Perspectives
Les deux prochaines années devraient voir une montée en puissance des tests continus, surtout lorsqu'ils sont intégrés dès la phase de développement. L'IA peut accélérer la discovery et la corrélation d'indicateurs, mais elle doit être supervisée pour limiter les faux positifs et éviter des actions automatisées dangereuses.
Les contrôles de la supply chain logicielle vont devenir obligatoires. Le cas de Log4Shell (CVE-2021-44228) rappelle combien un composant négligé peut impacter massivement une infrastructure⁴. Automatiser la vérification des dépendances open source et cartographier la provenance des artefacts sont des priorités.
Côté règlementaire et assurantiel, les assureurs exigent désormais des preuves de stratégie de tests continues; une couverture de 32% expose à des conséquences financières et contractuelles. Pour corriger le tir, ciblez trois chantiers : automatisation de l'inventaire, inclusion explicite des APIs et environnements intermédiaires, et scénarios de test orientés métier.
En combinant automatisation et expertise humaine, vous réduirez l'écart entre intention et couverture et rendrez vos pentests réellement utiles.
