Continuous Offensive Security : la voie que nous suivons

Le pentest par IA connaît un moment fort.

En fait, plusieurs moments forts. Toutes les deux semaines, un autre fournisseur annonce quelque chose, ou un autre outil de pentest basé sur un LLM bat un record sur une cible dont personne n’a entendu parler. Une autre présentation prétend bouleverser un nouveau « standard de référence », enfin… C’est animé.

Mais sous tout ce bruit, il y a une vraie raison à ce phénomène qui se produit partout, en même temps : la même capacité de raisonnement qui vient de rendre le pentest par IA commercialement viable est désormais entre les mains des attaquants. Des attaquants autonomes sondent déjà les surfaces applicatives en continu, à la vitesse des machines, selon un rythme que les défenseurs ne peuvent pas suivre.

La véritable course consiste désormais à savoir si vos tests de sécurité offensive détecteront les failles avant l’IA offensive d’un attaquant. Les annonces des fournisseurs ne sont pas le véritable enjeu : elles montrent simplement que le marché rattrape un problème déjà bien réel.

Je travaille depuis plusieurs années sur Snyk API & Web, notre produit de tests de sécurité dynamique, et je me sens conforté dans mes convictions alors que Snyk annonce Continuous Offensive Security. Avec cet article, je veux faire autre chose que l’annoncer : expliquer pourquoi le chemin qui mène des tests de sécurité dynamique au pentest par IA est celui que nous parcourons depuis des années, et pourquoi toute personne qui essaie de créer le second sans s’appuyer sur les bases du premier atteindra rapidement un plafond, à mon avis.

Détectables par heuristique ou dépendantes du contexte

Voici la distinction fondamentale pour comprendre tout notre propos.

Les vulnérabilités détectables par heuristique sont celles que les outils déterministes savent déceler. Le SAST repère des motifs dans le code source lui-même, tandis que le DAST adopte une autre approche : il envoie des charges utiles à une application ou une API en cours d’exécution, puis observe les réponses : messages d’erreur, délais, différences de comportement, entre autres. Sonder, observer, déduire. Injection SQL, cross-site scripting, mauvaise utilisation des API, schémas classiques d’injection : tous ces problèmes se manifestent de façon fiable par des comportements que les heuristiques peuvent reconnaître. Les scanners et les outils DAST sont devenus très efficaces pour les détecter au fil des ans. Des centaines de catégories de vulnérabilités de ce type sont désormais détectées de façon fiable tout au long du cycle de développement logiciel, et c’est une vraie réussite. 

Les vulnérabilités dépendantes du contexte sont tout autre chose. BOLA ou IDOR, fuite de données entre locataires, contournements d’authentification et, surtout, vulnérabilités en chaîne, où plusieurs vulnérabilités moyennes et élevées se combinent pour former un chemin d’exploitation critique. Aucune ne présente de signature heuristique à rechercher. Impossible d’écrire une règle, en SAST ou en DAST, pour « l’utilisateur A ne devrait pas pouvoir lire la facture de l’utilisateur B » : cette règle dépend de ce que votre application est CENSÉE faire. La vulnérabilité se trouve dans l’écart entre le comportement prévu et le comportement réel ; aucune sonde, aucune charge utile, aucune signature ne peut déduire l’intention de l’extérieur.

C’est pourquoi les tests d’intrusion ont toujours été menés par des humains. Jusqu’à récemment, seuls les humains pouvaient acquérir la compréhension contextuelle nécessaire pour détecter cette deuxième catégorie. Les heuristiques repèrent des signatures ou des comportements ; les spécialistes des tests d’intrusion découvrent ce que seul le contexte révèle. Aussi percutante que cette formule puisse paraître, ce n’est pas un slogan : c’est ainsi que fonctionne cette discipline depuis ses débuts.

Et c’est précisément la limite que l’IA vient de franchir.

L’héritage qui compte vraiment

Voici un secret de polichinelle : au cours de la dernière décennie, tous les moteurs DAST dignes de ce nom ont été créés par des personnes issues des tests d’intrusion. Le moteur Snyk API & Web ne fait pas exception. L’équipe qui l’a conçu avait passé des années à trouver des failles manuellement, et l’a bâti autour des méthodes des spécialistes des tests d’intrusion : reconnaissance, sondage, observation, raisonnement, escalade, validation… toute la démarche. À l’époque, nous ne pouvions toutefois pas reproduire tout ce que font ces spécialistes. Il nous manquait le raisonnement, et c’est précisément ce que nous pouvons désormais faire, puisque les LLM comprennent le contexte et savent raisonner.

Cet héritage explique pourquoi notre détection de BOLA, lancée l’an dernier, fonctionne ainsi. Elle ne compare pas les résultats à une liste de signatures, car il n’existe pas de signature pour BOLA : elle enchaîne des sondes d’autorisation, guidées par un raisonnement structurel sur les liens entre les objets d’API et les identités. Cette recherche automatisée de failles franchit le seuil entre « Que fait le code ? » et « Que devrait-il faire, et puis-je détourner cette intention ? »

Elle fonctionne en production pour nos clients depuis des mois. C’est la preuve que le passage du DAST aux tests fondés sur le raisonnement est possible. Et ce n’est pas un hasard si nous réfléchissions à la création de la version IA depuis bien avant que le « pentest par IA » ne devienne une catégorie attirant les investissements.

Ce qui a changé, et pourquoi maintenant

Ce qui a changé, ce n’est pas l’objectif, mais le coût.

À grande échelle, le raisonnement exigeait auparavant l’intervention d’un spécialiste des tests d’intrusion. Entre 20 000 et 50 000 $ par mission. Deux semaines de calendrier en moyenne. Une fenêtre de couverture qui se refermait dès la remise du rapport ; à ce stade, l’application avait déjà connu trois nouvelles versions.

C’était la réalité des tests d’intrusion manuels : irremplaçables, mais limités par la même contrainte que tout travail artisanal : le temps humain. Vos tests d’intrusion couvrent quinze jours par an. Que se passe-t-il pendant les trois cent cinquante autres ?

L’IA change la donne, mais pas la discipline. L’étape de raisonnement que seul un spécialiste des tests d’intrusion pouvait réaliser est désormais à la portée d’un modèle suffisamment performant, de façon répétable et pour une fraction du coût.

Et l’IA a créé une troisième surface d’attaque

Tout ce qui précède concerne une surface d’attaque qui existe depuis aussi longtemps que les applications web : les vulnérabilités détectables par heuristique et celles qui dépendent du contexte, dans le code, les API et les architectures traditionnels. L’IA change le modèle de test, mais pas les cibles : elles font l’objet de tests d’intrusion depuis vingt ans.

Il existe aussi une surface d’attaque entièrement nouvelle, créée par l’IA elle-même, qui n’existait pas il y a seulement cinq ans.

Des applications intégrant des LLM, des agents IA qui appellent des outils, des chatbots connectés aux données clients. Des pipelines de récupération qui extraient des données de sources qu’un attaquant peut empoisonner, des injections de prompt ou des usages détournés. L’exfiltration de données via les réponses d’un modèle, ou encore des jailbreaks qui transforment un agent du service client en acteur privilégié, avec des accès qu’il n’aurait jamais dû avoir. L’article de Manoj décrit un cas de figure : un agent IA appelle une API qui n’avait jamais été soumise à des tests de résistance, après avoir reçu un simple e-mail.

Ces attaques ne se détectent pas par un scan et ne constituent pas des failles au sens architectural traditionnel. Elles se trouvent dans l’écart entre ce qu’un LLM a reçu comme instruction et ce qu’un attaquant peut le convaincre de faire. Pour les détecter, il faut agir contre la couche intégrant le LLM comme le ferait un attaquant : sonder, escalader, exfiltrer, exploiter.

C’est la troisième capacité de Continuous Offensive Security : le red teaming d’agents. Une simulation adversariale en plusieurs étapes, ciblant les LLM, les agents IA et les outils qu’ils appellent. Un outil conçu spécifiquement pour la surface d’attaque créée par l’IA.

J’apprécie particulièrement son fonctionnement : il ne s’agit ni d’un scan distinct à planifier, ni d’un produit supplémentaire à acheter. Pendant une évaluation, l’agent de reconnaissance détecte si la cible comprend des composants intégrant un LLM. Le cas échéant, le module de red teaming se déclenche automatiquement. Vous n’avez pas besoin de savoir à l’avance quelle surface d’attaque votre application présente : le système l’identifie et lance les tests adaptés sur la bonne couche.

C’est plus important qu’il n’y paraît. Aujourd’hui, la plupart des organisations utilisent l’IA dans une partie de leur portefeuille d’applications, mais leurs équipes de sécurité n’en ont pas une vision claire. Commencer par la reconnaissance, puis tester ce que l’on trouve, est le seul modèle capable de passer à l’échelle lorsque « Où l’IA est-elle utilisée en production ? » est une cible en constante évolution.

Voilà donc la surface d’attaque : les failles des architectures traditionnelles et le nouveau terrain créé par l’IA. La question la plus difficile est de savoir ce qu’il faut pour mener efficacement des tests de sécurité offensive sur ces deux fronts, en continu et à l’échelle de l’entreprise. Diriger un LLM vers une URL cible et le laisser se débrouiller sans aucun contexte n’est pas la solution. Quatre éléments font toute la différence.

Contexte de la plateforme

L’approche naïve du pentest par IA consiste à repartir de zéro. Diriger le LLM vers une URL, le laisser explorer, faire des suppositions, gaspiller des ressources de calcul à énumérer des éléments sans importance, en espérant qu’il finisse par trouver quelque chose. Pire encore : il ne peut pas faire la différence entre une découverte théorique et une faille réellement exploitable dans votre environnement, car il ne voit ni votre code, ni vos dépendances, ni vos scans précédents, ni votre environnement de déploiement, ni vos frontières de confiance. Voilà le cycle d’une démo, mais ce n’est pas ainsi que devraient fonctionner des tests de sécurité en production.

La solution de Snyk est différente. Continuous Offensive Security s’appuie sur tout ce que la plateforme sait déjà de votre application : les résultats du SAST, les dépendances analysées par la SCA, les inventaires d’actifs, les scans DAST précédents et les indicateurs de risque issus de toute la plateforme. Toutes ces informations alimentent le testeur d’intrusion IA avant même qu’il envoie sa première requête.

Cela change la façon dont l’IA travaille dès le premier jour. Au lieu de lui dire « Découvre ce qu’est cette application et trouve des vulnérabilités, », on lui donne plutôt les instructions suivantes : « Cette application comprend ces composants, ces dépendances, ces résultats antérieurs, ces points de terminaison accessibles et ce profil de risque. À vous de trouver ce qui n’a pas encore été couvert. » Le LLM cesse de deviner et se met au travail.

Comme nous l’avons annoncé cette semaine : « Snyk se distingue parce que nous connaissons déjà votre code. » En sept mots, tout l’argument de la plateforme est là. Tous les autres outils de pentest par IA partent de zéro ; nous reprenons là où vos outils existants se sont arrêtés.

C’est aussi pour cette raison que je ne pense pas que les solutions spécialisées de ce secteur aient un long avenir : impossible d’ajouter cette couche à un produit tout neuf. Elle nécessite une décennie de contexte accumulé par des moteurs qui détectent de véritables vulnérabilités chez de vrais clients.

Tests dynamiques hybrides et détection par LLM

C’est le point technique que la plupart des nouveaux acteurs passent sous silence, et je pense que nombre d’entre eux vont peiner lorsque leur budget de financement et leurs factures de tokens se rejoindront.

L’approche naïve, une fois encore, pour créer un pentest par IA consiste à utiliser uniquement un LLM : le diriger vers la cible et le laisser tout découvrir. Ça fonctionne dans les démos, mais pas dans un modèle économique viable.

Chaque charge utile envoyée par un LLM à un point de terminaison XSS coûte des tokens. Chaque paramètre testé par force brute, chaque variante, chaque nouvelle tentative ? Des tokens, encore des tokens. Les tests dynamiques font tout cela de façon exhaustive et déterministe, pour quelques centimes. Gaspiller des tokens de modèles de pointe sur un catalogue de bugs, c’est ce que signifie « vendre à perte grâce aux subventions » ; les fournisseurs qui misent là-dessus découvriront ce que sont les coûts unitaires le jour où ils devront être rentables.

Le modèle architecturalement le plus judicieux n’est pas de faire fonctionner deux couches en parallèle, mais d’avoir un LLM qui joue le rôle de cerveau de l’évaluation, avec les tests dynamiques parmi les outils à sa disposition. Pour vérifier la présence de XSS, d’injection SQL ou de mauvaises configurations, le LLM ne répertorie pas lui-même les charges utiles : il fait appel aux tests dynamiques, qui s’en chargent de façon exhaustive et déterministe, pour quelques centimes, depuis des années.

Le LLM peut ainsi consacrer ses tokens à ce qu’il est le seul à pouvoir faire : raisonner sur la logique métier, détecter les failles d’autorisation et relier les résultats individuels pour tracer de véritables chemins d’exploitation. C’est là que se concentre la majeure partie de la puissance de calcul. Les scénarios déjà bien connus sont traités de manière déterministe, tandis que toute la puissance de calcul nécessaire est consacrée au raisonnement.

Cette architecture est en place depuis le premier jour ; ce n’est pas un objectif que nous cherchons à atteindre. C’est pourquoi, à mon avis, développer cette solution sans moteur de test de sécurité dynamique sous-jacent est bien plus difficile qu’il n’y paraît de l’extérieur.

Des récits d’attaque, pas des listes d’alertes

Un scanner traditionnel produit une liste de vulnérabilités classées par score de gravité, accompagnées de traces de pile ou de requêtes HTTP. Depuis plusieurs années, les équipes de sécurité croulent sous ces listes. CVSS 9,8, puis CVSS 9,6, puis CVSS 9,4… et quelque part au milieu, un véritable chemin d’exploitation qui en combine deux avec une troisième vulnérabilité de faible gravité, écartée par l’équipe lors du triage il y a plusieurs mois.

Les vulnérabilités dépendantes du contexte que j’ai décrites plus haut apparaissent presque jamais comme des résultats isolés ; elles se présentent sous forme de combinaisons : une lacune d’autorisation sur un point de terminaison, une faille logique dans la manière dont l’API attribue les identifiants et une session obsolète que la tâche de nettoyage a manquée. Pris isolément, ces trois résultats semblent anodins, mais combinés, ils peuvent provoquer une fuite de données.

Continuous Offensive Security ne présente pas les résultats sous forme de liste. Il les présente sous forme de chaînes d’exploitation : le chemin réel, de l’accès initial à l’impact, accompagné des traces de requêtes et de réponses à titre de preuve. Le tout est reproductible et vérifiable. C’est le récit de ce qu’un attaquant pourrait réellement faire à cette application, et non un tableur de 400 lignes qu’il faut trier un vendredi après-midi.

Colleen Carroll, directrice principale et responsable de la sécurité de l’information chez Emburse, a exprimé ce point de vue côté clients dans notre annonce :

« Les équipes de sécurité recherchent des solutions qui les aident à hiérarchiser les risques réels, et pas simplement à gérer davantage d’alertes. Continuous Offensive Security de Snyk leur offre une meilleure visibilité sur les vulnérabilités exploitables et leurs enchaînements, ce qui leur permet d’agir plus rapidement, de réduire leur exposition et de soutenir l’innovation en toute confiance. »

C’est toute la différence entre « Voici ce que nous avons trouvé » et « Voici comment cela peut être utilisé contre vous. »

Environnement sécurisé pour l’IA en entreprise

Le travail d’ingénierie considérable, qui fait rarement la une, consiste à exécuter des agents d’IA de manière responsable sur des systèmes situés à un saut réseau de la production.

Gouvernance, respect du périmètre, maintien du contexte lors d’opérations de longue durée et reproductibilité, afin de pouvoir valider et réexaminer les résultats. Traces de raisonnement, pour que les équipes de sécurité puissent vérifier comment une conclusion a été obtenue. Toute cette couche transforme « un LLM qui fait des essais » en un outil qu’une équipe de sécurité d’entreprise peut réellement utiliser pour tester une application.

Nous appelons cela l’AI Security Harness. C’est la composante de Continuous Offensive Security qui se trouve sous le capot. C’est aussi là que réside la majeure partie de la difficulté. Et là encore, l’expérience compte. Développer cette couche est plus difficile que de concevoir l’IA qui s’appuie dessus. Les organisations qui réalisent des tests d’intrusion et des tests de sécurité dynamique à l’échelle de l’entreprise depuis des années ont une avance considérable sur celles qui se lancent à peine.

C’est aussi là que nous avons fait un choix d’architecture délibéré que les autres solutions ne peuvent pas facilement reproduire : Continuous Offensive Security ne repose pas sur un modèle de pointe unique. L’AI Security Harness orchestre plusieurs modèles de pointe, des modèles de niveau défenseur ainsi que d’autres modèles ouverts et propriétaires, dont les paramètres sont affinés au fil du temps. Pour nous, il s’agit d’un choix d’architecture qui définit la conception d’un système d’IA de qualité entreprise.

Continuous Offensive Security exécute un système de sécurité offensive multi-modèle spécialement conçu pour les tests d’intrusion en entreprise. Les modèles de pointe réalisent l’évaluation à l’aide du cadre offensif de Snyk ; un modèle de validation dédié joue le rôle d’évaluateur indépendant et confirme l’exploitabilité avant la présentation de tout résultat ; et l’intelligence de la plateforme Snyk ancre chaque attaque dans le contexte réel de l’application. Le résultat : un système conçu pour privilégier la précision plutôt que le bruit.

Les prochaines étapes

Gabriel Brolo, ingénieur principal en sécurité chez Yalo, l’a récemment formulé plus clairement que je ne saurais le faire :

« Le volume et le rythme du code généré par l’IA ont fondamentalement dépassé les capacités du modèle de tests d’intrusion que la plupart d’entre nous utilisons depuis des années. Nous ne pouvons pas résoudre un risque continu en multipliant les planifications. Il nous faut des tests offensifs qui suivent le rythme de notre façon actuelle de développer des logiciels, avec suffisamment de contexte pour se concentrer sur ce qui est réellement exploitable, et pas seulement sur ce qui est théoriquement possible. Cette capacité permettra aux équipes de mieux comprendre leur paysage de menaces et leurs risques réels, afin de mieux les atténuer. »

Pour les clients de Snyk API & Web, Continuous Offensive Security n’est pas un achat distinct : c’est la couche suivante du même parcours de tests externes que couvre déjà votre solution de tests de sécurité dynamique. Le scanner détecte les problèmes décelables par heuristique, l’IA couvre ceux qui dépendent du contexte, et le Red Teaming couvre la surface d’attaque propre à l’IA dès que la reconnaissance détecte un LLM dans la pile technologique. La même approche de sécurité, étendue à la réalité des composants de vos applications d’aujourd’hui.

Pour le marché, la question n’est plus « Avez-vous besoin de tests d’intrusion par l’IA ? » (et, eh bien, nous pensons que oui), mais « Quelle solution de tests d’intrusion par l’IA choisir ? »

Alors que nous annonçons enfin Continuous Offensive Security cette semaine, nous voulons que les clients qui évaluent aujourd’hui des solutions de tests d’intrusion par l’IA, comparent les options, assistent à des démonstrations et cherchent à savoir à qui faire confiance, sachent que l’une des réponses vient de ceux qui sont présents depuis le tout début, bien avant que tout cela ne prenne forme.

Si vous avez lu l’article de Manoj sur la surface d’attaque créée par l’IA et mon précédent article sur l’évolution nécessaire des tests dynamiques pour suivre le rythme, voici le troisième volet. Le lien est maintenant évident. Il a toujours existé, et nous le laissions entrevoir depuis le début.

Nous vous en dirons davantage à Black Hat. Au plaisir de vous y retrouver !