Exécutez des tests d’intrusion pilotés par IA sur vos applications web et obtenez un rapport prêt pour l’audit
Corgea AI Pentest exécute des tests d’intrusion autonomes sur vos applications web en fonctionnement. Là où le SAST raisonne sur le code source, un pentest attaque l’application déployée comme le ferait un adversaire : il énumère la surface d’attaque, enchaîne les faiblesses entre elles et prouve chaque résultat à l’aide d’un exploit fonctionnel.Chaque exécution produit des résultats assortis d’une preuve de concept reproductible et d’un rapport PDF partageable, que vous pouvez remettre à un client, à un auditeur ou à vos propres équipes d’ingénierie.
Le pentesting est en bêta et proposé en option. Si Pentests n’apparaît pas dans la barre latérale, contactez votre administrateur Corgea ou écrivez à sales@corgea.com.
Les agents cartographient la surface d’attaque de votre cible : endpoints, parcours d’authentification, paramètres et routes vers lesquelles aucun lien évident ne pointe.
2
Attaque
Des agents spécialisés travaillent la cible en parallèle, chacun sur son domaine. Plutôt que de rechercher des motifs connus, ils tentent une exploitation réelle et enchaînent les faiblesses d’un domaine à l’autre pour atteindre des impacts plus élevés.
3
Rapport
Chaque résultat confirmé est documenté avec une description, l’impact métier, la chaîne d’attaque, un script d’exploitation et des recommandations de remédiation, puis intégré à un rapport téléchargeable.
Toute exécution mobilise les agents suivants :
Agent
Domaines couverts
Authentication / Authorization
Gestion des sessions, frontières de privilèges, IDOR et BOLA, mauvaises configurations MFA, JWT, OAuth et OIDC
Business Logic
Contournement de workflow, manipulation des prix et des quantités, conditions de concurrence, détournement des parcours de compte, intégrité des transactions
Injection
Injection SQL et NoSQL, injection de commandes et de templates, XSS, SSRF, XXE, désérialisation, traversée de répertoires, mass assignment
Une exécution Deep ajoute un agent red team étendu, qui explore au-delà de ces domaines et construit des chaînes d’attaque en plusieurs étapes qui les traversent.
Corgea ne remonte que les résultats que ses agents ont pu valider sur l’application en fonctionnement. Un résultat présent dans le rapport a été reproduit, et pas seulement soupçonné.
N’exécutez de pentests que sur des applications que votre organisation possède ou qu’elle est explicitement autorisée à tester. Un pentest envoie du trafic d’attaque réel et peut créer, modifier ou supprimer des données. Ciblez un environnement de préproduction ou un environnement de test dédié, sauf si vous avez accepté le risque de tester la production.
L’URL de votre cible doit être joignable publiquement en http ou https. Corgea refuse les cibles qui :
Utilisent un schéma autre que http ou https
Intègrent des identifiants directement dans l’URL, par exemple https://user:pass@example.com
Pointent vers localhost, une plage réseau privée ou une adresse de métadonnées cloud
Si votre application n’est pas joignable depuis Internet, exposez une instance de test ou contactez-nous pour envisager d’autres options.
Une cible est une configuration réutilisable : où attaquer, quels identifiants utiliser et quelles instructions permanentes appliquer. Chaque exécution s’appuie sur une cible : vous la configurez une fois, puis vous relancez un test à chaque mise en production.
L’en-tête indique le quota de pentest qu’il vous reste pour chaque mode de scan. L’onglet Pentest runs répertorie toutes les exécutions, cibles confondues, que vous pouvez rechercher et filtrer par statut.
Sélectionnez Pentests dans la barre latérale, puis cliquez sur New target.
2
Nommer la cible et choisir un mode de scan
Saisissez un nom reconnaissable, l’URL racine de l’application et un mode par défaut : Balanced ou Deep. Vous pouvez modifier le mode pour chaque exécution.
3
Choisir comment les agents se connectent
Choisissez des tests anonymes ou authentifiés. Pour les tests authentifiés, sélectionnez le mot de passe seul, une application d’authentification (TOTP) ou des codes de connexion par e-mail si votre déploiement le permet.
Si l’application demande un second facteur, choisissez une application d’authentification (TOTP) ou des codes de connexion par e-mail. Les codes par e-mail n’apparaissent que lorsqu’une boîte aux lettres de pentest partagée est configurée pour le déploiement.
4
Configurer les utilisateurs de test
Ajoutez un nom d’utilisateur ou une adresse e-mail et un mot de passe pour chaque compte. Plusieurs comptes permettent de tester les accès entre utilisateurs. Pour TOTP, saisissez l’URI TOTP du compte ou sélectionnez une image QR ; l’image est lue dans votre navigateur et n’est pas envoyée au serveur.
5
Ajouter d’autres identifiants et des instructions
Utilisez Other credentials pour les clés d’API, les en-têtes requis ou les identifiants de locataire. Utilisez Additional instructions pour les règles d’engagement, les exclusions de périmètre ou les endpoints prioritaires, puis cliquez sur Create target.
Les identifiants sont chiffrés au repos et ne sont déchiffrés que pendant une exécution contre cette cible.
Lorsque cette option est disponible, Corgea fournit une adresse e-mail pour chaque utilisateur de test. Saisissez un libellé de rôle court composé de lettres minuscules, de chiffres et de traits d’union, puis cliquez sur Provision. Invitez cette adresse dans votre application, utilisez Check for mail pour ouvrir l’invitation et terminer l’inscription, puis saisissez le mot de passe si votre application en a défini un et cliquez sur Save user. Répétez ces étapes pour chaque utilisateur.
L’enregistrement d’un utilisateur ferme sa boîte de réception de configuration. Les agents peuvent lire les codes de connexion pendant une exécution ; utilisez Reopen setup pour accéder à nouveau à la boîte lors de la configuration. Les codes par e-mail nécessitent une boîte aux lettres de pentest configurée et ne sont pas disponibles sur les déploiements qui en sont dépourvus.
Ouvrez le menu d’actions d’une cible pour lancer une exécution, la modifier ou l’archiver.Les modifications ne s’appliquent qu’aux exécutions futures. Chaque exécution fige la configuration de la cible au moment de son lancement : les exécutions passées et leurs résultats reflètent donc toujours le paramétrage qui les a produits. Changer une URL ou renouveler des identifiants ne réécrit jamais ce qu’une exécution antérieure a signalé.Choisissez Edit target pour rouvrir l’assistant de configuration. Pour supprimer les comptes enregistrés et effectuer des tests anonymes, choisissez No, test it anonymously à l’étape de connexion.L’archivage retire une cible de la liste tout en laissant consultables l’ensemble de ses exécutions passées.
Dans le menu d’actions d’une cible, choisissez Start new run.
Balanced
Deep
Une évaluation plus rapide, qui couvre l’authentification et l’autorisation, la logique métier et les injections. À privilégier pour des tests de routine à intervalles réguliers.
Une évaluation plus poussée, qui ajoute un agent red team pour une exploration étendue et l’enchaînement d’attaques en plusieurs étapes. À réserver aux veilles de release, aux audits ou aux revues de sécurité menées par vos clients.
Instruction override remplace les instructions permanentes de la cible, pour cette seule exécution. Laissez le champ vide pour conserver celles déjà définies sur la cible. C’est pratique lorsque vous voulez concentrer une exécution sur une fonctionnalité tout juste livrée, sans restreindre durablement le périmètre de la cible.Les exécutions Balanced et Deep consomment des quotas distincts. Le menu déroulant du mode de scan indique combien il vous en reste de chaque type, et un mode dont le quota est épuisé ne peut pas être sélectionné. Pour augmenter votre quota, écrivez à sales@corgea.com.
Une exécution dure quelques heures, selon le mode de scan et la taille de l’application. Inutile de garder la page ouverte : les résultats sont enregistrés au fur et à mesure de leur confirmation, et les administrateurs peuvent recevoir un e-mail à la fin de l’exécution.Pendant une exécution, la page se met à jour d’elle-même. Les résultats apparaissent à mesure que les agents les valident : vous pouvez donc commencer à trier les problèmes critiques avant la fin de l’exécution.Cliquez sur Logs pour observer les agents à l’œuvre.
L’arborescence indique chaque agent, ce sur quoi il travaille et le nombre de résultats qu’il a confirmés. Sélectionner un agent affiche sa tâche en cours et sa dernière activité. Les agents créent des agents enfants au fil de l’eau : lorsque l’un d’eux tombe sur une piste intéressante, il en délègue l’approfondissement plutôt que d’abandonner son propre axe d’attaque.
À la fin d’une exécution, la page de l’exécution récapitule ce qui a été découvert.
Les cartes affichées en haut de page répartissent les résultats par catégorie, en fonction du CWE. Cliquez sur l’une d’elles pour filtrer la liste située en dessous.
All findings — tout ce que l’exécution a confirmé, avec le décompte par sévérité
Auth & AuthZ — contrôles d’accès défaillants, problèmes d’authentification et de gestion de session
Business Logic — problèmes de workflow et d’intégrité des transactions
Injection — injections, traversées de chemin et problèmes liés aux entrées non fiables
Validated SAST — bientôt disponible ; recoupera les résultats SAST confirmés avec leur exploitabilité réelle à l’exécution
Les résultats dont le CWE ne correspond à aucune de ces catégories restent visibles dans All findings.
La barre d’outils située au-dessus de la liste des résultats vous propose :
Des pastilles de statut — Open, Fixed, Closed et False Positive, chacune avec un compteur en temps réel. More ajoute Accepted Risk, Duplicate et tous les statuts.
Une recherche — porte sur le titre, le CWE et l’endpoint
Un filtre de sévérité — Critical, High, Medium, Low ou Info
Un sélecteur CWE / Endpoint — regroupe les résultats par type de faiblesse ou par endpoint concerné
Le regroupement par CWE répond à la question « quelles classes de bugs cette application présente-t-elle ? ». Le regroupement par endpoint répond à « quelle partie de l’application est la plus fragile ? », une vue généralement plus utile au moment de répartir le travail de remédiation.
La description, l’impact métier, les rôles et utilisateurs concernés, ainsi que l’analyse technique de la cause racine. Le panneau latéral reprend l’identifiant CWE, la sévérité, le score CVSS, la cible, l’endpoint et le nombre de fois où le résultat a été redétecté au fil des exécutions.
La séquence exacte suivie par l’agent, sous forme d’étapes numérotées. Chaque étape précise la requête envoyée et la réponse de l’application, pour qu’un ingénieur puisse refaire le parcours sans rien deviner.
Un script exécutable qui reproduit le résultat. Lancez-le sur votre cible pour confirmer le problème par vous-même, puis de nouveau après correction pour vérifier que le correctif tient.
Les scripts d’exploitation mènent de véritables attaques. Ne les exécutez que sur des systèmes que vous êtes autorisé à tester, et attendez-vous à ce qu’ils créent ou modifient des données.
Une chronologie du résultat couvrant toutes les exécutions : première détection, redétections, ainsi que chaque changement de statut et chaque commentaire, avec leur auteur.Corgea reconnaît un même problème sous-jacent d’une exécution à l’autre. Si un résultat réapparaît lors d’un pentest ultérieur, il est rattaché au résultat d’origine plutôt qu’enregistré comme nouveau : l’historique raconte ainsi une seule et même histoire.
Utilisez Current Status sur un résultat pour consigner une décision. Les valeurs possibles sont :
Status
Signification
Open
Non résolu, en attente de traitement
Fixed
Vous estimez le problème résolu — confirmez-le par une exécution de revalidation
Accepted Risk
Reconnu et accepté, éventuellement avec une date d’expiration
False Positive
Ce n’est pas un vrai problème
Duplicate
Déjà suivi par un autre résultat
Un changement de statut s’applique à toutes les détections d’un même problème : trier une fois met donc à jour tout l’historique, et pas seulement la ligne que vous avez ouverte. Vous pouvez aussi ajouter des commentaires pour documenter le contexte à l’intention de vos collègues.
Closed figure parmi les statuts mais ne peut pas être appliqué manuellement. Corgea le positionne automatiquement lorsqu’une exécution de revalidation ne parvient plus à reproduire un résultat.
Une fois l’exécution terminée, Export report propose deux PDF.
Technical report
L’évaluation complète, avec l’analyse technique, la preuve de concept, le code d’exploitation et les recommandations de remédiation pour chaque résultat. Destiné à vos équipes d’ingénierie.
Executive report
La même évaluation et les mêmes résultats, sans l’analyse technique approfondie, la preuve de concept ni le détail de la remédiation. Destiné aux clients, aux auditeurs et à la direction.
Les deux rapports contiennent :
Une clause de confidentialité et un sommaire
Une synthèse pour la direction et un tableau de bord des résultats
Le périmètre et la méthodologie, avec les agents mobilisés et la couverture de chacun, ainsi qu’une mention explicite de ce qui est hors périmètre
Les définitions des niveaux de sévérité et l’action recommandée pour chacun
Un tableau récapitulatif de tous les résultats
Le détail des résultats, regroupés par sévérité
Les rapports peuvent servir de preuve de test d’intrusion dans le cadre d’audits SOC 2 et ISO 27001, et sont conçus pour être transmis tels quels à vos clients et à vos auditeurs. Le fait qu’un rapport réponde à une exigence précise dépend du périmètre de votre audit, des mesures que vous avez retenues et de votre auditeur.
Une fois vos correctifs livrés, retestez-les sans consommer un pentest complet sur toute l’application. Sur une exécution terminée, ouvrez le menu New run et choisissez Revalidate Findings.Une exécution de revalidation ne reteste que les résultats de l’exécution d’origine et signale :
Still open — les résultats qu’elle a de nouveau reproduits
Closed by this run — les résultats qu’elle n’a plus réussi à reproduire, automatiquement passés au statut Closed
1
Corriger les résultats
Déroulez les étapes de remédiation en marquant les résultats Fixed au fur et à mesure.
2
Revalider
Depuis l’exécution terminée, choisissez New run, puis Revalidate Findings.
3
Confirmer
Les résultats qui ne sont plus reproductibles passent au statut Closed. Ceux qui le sont encore restent ouverts, accompagnés de nouvelles preuves.
La revalidation nécessite une exécution terminée comportant au moins un résultat Open ou Fixed. Une exécution de revalidation ne peut pas être revalidée à son tour : relancez plutôt une revalidation depuis l’exécution d’origine.
La revalidation est le moyen le plus rapide de prouver une remédiation à un auditeur ou à un client : elle montre que le test qui avait détecté le problème ne parvient plus à le reproduire.
Les company admins peuvent recevoir un e-mail AI Pentest Completed à la fin d’une exécution, indiquant la cible, le mode de scan, le nombre total de résultats et leur répartition par sévérité. Il s’agit d’une préférence e-mail individuelle : un administrateur qui préfère ne pas le recevoir peut le désactiver sans conséquence pour les autres.Corgea déclenche également un webhook à la fin de l’exécution, que vous pouvez utiliser pour publier les résultats dans Slack, ouvrir des tickets ou conditionner un pipeline de release. Consultez Webhooks pour la configuration et le détail des payloads.Les exécutions de revalidation n’envoient pas de notification de fin.
Quelques heures, selon le mode de scan ainsi que la taille et la complexité de votre application. Les exécutions Deep sont plus longues que les Balanced. Vous n’avez pas besoin de surveiller l’exécution : les résultats sont enregistrés dès leur confirmation, et les administrateurs peuvent être prévenus par e-mail à la fin.
Puis-je tester une application protégée par authentification ?
Oui. Dans l’assistant de configuration de la cible, choisissez les tests authentifiés et ajoutez un ou plusieurs comptes de test. Vous pouvez utiliser un mot de passe, une application d’authentification (TOTP) ou des codes reçus par e-mail lorsque cette option est disponible. Les exécutions incluent aussi des tests non authentifiés : vous obtenez donc à la fois le point de vue de l’attaquant externe et celui de l’utilisateur connecté.
Un pentest risque-t-il d’endommager mon application ou ses données ?
Les agents mènent de véritables attaques, susceptibles de créer, modifier ou supprimer des données. Les tests de déni de service et de montée en charge volumétrique sont explicitement hors périmètre, mais mieux vaut tout de même privilégier un environnement de préproduction ou de test dédié pour les exécutions de routine.
Pourquoi l’URL de ma cible a-t-elle été refusée ?
Les cibles doivent utiliser http ou https, ne pas intégrer d’identifiants dans l’URL et ne pas pointer vers localhost, une plage réseau privée ou une adresse de métadonnées cloud. Exposez plutôt une instance de test joignable.
Pourquoi un mode de scan apparaît-il grisé ?
Son quota est épuisé. Balanced et Deep sont comptabilisés séparément, et les soldes restants s’affichent dans l’en-tête de la page ainsi que dans le menu déroulant du mode de scan. Écrivez à sales@corgea.com pour l’augmenter.
Mon exécution a échoué. Que faire ?
Le statut de l’exécution en indique la raison. Les causes les plus fréquentes sont une cible devenue injoignable en cours de route et des identifiants qui ont cessé de fonctionner. Vérifiez que la cible est bien accessible et que les identifiants sont à jour, puis lancez une nouvelle exécution.
L’exécution s’est terminée sans aucun résultat. Est-ce un problème ?
Pas nécessairement. Cela signifie que les agents n’ont validé aucun problème exploitable dans le périmètre. Si vous attendiez des résultats, vérifiez que les identifiants sont corrects afin que les zones authentifiées aient bien été atteintes, et envisagez une exécution Deep pour élargir la couverture.
En quoi est-ce différent du SAST ?
Le SAST raisonne sur le code source et détecte les problèmes avant le déploiement. Un pentest attaque l’application en fonctionnement et démontre ce qui est réellement exploitable dans votre configuration déployée. Les deux approches détectent des choses différentes, et leurs résultats sont suivis séparément dans Corgea.