Comment fonctionne un test d'intrusion piloté par l'IA (et ce qu'il ne peut toujours pas faire)

Comment ça fonctionne#

BreachVex repose sur un moteur d'attaque multi-étapes s'exécutant dans un conteneur isolé, neuf et à usage unique, doté de véritables outils offensifs standard de l'industrie. Chaque analyse suit une séquence fixe d'étapes, chacune responsable d'une phase distincte de la mission :

1. Reconnaissance passive — Enregistrements DNS, journaux de transparence des certificats, données d'exposition publique.
2. Sondage — Empreinte HTTP, détection de la pile technologique, identification du mécanisme d'authentification (formulaire, JWT, OAuth2, clé API).
3. Cartographie — Découverte des points d'entrée via l'analyse des bundles JavaScript, le crawl Katana, l'énumération de chemins Gobuster, et l'extraction des routes SPA.
4. Reconnaissance active — Cartographie approfondie de la surface d'attaque incluant la découverte de paramètres (Arjun), l'énumération de sous-domaines, et la détection des redirections ouvertes.
5. Planification des attaques — L'étape de planification sélectionne les classes de vulnérabilités à tester en fonction de la pile découverte. Une route API Next.js est testée différemment d'un monolithe Laravel.
6. Exécution des squads — Neuf squads d'agents spécialisés s'exécutent, chacune couvrant une catégorie de vulnérabilités : XSS, injection SQL, SSRF, XXE, authentification et sessions, logique métier, sécurité des API, mauvaises configurations et attaques avancées.
7. Moteur de preuve — Les résultats ne sont promus dans le rapport que si le moteur de preuve peut vérifier l'exploitation. Pour le XSS, cela signifie l'exécution du payload dans un vrai navigateur Playwright. Pour l'IDOR, cela implique la confirmation d'un accès inter-comptes avec une comparaison de réponses.
8. Rapport — Les sorties PDF, JSON et SARIF 2.1.0 sont générées avec les étapes de reproduction complètes.

Le pipeline complet se termine généralement en 40 à 60 minutes selon la complexité de la cible et le nombre de points d'entrée découverts.

Ce que ça couvre#

BreachVex teste plus de 120 classes de vulnérabilités dans les catégories suivantes :

• Injection : SQL, NoSQL, commandes systèmes, LDAP, SSTI, XPath
• XSS : Réfléchi, stocké, basé sur le DOM, XSS aveugle avec rappel hors bande
• Contrôle d'accès défaillant : IDOR, BOLA, élévation de privilèges horizontale et verticale, manipulation de JWT
• Authentification et sessions : Identifiants faibles, fixation de session, détournement de session, confusion d'algorithme JWT, énumération de comptes
• SSRF : Accès aux endpoints de métadonnées cloud (AWS IMDSv1/v2, GCP, Azure), sondage de services internes, confirmation hors bande via rappel DNS
• Sécurité des API : OWASP API Top 10, introspection et batching GraphQL, assignation de masse, contournement des limites de débit
• Mauvaises configurations : Points d'entrée de débogage exposés, identifiants par défaut, messages d'erreur verbeux, références S3 ouvertes dans le code source, lacunes dans les en-têtes de sécurité
• Logique métier : Contournement de flux applicatifs, manipulation des prix, cumul de remises, dépassement des limites d'utilisation

Limitations#

Cette section est importante. Un outil de test d'intrusion par IA est un outil dont le périmètre est défini, et surestimer ce périmètre ne rend service à personne.

Ce que BreachVex ne fait pas :

• Ingénierie sociale — Le phishing, le vishing, le pretexting et les attaques exploitant le facteur humain nécessitent un jugement et une interaction humaine. Cela n'est pas automatisable de façon significative.
• Sécurité physique — Le clonage de badges, l'intrusion physique, les attaques matérielles et la compromission de la chaîne d'approvisionnement requièrent une présence sur place.
• Revue de code source — BreachVex opère en boîte noire. Il n'a pas accès à votre code source et ne peut pas effectuer d'analyse statique (SAST) ni de revue de sécurité au niveau du code.
• Recherche de zero-day — BreachVex exploite des classes de vulnérabilités connues à l'aide de techniques éprouvées. Il ne découvre pas de vulnérabilités inédites dans des logiciels tiers ou des systèmes d'exploitation.
• Tests d'intrusion sur le réseau interne — Le pipeline s'exécute depuis un point d'observation externe. Tester la segmentation réseau interne, Active Directory ou l'infrastructure sur site nécessite des outils et un accès réseau différents.
• Analyse d'écarts de conformité — BreachVex produit des résultats de sécurité, pas des cartographies de conformité. Il ne génère pas de rapports de préparation SOC 2, d'analyses d'écarts ISO 27001, ni d'évaluations de conformité PCI-DSS.

Quand l'utiliser versus un pentest traditionnel#

Le bon outil dépend de votre situation :

Utilisez BreachVex lorsque :

• Vous souhaitez une couverture continue à chaque déploiement, et non une mission ponctuelle
• Vous avez besoin de résultats rapides pour une nouvelle fonctionnalité, intégration ou surface d'API
• Vous souhaitez valider que les résultats d'un pentest manuel ont bien été corrigés
• Votre budget ne permet pas des missions manuelles trimestrielles
• Vous souhaitez une sortie lisible par les machines (SARIF) qui s'intègre à votre pipeline CI/CD

Utilisez un pentest humain traditionnel lorsque :

• Les référentiels de conformité l'exigent explicitement (PCI-DSS 11.4, SOC 2 Type II)
• Votre modèle de menace inclut l'ingénierie sociale ou les vecteurs de menace interne
• Vous avez besoin d'une revue de code source dans le cadre de la mission
• Votre application implique une logique métier complexe nécessitant un raisonnement humain soutenu pour la modéliser
• Vous testez une infrastructure interne, des périmètres VPN ou des systèmes sur site

Les programmes de sécurité les plus efficaces utilisent les deux. La couverture continue automatisée détecte les régressions et maintient un niveau de référence. Les pentests humains approfondissent certaines surfaces spécifiques — généralement une à deux fois par an — tandis que l'outil automatisé assure la couverture entre ces missions.