Module 6 sur 10 · 40 min

AI Swarm Pentest

Menez un AI Swarm Pentest comme une mission autorisée, au périmètre défini. Prouvez que vous êtes propriétaire de la cible, puis configurez et lancez un AI Pentest, suivez l'essaim en direct et examinez des constats étayés par des preuves de concept enregistrées.

À la fin de ce module, vous saurez

  • Expliquer les règles d'engagement et les garde-fous qui font d'AI Swarm Pentest une mission autorisée, au périmètre défini
  • Décrire comment l'essaim transforme des hypothèses en constats vérifiés de manière indépendante
  • Prouver la propriété d'une cible au moyen d'une balise meta HTML, d'un fichier /.well-known ou d'un enregistrement DNS TXT
  • Configurer, lancer et suivre une évaluation avec l'assistant New AI Pentest et la page d'exécution
  • Examiner les constats App Pentest, les artefacts de preuve de concept, le rapport et votre quota mensuel de sessions

Une mission autorisée, au périmètre défini

AI Swarm Pentest constitue l’étape Valider de Proof-Driven AppSec. Avant que Plexicus ne vous aide à comprendre une faiblesse dans le code (Deep Code Analysis, module 5) ou à la corriger (Remediation, module 7), il vous montre quels chemins d’attaque sont réels dans une application en cours d’exécution. Dans le produit, AI Swarm Pentest apparaît sous le nom AI Pentest, dans sa propre entrée Pentest de la barre latérale.

Un pentest envoie du trafic réel vers un système réel : tout commence donc par l’autorisation.

Les règles d’engagement

Un AI Swarm Pentest porte sur une application, une API, du code source ou un environnement de test autorisés. Avant le début des travaux, la cible, les accès de test et les règles d’engagement sont convenus par écrit, et Plexicus n’agit pas en dehors de ce périmètre. Concrètement, vos règles d’engagement répondent à quatre questions :

  • Ce qui entre dans le périmètre : l’URL exacte de l’application ou le domaine, et l’environnement concerné (préproduction ou production).
  • Les accès de test que vous fournissez, le cas échéant : aucun, un compte de test dédié, ou des clés API ou en-têtes de test (la leçon 4 explique pourquoi vous ne devez pas présumer qu’ils sont utilisés).
  • Ce qui est exclu : par exemple la suppression de comptes, l’envoi d’e-mails ou de SMS, ou l’encaissement de paiements.
  • Qui décide de la suite à donner aux résultats.

Lorsque votre équipe utilise AI Pentest dans la plateforme, c’est elle qui rédige et approuve ces règles en interne. L’assistant en reprend une partie : la cible, les paramètres d’authentification, les éléments hors périmètre et le brief.

Ce que c’est, et ce que ce n’est pas

AI Swarm Pentest s’appuie sur des vérifications IA coordonnées qui cartographient votre application, formulent des hypothèses, testent des chemins d’attaque et joignent des preuves à ce qu’elles trouvent. Il automatise le travail répétitif d’exploration, de corrélation et de reproduction. Votre équipe garde le contexte, la supervision et la décision finale.

Ce n’est pas :

  • un scanner à signatures qui compare des motifs connus,
  • un chatbot de sécurité qui suggère des réponses,
  • un contrôle lancé sans périmètre signé,
  • un pentest humain classique, sur site, étalé sur plusieurs jours,
  • une liste sans fin de « problèmes potentiels » non priorisés,
  • un outil qui modifie automatiquement la production.

Si rien ne peut être confirmé, les résultats ne sont pas gonflés d’alertes théoriques. Plexicus ne promet pas zéro vulnérabilité. Il promet que tout ce qui est présenté comme vérifié peut être démontré.

Les quatre garde-fous

Les quatre garde-fous du module 1 (périmètre convenu par écrit, preuves traçables, limites de mission et décision humaine) s’appliquent à chaque exécution. Concrètement, l’assistant les applique ainsi :

L’assistant transmet à l’agent un périmètre restreint : l’hôte de l’URL cible lui-même, sans domaine supplémentaire, sur les ports 80 et 443 ainsi que sur tout port indiqué dans l’URL. Destructive actions est présélectionné comme hors périmètre à la dernière étape de l’assistant. Chaque élément hors périmètre que vous sélectionnez parvient à l’agent sous la forme d’une consigne écrite de ne pas l’exécuter. Il s’agit d’une consigne, et non d’un blocage technique : associez-la donc à une cible de préproduction et à des moyens de paiement de test. Quelle que soit la profondeur, Quick compris, des requêtes réelles sont envoyées à la cible.

Le fonctionnement de l’essaim

Un scanner à signatures compare votre application à des motifs connus et vous indique où regarder. Un chatbot de sécurité répond aux questions à partir du contexte que vous lui fournissez. AI Swarm Pentest ne fait ni l’un ni l’autre. Il explore des chemins, teste des hypothèses et joint des preuves, afin que vous puissiez prioriser ce qui mérite votre attention.

Le travail est réparti entre des vérifications IA coordonnées. Elles cartographient la surface, formulent des hypothèses et testent des chemins d’attaque dans le périmètre convenu, puis une seconde passe confirme chaque constat de manière indépendante avant qu’il soit marqué comme vérifié. Dans le produit, l’agent de pentest Plexicus s’exécute sur votre URL cible, guidé par le brief que vous rédigez dans l’assistant (leçon 4). Les modes de scan plus approfondis autorisent des exécutions plus longues et un effort plus important de l’agent. Pendant qu’une exécution est active, la War room (live board) de la page d’exécution montre l’activité de l’essaim.

Du signal au constat vérifié

La mission est conçue pour qu’une seule vérification ne suffise jamais à qualifier un résultat de vérifié. Un résultat passe par trois étapes :

  1. Constat candidat. Une hypothèse produit un signal assorti d’un contexte technique.
  2. Vérification indépendante. Une seconde passe tente de confirmer par elle-même le comportement observé.
  3. Constat vérifié. Seul un résultat confirmé est présenté comme vérifié, avec son impact et une priorité fondée sur le risque réel (sévérité et contexte), et non sur l’ordre d’arrivée.

Selon l’exigence de preuve, un résultat qu’une seconde passe ne parvient pas à reproduire n’est pas présenté comme un constat vérifié. Il est marqué comme non vérifié ou écarté. C’est la règle du module 1 : pas de preuve reproductible, pas de constat vérifié.

Dans le produit, le badge Unverified de la liste Pentest concerne la propriété de la cible (leçon 3), et non les constats. Ne le lisez pas comme un verdict sur un constat.

Ce que cela implique pour la lecture des résultats

Cette conception a deux conséquences pratiques.

Peu de constats, c’est un résultat, pas un échec. Une exécution qui s’arrête parce qu’elle a atteint sa limite de temps ou son budget IA est tout de même marquée Completed. Une exécution Completed qui compte peu de constats, voire aucun, vous indique ce que l’essaim a pu confirmer ou non dans ce laps de temps. Elle ne prouve pas que la cible a été testée de manière exhaustive. Orientez davantage l’exécution suivante : un scan plus approfondi, des axes de test précis, un brief plus clair.

La revue humaine reste de mise. Les constats de pentest passent par la même validation par l’IA que les autres constats Plexicus, y compris le verdict de l’IA et l’analyse des faux positifs présentés aux modules 4 et 5. Si vous êtes en désaccord avec un verdict, utilisez Mark as false positive. Cette action ne demande aucune justification écrite : consignez donc votre raisonnement dans votre ticket ou dans les notes de l’équipe. Rien n’atteint la production sans une décision de votre équipe.

Si votre organisation a configuré son propre fournisseur d’IA, l’agent de pentest utilise ce fournisseur. Sinon, il utilise un modèle géré par Plexicus. Le code des clients n’est pas utilisé pour entraîner des modèles d’IA.

Prouver que vous êtes propriétaire de la cible

Avant que l’agent n’envoie la moindre requête, Plexicus exige la preuve que vous contrôlez la cible. Launch AI Pentest reste désactivé tant que la propriété n’est pas vérifiée, et le serveur rejette les cibles non prouvées même si quelqu’un contourne l’interface.

Pourquoi accepter des conditions ne constitue pas une preuve

Accepter des conditions d’utilisation est une déclaration, pas une preuve. N’importe qui peut accepter des conditions pour un domaine qu’il ne contrôle pas : Plexicus ne les considère donc pas comme une autorisation. Comme l’agent envoie du trafic réel susceptible de modifier l’état de la cible, Plexicus n’accepte que des preuves qui vous obligent à modifier quelque chose sur la cible elle-même : un jeton dans son HTML, dans un fichier qu’elle sert ou dans son DNS.

Deux périmètres, trois méthodes

À l’étape Verify ownership de l’assistant, vous choisissez un périmètre :

PérimètreMéthodeCouvertureIdéal pour
Verify this applicationBalise meta HTML ou fichier sous /.well-known/Uniquement cet hôte précisUne seule application, la voie la plus rapide
Verify the whole domainEnregistrement DNS TXTLe domaine et tous ses sous-domaines, actuels et futursLes équipes qui testent de nombreuses applications sur un même domaine

Le contrôle au lancement accepte l’une ou l’autre preuve. Un domaine vérifié couvre le domaine lui-même et tous ses sous-domaines. Une application vérifiée couvre cet hôte précis.

L’option Verify this application

L’assistant affiche un Verification token. Publiez-le de l’une des deux façons suivantes. Vous pouvez ajouter cette balise meta à la page cible, en la copiant exactement telle qu’elle est affichée, avec name avant content :

<meta name="plexicus-site-verification" content="YOUR-TOKEN">

Vous pouvez aussi servir à l’adresse /.well-known/plexicus-verification.txt un fichier contenant le jeton. Cliquez ensuite sur Recheck. Plexicus vérifie automatiquement les deux : d’abord le fichier à l’origine du site, puis la balise meta sur l’URL cible exacte. Gardez trois règles en tête :

  • La réponse doit renvoyer un code HTTP 200.
  • Les redirections ne sont pas suivies : une page qui redirige vers un écran de connexion fait donc échouer le contrôle.
  • Chaque requête expire au bout de 10 secondes.

Lorsque le contrôle réussit, le statut indique « Ownership verified · HTML meta tag or file ».

L’option Verify the whole domain

Choisissez Verify the whole domain : l’assistant affiche un Host et une TXT record value, c’est-à-dire un jeton qui commence par verif-. L’assistant propose le domaine parent de votre cible : pour app.example.com, il s’agit de example.com. Contrôlez le Host avant de publier quoi que ce soit. Vous ne pouvez pas le modifier, et l’assistant propose toujours les deux derniers libellés de l’hôte. S’il est erroné (par exemple co.uk pour shop.example.co.uk), utilisez plutôt Verify this application. Sinon, ajoutez l’enregistrement TXT chez votre fournisseur DNS, attendez sa propagation, puis cliquez sur Recheck. Si l’enregistrement n’est pas encore visible, vous voyez « Verification token not found yet — DNS changes can take time to propagate ».

Lorsque le badge et le lancement ne concordent pas

La colonne Verification de la liste Pentest ne reconnaît qu’un domaine vérifié pour l’hôte cible exact. Une cible couverte par une vérification d’application, ou par un domaine parent vérifié, peut afficher Unverified. Sa ligne peut alors proposer Verify first au lieu de View Findings, Rescan ou Run. C’est le contrôle au lancement qui fait foi. Dans ce cas, ouvrez les constats depuis Findings App Pentest et, pour tester à nouveau, lancez un New AI Pentest sur la même URL.

Si une exécution est refusée pour une question de propriété, le message indique « Target URL is not verified. Please verify this application or the whole domain under Settings → Domain Verification. » Dans le menu des paramètres, cette page s’intitule Ownership Verification.

Mener une évaluation

Une évaluation est une définition de pentest enregistrée (nom, URL cible, authentification, dépôt facultatif, consignes de scan) que vous pouvez exécuter autant de fois que nécessaire.

L’assistant, étape par étape

ÉtapeCe que vous définissez
1. TargetAssessment name et Target URL. Si vous omettez le schéma, https:// est ajouté.
2. Verify ownershipPreuve pour l’application ou pour le domaine entier (leçon 3), puis Recheck.
3. AuthenticationNo authentication, Username / Password (Login URL, nom d’utilisateur de test, mot de passe de test) ou API Keys / Headers.
4. Source repositoryFacultatif : Select existing, Connect new, ou aucun dépôt pour une exécution en boîte noire.
5. Scan & launchProfondeur de scan, axes de test, éléments hors périmètre, stack technique connue, Additional context, puis un récapitulatif (Summary).

Remarques sur l’assistant :

  • Authentification. Si vous fournissez un accès, utilisez un compte de test dédié, jamais celui d’un véritable utilisateur. Les mots de passe et les valeurs d’en-têtes enregistrés ne sont jamais renvoyés par l’API. Pour utiliser d’autres identifiants, créez une nouvelle évaluation. Les tests authentifiés ne sont pas garantis : considérez une exécution comme non authentifiée tant que la vue du navigateur en direct ou l’enregistrement ne montre pas que l’agent s’est connecté et a atteint les zones attendues.
  • Dépôt source. Associer un dépôt donne à l’agent accès à votre code source pour une exécution en boîte blanche. Share source code with the engine (whitebox scan) est activé par défaut. Désactivez-le pour effectuer un test en boîte noire tout en gardant le dépôt associé.
  • Profondeur. Quick (« Minutes · CI/CD & smoke checks »), Standard (« 30 min–1 hr · routine review », la valeur par défaut) ou Deep (« 1–4 hr · full audit, chained exploits »). Les durées affichées par l’assistant sont indicatives. Chaque exécution est limitée dans le temps selon sa profondeur, et une exécution qui n’a produit aucun résultat avant sa limite est marquée Failed.
  • Consignes. Choisissez des axes de test comme Access control (IDOR), passez en revue la liste des éléments hors périmètre et rédigez le champ Additional context comme un brief destiné à un pentester humain : flux critiques, problèmes à revérifier, points de terminaison à éviter. L’ensemble constitue le brief de l’agent.

Lorsque vous cliquez sur Launch AI Pentest, Plexicus vérifie également que le connecteur AI Pentest est activé, que tout dépôt associé appartient à votre organisation et qu’il vous reste une session ce mois-ci. Si tous les contrôles réussissent, vous voyez « Scan started. » et arrivez sur la page d’exécution. Si le connecteur est désactivé, une personne autorisée à gérer les connecteurs peut l’activer dans Pentest Configure .

Si un contrôle échoue, l’assistant affiche une erreur et enregistre l’évaluation à l’état Draft. Corrigez la cause, puis ouvrez l’évaluation Draft depuis la liste Pentest et cliquez sur Run dans sa page d’exécution. Relancer depuis l’assistant créerait une seconde évaluation.

Les statuts d’exécution

StatutSignification
DraftCréée, mais non lancée. Seule une évaluation Draft peut être modifiée, et uniquement via l’API.
PendingLancement accepté. L’exécution démarre.
RunningL’agent effectue ses tests. Vous pouvez annuler l’exécution depuis sa page.
CompletedL’exécution s’est terminée et a renvoyé des résultats.
FailedL’agent a signalé une erreur, ou aucun résultat n’est arrivé avant la limite de temps de l’exécution.
CancelledQuelqu’un a annulé l’exécution.

Suivre une exécution

La page d’exécution affiche « Scan in progress » avec un chronomètre du temps écoulé. Au bout de 90 minutes, la bannière devient « Scan may be stuck » et propose Cancel.

La Live browser view diffuse le navigateur de l’agent. La War room (live board) montre l’activité de l’essaim avec un badge LIVE. Sur les exécutions terminées, elle affiche Replay, et Expand passe en plein écran. Seule votre organisation peut ouvrir ces vues en direct.

Vous obtenez aussi des captures d’écran et, s’il existe, un Session recording du navigateur de l’agent. Avec les rôles intégrés, Admin et Cyberoper peuvent lancer et annuler des exécutions. Developer dispose d’un accès en lecture seule (module 10).

Preuves et résultats

Lorsqu’une exécution se termine, vous disposez de constats, d’un rapport, de captures d’écran et, s’il a été produit, d’un enregistrement de session. Les constats de pentest s’accompagnent normalement d’un artefact de preuve de concept.

Les constats sur la page d’exécution

La carte Findings liste chaque constat avec un badge de sévérité et un titre. Cliquez sur l’un d’eux pour afficher sa description, l’URL concernée et le type de son artefact de preuve de concept :

ArtefactContenu
Commande cURLLa requête HTTP qui a démontré le problème, sous forme de commande cURL.
Script shellLes étapes de reproduction enregistrées, sous forme de script.
Capture HARUne archive HTTP (HTTP Archive) enregistrée de la session, affichée en JSON mis en forme.

View PoC ouvre l’artefact dans une visionneuse, et Download l’enregistre sous son nom de fichier d’origine. Les artefacts restent disponibles après la fin de l’exécution. Si une exécution terminée ne compte aucun constat, la carte affiche « No findings ».

Les constats de toutes les exécutions

Les constats de pentest sont enregistrés comme des constats Plexicus ordinaires, rattachés à leur pentest. Ouvrez Findings App Pentest pour les traiter dans le tableau, les filtres et le panneau de détail standard des constats, ou cliquez sur View Findings sur une ligne terminée de la liste Pentest.

Dans le panneau de détail, un constat de pentest affiche Evidence & attack path au lieu de Code & taint trace. Cette section contient l’URL cible, une pastille qui indique si un dépôt source était associé (« White-box run — source repository linked » ou « Black-box run — no source repository »), le type d’artefact (CURL, HAR ou SCRIPT) et Download artifact. Le panneau présente l’artefact comme un rejeu déterministe : la commande et les preuves attendues sont affichées telles qu’elles ont été enregistrées, et rien n’est réexécuté depuis votre navigateur (« shown as recorded; nothing is re-run from your browser. »). La visionneuse affiche jusqu’à 64 Ko d’un artefact. Au-delà, téléchargez-le pour voir la capture complète. Si aucun artefact n’a été enregistré, le panneau indique « No stored replay artifact for this finding. »

Rapport et enregistrement

Download report apparaît dans l’en-tête de la page d’exécution dès que l’agent a enregistré son rapport, un fichier Markdown (.md) produit à la fin de l’exécution. Download video télécharge l’enregistrement de session au format .webm. Pour exporter les constats App Pentest en PDF ou en JSON, utilisez Findings App Pentest Download (le reporting est traité au module 8). Les constats vérifiés rejoignent ensuite votre workflow de remédiation habituel (module 7). Vérifiez auprès de votre contact Plexicus que les correctifs IA sont disponibles pour les constats de pentest dans votre version. C’est toujours votre équipe qui décide de fusionner ou non.

Les quotas de sessions

L’utilisation d’AI Pentest est décomptée en sessions mensuelles, distinctes de votre quota d’utilisation de l’IA. Le nombre de sessions dont vous disposez dépend de votre offre. Si votre offre n’inclut pas AI Pentest, New AI Pentest affiche une invitation à passer à une offre supérieure au lieu de l’assistant.

  • Chaque Run ou Rescan consomme une session.
  • Lorsque les données d’utilisation sont disponibles, le menu de votre profil affiche un compteur Pentest avec les sessions utilisées et la limite du mois en cours (ou Unlimited). Lorsque la facturation est affichée pour votre offre, Settings Billing comporte aussi une carte Pentest Sessions.
  • Une session n’est restituée automatiquement que si l’exécution échoue avant le démarrage de l’agent, par exemple en cas d’échec de l’initialisation. Une fois l’agent démarré, l’annulation de l’exécution ou un échec ultérieur consomme tout de même la session.
  • Lorsqu’il ne vous reste plus de sessions, le lancement est refusé avec le nombre de sessions utilisées, la limite et la date de réinitialisation.
  • Le décompte des sessions est réinitialisé le 1er de chaque mois civil (UTC), et non à votre date de facturation.

Préparez le terrain avant de consommer une session : vérifiez la propriété, passez en revue la liste des éléments hors périmètre, rédigez le brief et choisissez la profondeur adaptée à la question que vous vous posez.

Points clés à retenir

  • AI Swarm Pentest (AI Pentest dans le produit) est une mission autorisée, au périmètre défini, encadrée par les quatre garde-fous du module 1 : périmètre convenu par écrit, preuves traçables, limites de mission et décision humaine. Il n’effectue aucune modification automatique en production.
  • L’essaim cartographie la surface, formule des hypothèses et teste des chemins d’attaque dans le périmètre convenu, et une seconde passe doit confirmer un résultat avant qu’il soit présenté comme vérifié. Pas de preuve reproductible, pas de constat vérifié.
  • Un lancement exige une propriété prouvée : une balise meta ou un fichier /.well-known pour un hôte, ou un enregistrement DNS TXT pour un domaine entier. Accepter des conditions ne constitue pas une preuve, et le badge Verification de la liste Pentest n’est qu’une indication.
  • L’assistant New AI Pentest comporte cinq étapes. Privilégiez la préproduction, gardez à l’esprit que les éléments hors périmètre sont des consignes et non des blocages techniques, et rédigez le brief comme vous le feriez pour un pentester humain.
  • Les constats de pentest s’accompagnent normalement d’un artefact de preuve de concept (commande cURL, script shell ou capture HAR), affiché exactement tel qu’il a été enregistré. Rien n’est réexécuté depuis votre navigateur.
  • Chaque Run ou Rescan consomme une session mensuelle, qui n’est restituée que si l’exécution échoue avant le démarrage de l’agent. La bannière « Scan may be stuck » affichée au bout de 90 minutes ne justifie pas à elle seule l’annulation d’une exécution Deep.

Contrôle des connaissances

Vérifiez vos acquis

Questions d'entraînement pour ce module. Elles ne comptent pas pour la certification. Seuil de réussite : 4 bonnes réponses.

  1. Question 1 Laquelle de ces options satisfait au contrôle de propriété pour un AI Pentest visant app.example.com ?
  2. Question 2 Une exécution Completed ne signale aucun constat. Que pouvez-vous en conclure ?
  3. Question 3 Une exécution affiche le statut Pending. Qu'est-ce que cela signifie ?
  4. Question 4 Où pouvez-vous examiner les constats de pentest de toutes les exécutions, avec le tableau et les filtres standard des constats ?
  5. Question 5 Dans quel cas une session AI Pentest est-elle automatiquement restituée à votre quota mensuel ?

Qualification

Vérifiez si l'AI Swarm Pentest convient à votre environnement.

Partagez le contexte minimum. Nous vérifierons le périmètre et indiquerons la prochaine étape commerciale.

Avant d'envoyer — vérifiez que vous correspondez

0 / 280

Sans engagement. Si vous ne correspondez pas, nous vous le dirons.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorized target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)
Tour privé Pour les investisseurs