Les tests d'intrusion aujourd'hui : ce qu'ils couvrent vraiment, ce qu'ils ratent, ce qu'il faut répéter

Une entreprise sur trois ayant reçu un rapport de pentest sans finding critique subit un incident dans les douze mois suivants. Le problème vient rarement du prestataire. Il vient de la définition du périmètre.

Ce que couvre réellement un pentest standard

Lorsqu'un client commande un test d'intrusion, il reçoit en général l'une des trois variantes classiques :

Black box : le testeur n'a ni identifiants ni documentation. Il simule un attaquant externe sans information préalable.
Grey box : identifiants limités, architecture partiellement partagée. C'est le scénario le plus courant pour les tests d'applications web B2B.
White box : accès complet au code source, à la documentation et aux identifiants de test. Le plus coûteux, le plus approfondi.

Un test grey box sur une application web couvre typiquement : l'OWASP Top 10, l'authentification et la gestion des sessions, l'autorisation verticale et horizontale, les injections (SQL, NoSQL, commande), l'exposition de données sensibles dans les API REST, les erreurs de configuration des headers HTTP.

C'est déjà substantiel. Mais regardons maintenant ce qui n'entre presque jamais dans le périmètre.

Les lacunes structurelles qu'aucun pentest annuel ne résout

1. La surface d'attaque évolue en permanence

Une application SaaS B2B typique livre du code toutes les une à deux semaines. Un pentest réalisé en janvier photographie l'état de janvier. En mars, trois nouveaux endpoints ont été ajoutés, une intégration avec un prestataire de paiement tiers est en production, et une fonctionnalité d'export CSV est disponible. Aucun de ces éléments n'a été testé.

La réponse n'est pas de réaliser douze pentests par an — ce n'est pas viable économiquement. La réponse est de combiner le pentest périodique avec un programme de DAST continu (Dynamic Application Security Testing) à chaque déploiement, intégré dans la pipeline CI/CD.

Exemple pratique avec OWASP ZAP dans GitHub Actions :

- name: DAST scan
  uses: zaproxy/action-full-scan@v0.10.0
  with:
    target: 'https://staging.example.com'
    rules_file_name: '.zap/rules.tsv'
    cmd_options: '-a'

Cela ne remplace pas le pentest manuel, mais garantit que les nouveaux endpoints sont au moins parcourus par des scanners automatiques avant d'arriver en production.

2. La couche infrastructure cloud est souvent hors périmètre

La plupart des pentests applicatifs ne touchent pas l'infrastructure cloud sous-jacente. Politiques IAM sur AWS, buckets S3 publics par erreur, security groups trop permissifs, secrets dans les logs CloudWatch : ce sont des surfaces d'attaque réelles, mais elles sont exclues parce que « c'est un test applicatif ».

Couvrir cette couche requiert des outils dédiés : Prowler pour AWS, ScoutSuite pour le multi-cloud, ou une solution CSPM comme AWS Security Hub pour des findings continus.

Audit rapide avec Prowler :

prowler aws --services s3 iam cloudtrail \
  --output-formats json-asff \
  --output-directory ./prowler-reports

Une heure d'exécution sur un compte AWS moyen fait remonter des dizaines de findings qu'aucun pentest applicatif n'aurait détectés.

3. Le facteur humain n'est pas testable dans un pentest standard

Les campagnes de phishing, le social engineering, le vishing : ces vecteurs sont généralement contractualisés séparément (red team engagement) ou exclus pour des raisons organisationnelles. Pourtant, 74 % des violations — selon le Verizon DBIR 2023 — impliquent l'élément humain.

Si votre budget ne permet pas un red team complet, envisagez au moins une campagne de phishing simulé trimestrielle avec des outils comme GoPhish (open source) ou des services managés. Les données obtenues — taux de clic, taux de soumission d'identifiants — sont des métriques opérationnelles concrètes, pas des opinions.

4. Les dépendances tierces ne sont pas testées

Votre code peut être propre. Mais si vous utilisez vingt packages npm, trois SDK de prestataires externes et un widget de chat en iframe, la surface réelle est bien plus grande que ce que le pentest a couvert.

L'analyse des dépendances est un processus distinct : SCA (Software Composition Analysis) avec des outils comme Snyk, Dependabot, ou OWASP Dependency-Check dans la pipeline.

Ce qu'il faut répéter et à quelle cadence

Il n'existe pas de cadence universelle, mais il existe un cadre raisonnable :

| Activité | Cadence conseillée | Déclencheurs supplémentaires | |---|---|---| | Pentest manuel (grey/white box) | Annuel | Sortie de fonctionnalité majeure, changement architectural significatif | | DAST automatique | Chaque déploiement (staging) | — | | CSPM scan (posture cloud) | Hebdomadaire / continu | Chaque modification IaC | | SCA (dépendances) | Chaque build | — | | Phishing simulé | Trimestriel | Post-incident, changement d'équipe significatif | | Revue manuelle IAM/secrets | Semestrielle | Départ d'un développeur senior |

Le pentest annuel reste fondamental parce que l'intelligence humaine détecte des vulnérabilités logiques qu'aucun scanner ne trouvera jamais. Mais c'est un point d'ancrage, pas une couverture complète.

Le rapport n'est pas une fin : c'est un début

Une erreur récurrente : recevoir le rapport, corriger les findings critiques et élevés, fermer le ticket. Les findings moyens et bas restent ouverts pendant des mois.

La priorisation correcte ne repose pas uniquement sur le score CVSS. Elle repose sur le contexte métier : un finding CVSS 5.5 sur un endpoint qui gère des données de paiement est plus urgent qu'un CVSS 7.0 sur une page de documentation publique.

Intégrer les findings du pentest dans un système de suivi (Jira, Linear, peu importe) avec des SLA définis par catégorie est le minimum pour transformer un document en processus.

Points opérationnels à retenir

Définissez le périmètre du prochain pentest en incluant explicitement l'infrastructure cloud, les API internes et les intégrations tierces — pas seulement l'application web principale.
Ajoutez du DAST automatique dans votre CI/CD pour couvrir l'intervalle entre deux pentests.
Utilisez un CSPM pour la couche cloud : elle est presque toujours hors périmètre dans les pentests standard.
Suivez les findings comme des tâches avec SLA, pas comme des PDF à archiver.
Planifiez la répétition du pentest à chaque changement architectural significatif, pas uniquement selon un calendrier fixe.

La sécurité est un processus continu avec des points de contrôle périodiques, pas un audit annuel avec une signature finale.

---

Evviva Group accompagne partenaires et intégrateurs dans la structuration de programmes de tests de sécurité continus. Si vous repensez votre approche du pentest, nous pouvons en discuter ensemble.