Comprendre le pentest
De l’image Docker au rapport : qui prépare les outils, qui décide et où restent vos données.
Le pentest est une recherche de faiblesses sur une application que vous autorisez à tester. Votre IA propose les contrôles ; des outils locaux les exécutent dans les limites approuvées. Vous obtenez un rapport avec les observations, les constats vérifiés et les limites du test.
Les schémas expliquent le parcours local expérimental. Ils ne prouvent pas sa compatibilité avec chaque outil d’IA : les confirmations humaines et les missions séparées doivent être vérifiées dans votre environnement. L’exécution sur une cible distante reste indisponible.
1. Que contient l’image Docker ?
La toolbox est la boîte à outils du pentest : outils de sécurité, moteur local qui organise les tests et génération des rapports. L’image Docker est le paquet qui contient ces éléments et leurs versions. Docker utilise cette image pour lancer des conteneurs, des environnements d’exécution séparés sur votre machine.
Votre agent récupère les ressources de préparation, puis construit l’image avec Docker après votre accord. Vous n’avez pas de recette Docker à écrire. La construction se fait sur votre machine ; aucun service d’intégration continue n’est nécessaire. Les versions sont ensuite figées. Des vérifications distinctes contrôlent que les outils sont présents et fonctionnent.
Les outils sont récupérés depuis leurs distributions officielles, avec leur version et leur empreinte vérifiées. Leur maintenance consiste à mettre à jour l’outil complet ; Grace ne remplace pas séparément ses bibliothèques internes. Le contrôle de sécurité de la toolbox couvre aussi ces bibliothèques. Une alerte sur un outil de la toolbox concerne ce qui vous est fourni pour tester ; elle ne constitue pas un constat de vulnérabilité de votre application.
La toolbox est distincte de votre application et n’est pas réservée aux projets Grace. Votre opérateur choisit le mode local avec des données fictives :
| Mode | Ce qui tourne sur votre machine |
|---|---|
| Laboratoire isolé | Une copie jetable de l’application, dans ses propres conteneurs, recréée pour chaque mission. |
| Application existante | Votre application Web ou API est déjà démarrée. Le pentest envoie les requêtes HTTP(S) autorisées à ses adresses locales ; il ne la démarre, ne l’arrête et ne la réinitialise pas. |
Dans le second mode, l’état reste partagé entre missions et les écritures autorisées peuvent persister. Vérifiez aussi les dépendances externes déclarées : l’application garde ses propres connexions sortantes. Sa version est déclarée par l’opérateur, sans attestation du processus exécuté. Ce mode couvre les contrôles HTTP d’autorisation, d’authentification, de canaris d’injection et de logique métier. Il n’automatise pas les interfaces d’applications desktop ou mobiles.
Ces tests Web/API ne demandent ni Appium ni Xcode ; votre application n’a pas besoin d’être exposée sur Internet. Installer Appium n’active pas le pilotage des interfaces desktop ou mobiles dans ce parcours.
2. Comment l’IA utilise-t-elle les outils ?
Une campagne regroupe les tests autorisés. L’IA reste dans l’outil que vous avez choisi, en dehors de la toolbox. Elle échange avec le moteur local par MCP, le protocole qui relie un agent IA à ses outils.
- Vous autorisez le plan. Vérifiez la cible, les comptes fictifs, les actions, la durée, les budgets et les données que le fournisseur IA peut recevoir dans le formulaire présenté.
- L’IA choisit un contrôle admis. Le contrôleur, la partie du moteur qui vérifie les autorisations, contrôle la demande puis lance l’outil. L’IA ne dispose pas d’un terminal libre dans la toolbox.
- L’IA analyse l’observation. Elle reçoit les extraits autorisés, choisit le contrôle suivant ou conclut. Un refus ou un résultat incertain arrête l’action concernée.
- Une mission distincte vérifie le constat. Un validateur reçoit l’hypothèse et les preuves utiles dans un nouveau contexte IA, sans la conversation du chercheur. Il cherche à reproduire le problème ; une preuve insuffisante reste signalée.
- Vous lisez le rapport local. Le HTML, et le PDF lorsque son export est disponible, distinguent les constats des tests bloqués, incomplets ou non effectués. Les conteneurs créés pour la campagne sont arrêtés et leur nettoyage est vérifié ; les preuves sont conservées. En mode application existante, seules les ressources du pentest sont libérées : votre application reste démarrée et ses données ne sont pas restaurées.
3. Où vont les données ?
| Élément | Pendant la campagne |
|---|---|
| Application testée | Laboratoire jetable ou application locale déjà démarrée, avec des données fictives ; votre production n’est pas la cible. |
| Preuves originales et rapport | Conservés dans un espace privé local. |
| Observations reçues par l’IA | Extraits réduits et masqués, limités à ce que vous avez autorisé. Avec un modèle cloud, ces extraits peuvent quitter votre machine. Leur réduction ne garantit pas l’anonymisation. |
| Grace | Déconnecté avant les tests. Les consignes sont préparées auparavant ; aucune donnée de campagne, même masquée, ne lui est envoyée. |
L’autorisation de tester l’application et l’accord sur les données transmises au fournisseur IA sont deux décisions distinctes. Lire le rapport n’autorise aucune correction : modifier le code et vérifier la correction demandent une nouvelle tâche et les accords correspondants. Le mode application existante permet une nouvelle campagne indépendante, mais ne propose pas encore de retest lié attestant la correction d’une révision.
Passer à la préparation
Prévoyez Docker démarré sur la machine de votre agent IA, l’application de test dans le mode choisi et les capacités de confirmation humaine et de missions séparées vérifiées dans votre outil IA. Suivez ensuite l’installation du pentest.
Le résultat à vérifier est un rapport qui explique ce qui a réellement été testé et ce qui reste inconnu. Un rapport sans constat ne garantit pas l’absence de vulnérabilités.