Pentesting

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.

​

Fonctionnement d’un pentest

Chaque exécution suit les trois mêmes étapes. Toute exécution mobilise les agents suivants : 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.

​

Avant de commencer

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.

​

Cibles

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.

​

Créer une cible

​

Modifier et archiver

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é. Lorsque vous modifiez une cible, laisser le champ Credentials vide conserve les identifiants enregistrés. Pour les supprimer complètement, sélectionnez Clear stored credentials. L’archivage retire une cible de la liste tout en laissant consultables l’ensemble de ses exécutions passées.

​

Lancer une exécution

Dans le menu d’actions d’une cible, choisissez Start new run. 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.

​

Suivre une exécution

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.

​

Examiner les résultats

À 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.

​

Filtrer et regrouper

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.

​

Détail d’un résultat

Ouvrez n’importe quel résultat pour consulter l’analyse complète, répartie sur cinq onglets.

​

Détails du résultat

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.

​

Chaîne d’attaque

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.

​

Script d’exploitation

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.

​

Remédiation

Des étapes de remédiation concrètes pour ce résultat précis, accompagnées de références aux normes et bonnes pratiques applicables.

​

Historique

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.

​

Trier les résultats

Utilisez Current Status sur un résultat pour consigner une décision. Les valeurs possibles sont : 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.

​

Exporter un rapport

Une fois l’exécution terminée, Export report propose deux PDF. 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.

​

Revalider après correction

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

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.

​

Notifications

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.

​

Questions fréquentes

​

Ressources associées