Menu

Star on GitHub · 3.2k

Pentest agentique

Un agent IA prend le fauteuil du testeur : il planifie, sonde et s'adapte sur une cible comme le ferait une personne, puis remet une courte liste de failles vérifiées à un humain. Voici ce que cela veut dire concrètement, comment ça marche, et où une personne reste nécessaire dans la boucle.

Ce que c'est

Un agent est un programme qui raisonne vers un objectif au lieu d'exécuter un script figé. Donnez-lui une cible et un but — « trouver ce qu'un attaquant pourrait réellement atteindre ici » — et il décide quoi tenter ensuite selon ce qu'il a déjà observé : cartographier la surface, formuler une hypothèse, la tester, lire la réponse, corriger, avancer. Le pentest agentique, c'est cette boucle appliquée à la sécurité offensive.

Il raisonne, il ne suit pas un script : raisonner vers un objectif, pas une batterie figée

Il se situe entre les deux outils employés aujourd'hui. Un scanner lance une batterie de vérifications fixe et signale tout ce qui correspond à une signature — rapide, mais aveugle au contexte et bruyant en faux positifs. Un pentesteur humain raisonne sur l'application précise et sa logique métier — lent, coûteux, et un instantané d'une semaine. Un agent vise le raisonnement du pentesteur avec une portée proche de celle du scanner, et laisse les décisions de jugement à une personne.

Pourquoi la sécurité offensive a stagné

La sécurité s'est largement modernisée — intégration continue, cloud, défense automatisée. La sécurité offensive, en grande partie, non. Elle reste surtout livrée comme un service, à la main, et traîne trois problèmes qui n'ont jamais disparu :

  • Ponctuel. Un pentest décrit l'application telle qu'elle était la semaine du test. Le déploiement suivant peut invalider le rapport.
  • Difficile à passer à l'échelle. Les bons testeurs sont rares et chers, donc la profondeur est rationnée. Beaucoup de missions s'appuient sur du travail junior ou externalisé et optimisent le volume de failles plutôt que la qualité.
  • La conformité avant la sécurité. Trop souvent, le test devient une case à cocher pour un audit plutôt qu'une vraie tentative de casser le système.

Les limites de l'automatisation jusqu'ici

Les outils automatisés ont comblé une partie de l'écart pour l'infrastructure, où les cibles se ressemblent. Pour les applications web, ils restent systématiquement en deçà, et la raison est le problème du dernier kilomètre : chaque application est différente. Les failles qui comptent — contrôle d'accès cassé, défauts de logique métier, vulnérabilités chaînées — dépendent de la compréhension de ce à quoi sert un endpoint précis, ce qu'une signature ne peut pas encoder.

C'est le même mur qu'a heurté l'ancienne catégorie DAST : elle pouvait signaler un motif, mais pas raisonner pour savoir s'il comptait ici, ni quoi faire ensuite. Les équipes ont donc continué à payer pour du test humain, non parce que les outils échouaient à s'exécuter, mais parce qu'ils échouaient à penser.

Ce que change un agent

Les modèles de langage ont rendu la pièce manquante praticable : un système capable de tenir le contexte d'une application et d'adapter son test en conséquence. Utilisé avec prudence, cela transforme trois choses qui s'opposaient jusque-là en propriétés que l'on peut avoir ensemble :

  • Continu plutôt qu'annuel. Le test peut tourner à chaque changement, de sorte que le résultat suit l'application au lieu de décrire la version du trimestre dernier.
  • Sensible au contexte plutôt qu'à la signature. L'agent part du comportement réel de l'application : quels objets existent, quels rôles les atteignent, à quoi sert un appel donné.
  • Une courte liste vérifiée plutôt qu'un backlog. La sortie doit être la poignée de problèmes réellement exploitables, avec les étapes pour les reproduire — pas des milliers de failles « potentielles » non triées.

Comment ça marche

Ce qui rend cela fiable, c'est précisément de ne pas laisser le modèle improviser librement. Chez CyberStrike, l'agent raisonne au-dessus d'un moteur déterministe qui fait le travail où un modèle est mauvais : il ingère chaque requête et réponse, applique des centaines de règles, construit une carte inter-identités des rôles qui ont atteint quels objets et fonctions, sonde les points d'injection et rejoue les requêtes sous des limites de sécurité strictes. Ce moteur produit la vérité terrain.

Le rôle de l'agent est de décider quoi poursuivre — quelles pistes semblent exploitables, quelle chaîne tenter ensuite — et d'expliquer pourquoi. La preuve vient du moteur, pas de l'imagination du modèle ; une faille s'appuie donc sur du trafic réel qu'une personne peut rejouer. Le jugement est celui de l'agent ; les faits sont déterministes.

Ce que les agents ne savent pas encore faire

C'est ici que l'honnêteté compte plus que l'enthousiasme. La technologie n'est pas aboutie, et quiconque prétend le contraire vous vend quelque chose :

  • Les modèles hallucinent. Un modèle de langage affirmera parfois une vulnérabilité qui n'existe pas. C'est exactement pourquoi les failles doivent être rattachées à des preuves reproductibles, et pourquoi un compte rendu assuré n'est pas la même chose qu'un vrai bug.
  • La sortie n'est pas déterministe. Lancez deux fois la même requête et vous pouvez obtenir des chemins différents. La reproductibilité doit venir du moteur et du trafic enregistré, pas du modèle qui se donne raison.
  • Sûreté et autorisation sont des décisions humaines. Le périmètre, les règles d'engagement et le « est-il sûr d'envoyer cette requête en production » ne sont pas à confier à un processus autonome.
L'agent sonde, un humain décide : human-on-the-loop, pas une autonomie totale

Le modèle réaliste est donc le human-on-the-loop : l'agent assure l'ampleur et le travail ingrat, et une personne valide les failles, assume les décisions à risque et répond du rapport. C'est ce couplage — pas l'autonomie totale — qui est livrable aujourd'hui.

Sa place

Le pentest agentique ne met au rebut ni les testeurs humains ni la validation d'audit. Il change ce à quoi l'humain consacre son temps : moins à redécouvrir la même surface chaque trimestre, davantage à valider des failles réelles et à prendre les décisions qui exigent une responsabilité. Le test devient continu ; la personne devient le relecteur plutôt que le crawler.

C'est tout le propos, et il est volontairement modeste. La sécurité offensive a toujours été le moyen le plus direct de comprendre le risque réel. Elle était simplement trop lente et trop rare pour être employée partout. Réduire cet écart, tout en restant clair sur ce qui nécessite encore une personne, c'est la version utile de cette technologie.

CyberStrike est une plateforme de tests d'intrusion augmentés par l'IA, actuellement en accès anticipé. Envie de voir l'agent et le moteur qui l'accompagne ? Explorez la plateforme ou rejoignez la liste d'attente.

Envie de voir plus en détail comment ça tourne ?