L'évolution de la cybersécurité offensive vers un modèle basé sur la preuve. Comment les agents IA raisonnent comme des pentesters et produisent des preuves.
Jordan Fredj
March 10, 2026
10 min
Loading...
Jordan Fredj
Fondateur, Hacksessible
Pendant des decennies, la cybersécurité offensive a fonctionne selon un modele simple : scanner, détectér, reporter. Des outils automatisés parcourent les systèmes, identifiént des vulnérabilités potentielles, et produisent des rapports volumineux classes par severite. Mais ce modele atteint ses limites. Les equipes de sécurité croulent sous les alertes, les faux positifs polluent les rapports, et les decideurs peinent a distinguer les risques theoriques des menaces reelles. L'emergence de l'IA dans la cybersécurité offensive change fondamentalement cette equation en introduisant un nouveau paradigme : du risque a la preuve.
Le modele traditionnel de la cybersécurité offensive repose sur l'identification de risques theoriques. Un scanner détecté qu'un serveur utilise une version obsolete d'OpenSSL, lui attribue un score CVSS de 9.1, et le rapport recommande une mise a jour urgente. Mais ce score ne repond pas aux questions essentielles : cette vulnérabilité est-elle réellement exploitable dans mon contexte ? Quel est l'impact concret si elle est exploitee ? Y a-t-il des controles compensatoires qui la rendent inexploitable ?
Le résultat est previsible : les equipes de sécurité sont submergees par des centaines de vulnérabilités "critiques" dont une fraction seulement représente un risque reel. Les ressources sont dispersees sur des corrections qui n'ameliorent pas significativement la posture de sécurité, tandis que des failles réellement exploitables restent non traitees parce qu'elles n'ont pas ete correctement priorisees.
Selon les analyses de l'industrie, moins de 5% des vulnérabilités identifiées par les scanners sont effectivement exploitees dans la nature. Pourtant, les equipes de sécurité traitent souvent toutes les vulnérabilités "critiques" avec la meme urgence, diluant leurs efforts sur un volume ingerable. Le passage a un modele base sur la preuve d'exploitation resout ce problème fondamental en concentrant les efforts sur ce qui est réellement dangereux.
Le paradigme "du risque a la preuve" repose sur un principe simple : une vulnérabilité n'est confirmee que lorsqu'elle a ete exploitee avec succes dans le contexte spécifique de l'organisation. Cette approche transforme la nature meme des livrables de sécurité offensive.
Au lieu d'un rapport listant des centaines de vulnérabilités potentielles classees par score CVSS, l'organisation recoit un rapport contenant uniquement les vulnérabilités dont l'exploitation a ete demontree, accompagnees de preuves techniques reproductibles : les requetes HTTP envoyees, les réponses recues, les donnees accessibles, les privileges obtenus. Chaque vulnérabilité est accompagnee d'une demonstration concrete de son impact : "En exploitant cette faille IDOR sur l'endpoint /api/users/{"{id}"}/invoices, un attaquant avec un compte standard peut acceder aux factures de n'importe quel client, soit potentiellement 45 000 enregistrements financiers".
Cette approche change radicalement la conversation entre les equipes de sécurité et la direction. On ne parle plus de probabilites abstraites mais de faits demontres. Un COMEX qui voit une preuve d'exfiltration de donnees clients comprend immédiatement la gravite de la situation, bien mieux qu'avec un tableau de scores CVSS.
Les agents IA modernes ne fonctionnent pas comme des scanners ameliores. Ils reproduisent le processus cognitif d'un pentester humain expert, avec une approche en plusieurs phases.
Comme un pentester qui commence par naviguer sur l'application pour comprendre son fonctionnement, l'agent IA analyse la structure du système, identifié les flux de donnees, les mecanismes d'authentification, les roles utilisateurs et les points d'interaction. Il construit un modele mental du système avant de passer a l'attaque. Cette phase d'observation est cruciale car elle permet a l'IA d'identifier des surfaces d'attaque que les scanners classiques ne voient pas : des enchainements de fonctionnalites qui, combines, creent des vulnérabilités, des hypotheses de sécurité implicites qui peuvent etre violees, des cas limites dans la logique metier.
Sur la base de sa comprehension du système, l'agent IA formule des hypotheses d'attaque. Par exemple : "Cette API renvoie les donnees d'un utilisateur base sur un identifiant numerique sequentiel. Hypothese : le controle d'acces est peut-etre base uniquement sur l'authentification et non sur l'autorisation - un utilisateur authentifie pourrait acceder aux donnees d'autres utilisateurs en modifiant l'identifiant". Cette capacité de raisonnement est ce qui distingue fondamentalement l'IA d'un scanner : le scanner cherche des patterns connus, l'IA raisonne sur le contexte.
Chaque hypothese est testee methodiquement. L'agent IA construit des requetes spécifiques pour valider ou invalider ses hypotheses. Si une première tentative echoue, il adapte son approche : peut-etre le controle d'acces existe mais peut etre contourne par un encodage different de l'identifiant, ou par une manipulation des en-tetes HTTP. Cette capacité d'adaptation iterative est exactement ce que fait un pentester humain, mais l'IA peut tester des centaines de variations en quelques minutes.
Les vulnérabilités les plus dangereuses ne sont souvent pas des failles isolees mais des combinaisons de failles mineures qui, enchainées, menent a un impact majeur. L'agent IA excelle dans cette construction de chaines d'attaque : une fuite d'information sur un endpoint permet de decouvrir des identifiants internes, qui permettent d'exploiter un IDOR, qui donne acces a un token d'administration, qui permet une escalade de privileges complete. Cette capacité de raisonnement multi-etapes est l'un des apports les plus significatifs de l'IA dans la sécurité offensive.
Les preuves d'exploitation fournissent aux developpeurs et aux equipes d'operations tout ce dont ils ont besoin pour comprendre et corriger une vulnérabilité. Au lieu d'un vague "Injection SQL détectée sur le formulaire de connexion", ils recoivent le payload exact qui a fonctionne, la réponse du serveur, et les donnees qui ont ete extraites. Ils peuvent reproduire le problème immédiatement, comprendre exactement ou se situe la faille dans le code, et verifier que leur correction est efficace. Le temps de remédiation passe de jours (pour comprendre et reproduire une alerte vague) a heures (pour corriger un problème clairement documente).
Les preuves concretes permettent une communication claire avec la direction. "Notre plateforme contient une vulnérabilité qui permet a n'importe quel utilisateur d'acceder aux donnees financieres de tous nos clients - voici la preuve" est un message infiniment plus impactant que "Notre scanner a détecté 347 vulnérabilités dont 42 critiques". Les preuves facilitent aussi l'arbitrage budgetaire : il est beaucoup plus facile de justifier un investissement en sécurité quand on peut demontrer concretement les risques. La priorisation devient evidente quand on voit les preuves d'exploitation plutot que des scores theoriques.
Le paradigme "du risque a la preuve" s'inscrit dans une tendance plus large de l'industrie : le passage d'une priorisation basee sur la severite theorique (CVSS) a une priorisation basee sur la probabilite d'exploitation reelle (EPSS). Le score CVSS mesure la severite intrinseque d'une vulnérabilité dans le pire cas. Le score EPSS mesure la probabilite qu'une vulnérabilité soit effectivement exploitee dans les 30 prochains jours. En combinant les deux avec des preuves d'exploitation reelles, on obtient une priorisation qui reflete veritablement le risque operationnel.
Prenons un exemple concret. Une plateforme SaaS multi-tenant fait réalisér un scan de vulnérabilités. Le scanner identifié 200 vulnérabilités, dont 30 critiques. L'equipe de sécurité commence a traiter les critiques par ordre de score CVSS. Apres trois mois de travail, les 30 critiques sont corrigees, mais l'equipe n'a jamais détecté la faille la plus dangereuse : un defaut d'isolation entre les tenants qui permettait a un client d'acceder aux donnees d'un autre client via une manipulation d'API. Cette faille, invisible pour le scanner car elle releve de la logique metier, aurait ete détectée en quelques heures par un agent IA capable de tester l'isolation multi-tenant de maniere systematique.
Quand un pentest automatisé produit des preuves d'exploitation contenant des donnees sensibles (identifiants, donnees clients, informations financieres), la question de la souveraineté des donnees devient cruciale. Ou sont stockees ces preuves ? Qui y a acces ? Sous quelle juridiction ? Pour les entreprises européennes, utiliser une plateforme dont les donnees transitent par des serveurs americains ou chinois pose des problèmes réglementaires et strategiques evidents.
C'est pourquoi Hacksessible a fait le choix d'une infrastructure 100% souveraine, hebergee en France. Les preuves d'exploitation, qui sont par nature les donnees les plus sensibles d'un test de sécurité, ne quittent jamais le territoire européen. Cette approche est non seulement conforme au RGPD et aux exigences de l'ANSSI, mais elle constitue aussi un element de confiance fondamental pour les clients qui nous confient la sécurité de leurs systèmes.
La transition vers une approche basee sur la preuve ne se fait pas du jour au lendemain. Voici les étapes cles pour les organisations qui souhaitent adopter ce paradigme.
Commencez par évaluér votre approche actuelle : combien de vulnérabilités votre scanner remonte-t-il ? Quel pourcentage est effectivement traite ? Combien de faux positifs generez-vous ? Quel est votre MTTR (Mean Time To Remediate) ? Ces metriques de reference vous permettront de mesurer l'amelioration apportee par l'approche par la preuve.
Ensuite, commencez par un périmètre pilote : une application critique, un segment de votre infrastructure. Faites réalisér un pentest automatisé par IA avec generation de preuves et comparez les résultats avec votre approche habituelle. La difference de qualite et d'actionnabilite des résultats est généralement frappante.
Les preuves sont generees dans un cadre controle et ethique. Les donnees sensibles eventuellement découvertes sont anonymisees dans les rapports. Les preuves sont stockees de maniere securisee, chiffrees, et accessibles uniquement aux personnes autorisees. Le risque de ne pas avoir de preuves (et donc de ne pas détectér les vraies failles) est incomparablement superieur au risque de les generer.
Un rapport de vulnérabilité classique dit "cette faille existe potentiellement, elle a un score CVSS de X". Une preuve d'exploitation dit "j'ai exploite cette faille, voici exactement comment, voici les donnees auxquelles j'ai accede, et voici l'impact reel sur votre système". La première est une hypothese, la seconde est un fait demontre.
Absolument. Les pentests manuels de qualite produisent deja des preuves d'exploitation. L'approche par la preuve automatisée ne remplace pas les pentests manuels mais les complete en assurant une couverture continue entre les interventions manuelles ponctuelles. Les deux approches sont complementaires et se renforcent mutuellement.
Le ROI se mesure sur plusieurs axes : reduction du temps de remédiation (les equipes corrigent plus vite quand elles ont des preuves claires), reduction des faux positifs (moins de temps perdu sur des alertes non pertinentes), amelioration de la priorisation (les ressources sont concentrees sur les vrais risques), et valeur de conformité (les rapports base preuves satisfont directement les exigences réglementaires).
Jordan Fredj, Fondateur Hacksessible -
Demandez une demonstration pour voir comment les agents IA d'Hacksessible produisent des preuves concretes sur votre infrastructure.