Les modèles de pointe ont trouvé les vulnérabilités. Seul l’attaquant a trouvé les chaînes d’exploitation.

Les attaquants ne lisent pas votre dépôt : ils ciblent votre URL et enchaînent tout ce qu’ils y trouvent. À l’heure où l’IA offensive s’attaque aux applications en production à la vitesse machine, vos outils de sécurité doivent aller au-delà de la détection des vulnérabilités et prouver leur exploitabilité, notamment si elles peuvent être combinées pour provoquer une compromission.

Nous avons donc effectué un test. Nous avons soumis la même application, Evo Continuous Offensive Security (COS) et Claude Security exécutant Mythos : TaintedPort. Cette application web délibérément vulnérable met en œuvre des catégories de bugs réelles et un ensemble de chaînes d’exploitation répertoriées. Il s’agit d’outils de types différents : COS attaque l’application en cours d’exécution, tandis que les deux produits Claude analysent le code source. Nous les avons testés sur la même cible pour voir ce que chaque approche permet de démontrer.

Evo COS a confirmé 10 des 15 chaînes d’exploitation.

Il ne s’agit pas de dénigrer les modèles : nous les utilisons

Claude Security avec Mythos représente une véritable avancée dans la détection des vulnérabilités par l’IA. Il analyse le code source comme le ferait un excellent réviseur humain et détecte des catégories de failles qui échappent aux outils fondés sur la reconnaissance de motifs. Mais repérer une faille dans le code et prouver qu’un attaquant peut exploiter ces vulnérabilités sont deux tâches différentes.

Le chemin d’attaque démontré par COS

Tous les outils de ce test ont détecté la faille de falsification de requêtes côté serveur (SSRF) et constaté que le secret de signature JWT de l’application était codé en dur. Evo COS est allé plus loin : il a exploité la SSRF pour accéder au secret de signature dans l’application en cours d’exécution et le récupérer, puis s’en est servi pour générer un jeton d’administrateur valide et prendre le contrôle de l’interface d’administration. Deux constats, reliés pour former un chemin complet de prise de contrôle de compte, ont été démontrés sur l’application en production avec une preuve de concept exécutable.

Ci-dessus : CHAIN-004, évaluée par COS. Les deux constats qui la composent — la faille SSRF et le secret codé en dur — ont été signalés individuellement par tous les outils de ce test. Evo COS a confirmé qu’ils se combinent pour permettre la falsification d’un jeton d’administrateur.

Voilà à quoi ressemble concrètement une attaque autonome : obtenir un point d’appui, puis enchaîner les étapes à partir de là. Evo COS vous montre le chemin et fournit une preuve de concept exécutable pour chaque chaîne confirmée.

Les résultats

TaintedPort v1.35, évalué à l’aide d’un corrigé fixe répertoriant 57 vulnérabilités connues et 15 chaînes d’exploitation connues, selon une échelle pondérée par la gravité (Faible : 1, Moyenne : 3, Élevée : 9, Critique : 27 ; chaque chaîne confirmée est notée selon sa propre gravité, en plus des constats qui la composent). Le score de détection pondéré correspond aux points trouvés ÷ 938 points possibles : 587 pour les 57 vulnérabilités et 351 pour les 15 chaînes.

Claude Security a détecté une vulnérabilité critique de plus (10 contre 9). Evo COS a trouvé le plus grand nombre de vulnérabilités, obtenu la meilleure précision (96,2 % vs 90,2 %) avec moins de faux positifs, et a su identifier et démontrer des chaînes d’exploitation. 

Pourquoi attaquer l’application déployée ?

Evo COS est un système dynamique : sa cible est toujours une URL en production, le code source étant une entrée facultative qui fait passer l’exécution de la boîte noire à la boîte grise. Il ne fonctionne jamais uniquement sur le code. Claude Security a été exécuté en boîte blanche (code uniquement).

Il s’agit donc d’une comparaison entre disciplines : Evo COS réalise un test d’intrusion offensif qui sonde et exploite l’application en cours d’exécution, un processus fondamentalement plus approfondi qu’une simple analyse du code. C’est la complémentarité que le secteur connaît depuis toujours entre DAST et SAST. Nous montrons ici ce que l’analyse de l’application en production permet de démontrer, et ce que la seule lecture du code ne peut pas établir : que ces vulnérabilités sont réelles et qu’elles peuvent s’enchaîner.

Les constats signalés uniquement par Evo COS concernent majoritairement des comportements à l’exécution : réponses réfléchies ou mal configurées, protections de transport manquantes, jetons toujours valides après la déconnexion et gestion insuffisante des sessions. Evo COS a pu confirmer plusieurs failles de logique métier dépendantes du contexte : contrôle d’accès défaillant au niveau des objets lors de la mise à jour des profils, élévation de privilèges via des déclarations JWT falsifiées et faille critique où la simple lecture d’un secret TOTP stocké neutralise l’authentification à deux facteurs. Pour confirmer les chaînes, il faut franchir chaque étape dans l’application en cours d’exécution et vérifier que la suivante est réellement accessible. Un modèle qui analyse le code source doit déduire qu’une vulnérabilité peut être exploitée et peut passer à côté de la chaîne.

Vous pouvez créer un banc de test, mais pas le contexte

Le débat sur les évaluations comparatives de cette année a mis en lumière un point important : le système autour d’un modèle compte davantage que le modèle lui-même. Nous irions même plus loin. « Quel banc de test ? » n’est pas une question neutre ; c’est dans la réponse que réside le véritable avantage.

Evo COS orchestre plusieurs modèles, dont des modèles Claude de pointe, chacun étant affecté à la tâche pour laquelle il est le plus performant. Ce résultat ne raconte donc pas une histoire de qualité des modèles. La même catégorie de modèle qui alimente une revue de code de pointe est intégrée à Evo COS. Ce qui change, c’est le système qui l’entoure : Evo COS s’appuie sur les connaissances que la plateforme Snyk possède déjà sur la cible, au lieu de partir de zéro. Il mobilise un groupe d’agents, chacun orchestré à des fins précises, et chaque constat passe par une étape de validation indépendante avant d’être présenté, car le système qui génère un constat ne devrait pas être celui qui l’évalue.

N’importe qui peut connecter ce soir un modèle de pointe à un agent de programmation et le diriger vers un dépôt. Mais cette configuration ne peut pas reproduire le contexte accumulé et validé sur lequel Evo COS s’appuie, le validateur indépendant ni les tests sur l’application en production. 

Les tests dynamiques et statiques sont complémentaires

Claude Security a détecté plusieurs vulnérabilités qui ont échappé à Evo COS, principalement des failles de logique visibles dans le code source et des failles cryptographiques qui ne se manifestent pas toujours dans l’application en cours d’exécution. Aucune approche n’est complète à elle seule : c’est tout l’intérêt d’une plateforme plutôt que d’un outil ponctuel. Analyser le code et attaquer l’application en production permet à chaque approche de détecter ce que l’autre ne voit pas.

Méthodologie

TaintedPort est l’application délibérément vulnérable de Snyk, conçue et maintenue par notre équipe, et accessible au public. Evo COS n’a pas été ajusté spécifiquement pour elle.

Cible : TaintedPort : 57 vulnérabilités connues (34 courantes, 23 liées à la logique métier) et 15 chaînes d’exploitation connues.

Outils et entrées :

• Evo COS : boîte grise (URL en production + code source), 18 septembre.

• Claude Security : boîte blanche (code source), Mythos avec raisonnement étendu, 18 septembre.

Exécutions : une par outil. Les résultats correspondent aux sorties de cette exécution unique, et non à des médianes.

Détection par catégorie

Détection par gravité (détectées/connues)

Faux positifs et F1

Reproduisez le test : TaintedPort est disponible sur taintedport.com.

Vous souhaitez savoir quels constats dans vos applications peuvent s’enchaîner jusqu’à une compromission ? Découvrez comment Evo Continuous Offensive Security teste votre URL en production.