Établissez un flux de travail encadré pour votre test autorisé avant de demander à un grand modèle de langage (LLM) d’analyser des documents fournis par le client. Un grand modèle de langage (LLM) génère du texte en se basant sur des schémas identifiés dans les données d’entrée. Dans le cadre d’un test d’intrusion, il peut accélérer l’interprétation de routine, mais il ne peut pas déterminer si une affirmation est avérée, autorisée ou prête à être transmise au client.
Simulation — scénario de mission :
Lors d’une mission autorisée pour Redwood Payments, un testeur soumet à un LLM le texte d’un résultat d’analyse semblant indiquer une vulnérabilité critique. Le modèle rédige une description soignée de la découverte, incluant une référence CVE et une analyse de l’impact métier. Le testeur vérifie les données brutes de l’analyse ainsi que la version de la cible, constate que la CVE ne s’applique pas, et supprime la découverte avant que le rapport ne soit transmis au client.
L’objectif ne se limite pas à une rédaction plus rapide. Il s’agit d’obtenir des preuves solides, un rapport précis et la confiance du client. Chaque contribution du LLM doit rester dans le périmètre de la mission et faire l’objet d’une vérification humaine avant de modifier une découverte ou un livrable destiné au client. Intégrons ces étapes de vérification dans le flux de travail pour Redwood Payments :
Une étape de vérification est un point de contrôle où le testeur compare la réponse du LLM aux preuves primaires avant de l’utiliser. Les preuves primaires comprennent les résultats d’outils approuvés, les horodatages, les commandes, les captures d’écran et les détails validés de la cible. Le testeur assume la responsabilité de l’affirmation, même si le LLM a organisé les informations ou rédigé le texte.
Utilisez le LLM pour une assistance encadrée. Il peut résumer les notes de reconnaissance, trier les résultats d’analyse, expliquer une vulnérabilité validée et rédiger des parties du rapport. Il ne doit en aucun cas générer d’exploits, étendre le périmètre autorisé ni se substituer à la preuve de l’existence d’une vulnérabilité sur la cible approuvée. Nous pouvons effectuer les vérifications requises à chaque point d’interaction autorisé :
Les erreurs générées par les LLM (grands modèles de langage) posent des problèmes spécifiques lors des tests d’intrusion, car une formulation soignée peut conférer une apparence de crédibilité à des affirmations non étayées. Les CVE inventées, les niveaux de gravité erronés, les faux positifs, l’extension non maîtrisée du périmètre (scope creep) et les fuites de données nécessitent chacun une méthode de vérification adaptée. Signaler un problème potentiel n’est utile que si le testeur est en mesure de le reproduire ou de l’infirmer à partir des éléments probants sous-jacents.
La preuve avant tout Considérez un brouillon généré par un LLM comme une simple note de travail. Une constatation ne peut être intégrée au rapport que si ses preuves, son périmètre, son impact et ses références résistent à l’examen critique du testeur.
Les données client constituent une limite distincte. Les résultats de scans, les journaux (logs), les éléments d’authentification et les données personnelles peuvent contenir des informations dont le client n’a jamais autorisé le traitement par un service externe. Masquez ou omettez ces éléments, sauf si une autorisation écrite couvre spécifiquement le service et l’usage concernés. Chaque type de défaillance peut être associé à la pratique permettant de la prévenir :