Skip to main content

Evo Continuous Offensive Security est disponible : une couverture de pentest de niveau expert pendant les 350 jours sans test

Écrit par
snyk evo cos pr

4 août 2026

0 minutes de lecture

À Black Hat USA 2026, Snyk rend Evo Continuous Offensive Security accessible à tous : des tests d’intrusion autonomes propulsés par l’IA qui comblent l’écart entre vos tests annuels ou bisannuels et les 350 jours par an pendant lesquels les attaquants ne s’arrêtent jamais. COS est le nouvel atout d’une défense unifiée, conçu pour répondre à la question que tous les conseils d’administration se posent désormais : comment nous préparer aux attaques autonomes par l’IA ?

Ce n’est plus une nouveauté : l’IA a profondément transformé la façon dont les logiciels sont conçus. Le code qui prenait autrefois des jours à livrer ne demande plus que quelques minutes, et nous profitons tous des assistants de codage IA et, de plus en plus, d’agents autonomes qui travaillent à nos côtés. Mais cette grande puissance s’accompagne d’une grande responsabilité : gérer cette accélération, qui confronte les équipes de sécurité à une réalité qu’elles commencent tout juste à mesurer. La surface d’attaque s’est considérablement étendue, tandis que les attaquants disposent désormais de la même IA capable de raisonner que les développeurs utilisent pour accélérer leur travail.

La prise de conscience tient aussi au fait que la surface d’attaque couvre désormais trois fronts à la fois : les failles architecturales que seuls des systèmes capables de raisonner peuvent détecter, les identifiants qui s’échappent du code généré par l’IA, ainsi que les modèles et agents désormais intégrés directement au cycle de développement. Et les adversaires sondent maintenant ces trois fronts simultanément, à la vitesse des machines.

En juin, l’alliance Five Eyes a averti que l’IA pourrait dépasser les capacités actuelles de cybersécurité en quelques mois, et non en plusieurs années, le temps d’intrusion des adversaires se mesurant désormais en secondes. Gartner prévoit que le délai d’exploitation sera réduit de moitié d’ici 2027. Les dernières recherches de Snyk sur l’adoption de l’IA en entreprise racontent la même histoire, mais de l’intérieur : le développement agentique s’accélère plus vite que les programmes de sécurité ne peuvent le suivre. Pour se défendre, il faut quatre éléments, pas un seul.

Aujourd’hui, à Black Hat USA 2026, Snyk répond à cette évolution en proposant l’extension la plus importante à ce jour de la Snyk AI Security Platform. Pas avec une suite de produits, mais avec une défense unifiée organisée autour des quatre étapes nécessaires aux organisations pour innover en toute sécurité : découvrir l’ensemble de la surface d’attaque, corriger le backlog hérité, valider ce qu’un attaquant peut réellement exploiter et prévenir l’apparition de nouveaux risques.

À la tête de cette initiative : la disponibilité générale d’Evo Continuous Offensive Security (COS), des tests d’intrusion autonomes propulsés par l’IA qui suivent le rythme du développement accéléré par l’IA. Snyk annonce également une gestion améliorée de la posture de sécurité de l’IA, un premier aperçu d’Evo Agentic Application Security et la disponibilité générale de Snyk Secrets. Ensemble, ces solutions sécurisent l’intégralité du cycle de vie des logiciels développés avec l’IA : leur conception, leurs composants et les attaques dont ils font l’objet.

Une défense unifiée : découvrir, corriger, valider, prévenir

Face à des attaquants qui raisonnent désormais sur votre application à la vitesse des machines, pour le prix de quelques jetons, une défense unifiée est indispensable :

  • Découvrir : visualisez l’ensemble de la surface d’attaque logicielle et IA : modèles, agents, serveurs MCP, compétences, outils et ressources auxquelles chacun peut accéder. Cette première étape est assurée par AI-SPM, l’AI-BOM et la Snyk AI Security Platform.

  • Corriger : résorbez le backlog hérité avant que les attaquants autonomes ne le parcourent plus vite que les équipes ne peuvent réagir. Cette étape est assurée par l’intelligence applicative de Snyk et la correction autonome.

  • Valider : attaquez vos applications en continu pour vérifier que les correctifs tiennent, voir ce qui reste exploitable et révéler les failles architecturales et de logique métier qu’aucun scanner ne détecte. Cette étape est assurée par Evo COS.

  • Prévenir : empêchez les secrets, les packages malveillants et les nouvelles vulnérabilités de reconstituer le backlog, à mesure que les humains et les agents écrivent du code. Cette dernière étape est assurée par Snyk Secrets, les contrôles préventifs et la défense contre le code malveillant.

Comme Snyk comprend déjà le code, les dépendances, les API, les composants d’IA et le contexte de développement, chaque capacité renforce les autres au lieu d’ajouter un outil de plus, sans lien avec les autres. C’est ce qui distingue une plateforme d’une suite de produits.

Le problème : les attaquants sont remontés dans la pile technologique, mais les tests n’ont pas suivi

Depuis plus de vingt ans, une distinction s’impose en sécurité applicative : les scanners détectent les bugs au niveau de l’implémentation, tandis que les pentesteurs humains trouvent les failles architecturales. Les scanners automatisés sont devenus réellement excellents dans la première catégorie : ils détectent les injections SQL, les scripts intersites, les mauvaises configurations, ainsi que les classes d’injection et de modèles visibles dans le code. Des centaines de classes de vulnérabilités sont désormais détectées de manière fiable tout au long du cycle de vie logiciel. C’est une avancée concrète et durable, qui n’est pas près de disparaître.

Mais les attaquants sont remontés dans la pile technologique, vers les failles de conception qui exigent de comprendre ce qu’une application est conçue pour faire avant de pouvoir l’exploiter. Ces failles résident dans les relations de confiance d’un système, et non dans son code ; elles ne présentent donc aucune signature à rechercher par un scanner. Voici à quoi elles peuvent ressembler :

  • En 2019, First American a exposé environ 885 millions de documents financiers. L’incident n’a pas été causé par un logiciel malveillant ou une faille zero-day, mais par la modification d’un seul chiffre dans une URL. Tous les scanners n’ont rien détecté, et l’application a fait exactement ce que son code lui demandait. Elle n’aurait simplement pas dû permettre à un client de consulter les documents d’un autre.

  • En janvier 2026, des chercheurs ont révélé BodySnatcher (CVE-2025-12420, CVSS 9.3) : une simple adresse e-mail suffisait pour usurper l’identité de n’importe quel administrateur ServiceNow et prendre le contrôle des agents IA de la plateforme. Aucun mot de passe n’a été piraté, aucun code d’exploitation n’a été utilisé. Le problème venait simplement d’une conception qui accordait sa confiance au mauvais élément.

Voici les types de failles que les attaquants exploitent aujourd’hui : les défauts d’autorisation au niveau des objets (BOLA) et les élévations de privilèges par manipulation d’identifiants, les fuites interlocataires qui exfiltrent les données des clients et les attaques en chaîne contre la logique métier, où plusieurs problèmes de faible gravité se combinent pour permettre la prise de contrôle d’un compte. Dix ans de vulnérabilités mineures ou modérées laissées en sommeil, auxquels s’ajoute chaque nouvelle découverte, sont désormais exploitables et combinables à la vitesse des machines. Et il est impossible d’écrire une règle de scanner du type « l’utilisateur A ne doit pas pouvoir consulter la facture de l’utilisateur B », car cette règle dépend entièrement du comportement attendu de l’application.

La détection de ces failles a toujours exigé un raisonnement humain, et donc un test d’intrusion manuel. Ces tests restent irremplaçables, mais sont limités par le temps dont disposent les humains. Une mission classique dure 15 jours et coûte entre 20 000 et 100 000 dollars, tout en ne capturant qu’un instantané. La couverture prend fin dès la livraison du rapport ; d’ici là, l’application a déjà connu plusieurs nouvelles versions. Votre test d’intrusion couvre environ 15 jours par an. Que se passe-t-il pendant les 350 autres jours ? Le développement ne s’arrête pas, pas plus que les attaquants. Chaque version livrée pendant cette période n’est pas testée précisément au niveau où se trouvent les risques les plus importants.

L’IA change les règles du jeu, pas la discipline

Voici ce qui a réellement changé. L’étape de raisonnement, que seul un pentesteur humain pouvait réaliser — modéliser l’intention d’une application, puis trouver comment la détourner — peut désormais être exécutée de façon reproductible par un modèle suffisamment performant, à une fraction du coût. La discipline reste la même, mais son modèle économique, lui, a bel et bien changé.

Les preuves sont déjà publiques et à grande échelle. Au cours de l’année précédant la mi-2026, les rapports de vulnérabilités valides générés par l’IA et transmis à HackerOne ont augmenté de 210 %, et les rapports d’injection de prompt de 540 %. Cette hausse concerne précisément les failles qui nécessitent un raisonnement et échappent aux scanners. La limite du raisonnement, qui a tenu pendant vingt ans, ne s’est pas érodée progressivement : elle a disparu en une génération de modèles.

Le corollaire particulièrement inquiétant, c’est que les attaquants ont franchi la même limite au même moment, et qu’ils opèrent déjà de bout en bout. Dans une campagne de cyberespionnage parrainée par un État, révélée fin 2025, jusqu’à 90 % des opérations ont été exécutées par l’IA plutôt que par des pirates humains (Anthropic Threat Intelligence, novembre 2025).

La question n’est plus de savoir si l’IA peut trouver et exploiter les failles que les scanners ne détectent pas, mais si vos tests de sécurité offensive les trouvent avant les attaquants.

Evo Continuous Offensive Security est désormais disponible

Nous avons développé Evo Continuous Offensive Security pour combler précisément cette lacune. Cette capacité de tests d’intrusion propulsée par l’IA s’appuie sur un environnement d’IA de niveau entreprise, capable de raisonner sur l’intention des applications afin de révéler les failles architecturales et les vulnérabilités de logique métier que les scanners traditionnels ne détectent pas. Et elle fonctionne en continu, pas une fois par an.

Point essentiel : COS ne teste pas à l’aveugle. Comme il fait partie de la Snyk AI Security Platform, il exploite le contexte des résultats existants de Snyk Code, Snyk Open Source et Snyk API & Web, ainsi que d’Evo AI-SPM, qui apporte des informations supplémentaires pour tester les applications natives de l’IA.. Il peut ainsi orienter son raisonnement vers les failles que ces outils ne détectent pas, plutôt que de consacrer de coûteux cycles de calcul à redécouvrir des vulnérabilités déjà identifiées. Comme le dit notre équipe : si un bug vaut 1 $ et une faille 100 $, pourquoi consacrer du temps aux tests d’intrusion à redécouvrir des bugs à 1 $ ?

Cette capacité s’appuie sur trois composants intégrés qui forment un programme de sécurité offensive continu : un raisonnement ciblé là où il compte, une couverture exhaustive là où elle est utile, le tout spécialement conçu pour la nouvelle surface d’attaque de l’IA :

  • Raisonner comme un attaquant - tests d’intrusion par l’IA constitue le cerveau de COS. Il définit lui-même le périmètre, planifie une attaque en plusieurs étapes et vérifie si elle est exploitable. Il orchestre les agents spécialisés et chaque outil de l’environnement afin de déceler les failles architecturales et les détournements de la logique métier qui échappent aux scanners et aux testeurs manuels. Chaque vulnérabilité confirmée est accompagnée d’une preuve de concept exécutable : une preuve, pas une description.

  • Mettre à l’épreuve la couche IA avec une équipe rouge - Agent Red Teaming est conçu spécifiquement pour la couche agentique des applications d’IA. Il intervient dès que la reconnaissance détecte un LLM dans la pile technologique. Il simule la chaîne d’attaque réelle : prompt utilisateur --> injection de prompt --> abus des outils et des agents --> exfiltration des données, en ciblant les injections de prompt, l’exfiltration et le détournement d’objectifs, que les signatures ne peuvent pas détecter.

  • Couvrir les classes de vulnérabilités courantes - tests dynamiques (DAST) offre une couverture exhaustive et hautement déterministe de chaque point de terminaison et point d’injection pour les classes courantes, comme les XSS, les injections SQL et les mauvaises configurations, avec un taux de faux positifs de 0,08 %. Plutôt que de consacrer des cycles à valider des bugs courants, la couche de raisonnement l’utilise comme un outil : l’IA peut ainsi se concentrer sur les failles, et non sur leur triage.

Les résultats ne se présentent pas sous la forme d’une simple liste d’alertes sans lien entre elles. Ils apparaissent comme des chaînes d’exploitation connectées, qui montrent comment une lacune d’autorisation et une faille de logique se combinent pour créer un chemin d’attaque à fort impact — à l’image du raisonnement d’un véritable attaquant face à votre système.

COS répond directement au problème de confiance qui compromet les approches naïves : la même IA ne peut pas être chargée à la fois de détecter une faille et de la confirmer. Le générateur ne peut pas être son propre validateur. Demander à un modèle de certifier ses propres résultats crée un conflit d’intérêts structurel et produit des résultats incohérents. Chaque résultat de COS est donc examiné par un juge de validation indépendant avant d’être présenté, ce qui permet d’obtenir un taux de faux positifs extrêmement faible, contre environ 30 % pour les outils d’IA bruts. Le résultat est ensuite accompagné d’une preuve de concept exécutable et de la trace complète du raisonnement : votre équipe ne reçoit pas une alerte qu’elle doit croire sur parole, mais un exploit qu’elle peut réellement exécuter.

C’est là que réside la véritable différence, et il est important de le préciser : un modèle performant n’est pas un test d’intrusion. Tout repose sur le système, pas sur le modèle : c’est le cadre d’IA d’entreprise qui entoure le raisonnement qui rend les tests offensifs autonomes fiables. Il s’appuie sur un contexte et une mémoire persistants d’une exécution à l’autre, une exécution contrôlée et une gouvernance qui garantissent la sécurité des tests dans des environnements proches de la production, la reproductibilité et l’intelligence de la plateforme qui alimente chaque évaluation. Les solutions ponctuelles repartent de zéro à chaque exécution, sans mémoire, sans contexte de plateforme ni gouvernance. C’est cette lacune que le cadre vient combler.

Tout aussi important, COS ne remplace pas les moteurs de sécurité que vous utilisez : il les complète. Les scanners continuent de couvrir les catégories de problèmes au niveau de l’implémentation pour lesquelles ils excellent, les testeurs humains se consacrent aux tâches qui exigent le plus de discernement, et COS prend en charge la couche continue qui repose sur le raisonnement, entre les deux, en validant à nouveau la sécurité chaque fois que votre application évolue.

Une défense complète : découvrir, corriger, prévenir

La validation est le point culminant, mais elle n’est qu’une étape d’une boucle, et la solidité de cette boucle dépend de tous ses éléments. COS ne peut prouver que ce qu’un attaquant pourrait exploiter, car la plateforme qui l’entoure découvre toute la surface d’attaque qu’il teste, résorbe le backlog dans lequel un attaquant pourrait autrement s’engouffrer et empêche de nouveaux risques de s’accumuler plus vite que vous ne pouvez les tester. Trois annonces viennent boucler la boucle, et chacune renforce COS.

Découvrir – Gestion améliorée de la posture de sécurité de l’IA

Découvrir (AI-SPM) : la découverte oriente COS vers les bonnes cibles et, de plus en plus, lui fournit les données nécessaires : les signaux AI-BOM et AI-SPM dont COS se sert pour tester les applications natives de l’IA.

Impossible de gouverner ce que l’on ne voit pas, et la plupart des organisations ne voient toujours pas la couche où se concentrent désormais les risques liés à l’IA. Snyk déploie une mise à niveau majeure de son renseignement sur les risques lié à la gestion de la posture de sécurité de l’IA (AI-SPM) : une taxonomie des risques liés aux modèles et un moteur de notation entièrement remaniés, ainsi qu’une nouvelle analyse des risques associés aux skills et aux serveurs MCP, directement intégrée à l’AI-BOM. Résultat : vous voyez précisément avec quoi vos agents interagissent — chaque modèle, skill et serveur MCP utilisé — et disposez d’une évaluation plus précise et plus défendable des risques associés à chacun. Comme le montre clairement une nouvelle étude de Snyk, l’empreinte réelle de l’IA d’une organisation est bien plus vaste que ne le laisse supposer son inventaire de modèles, et la plupart des programmes de gouvernance n’en ont toujours aucune visibilité. Cette amélioration comble cette lacune.

Corriger – Evo Agentic AppSec : un premier aperçu des prochaines nouveautés

Corriger (Agentic AppSec) : la correction transforme une vulnérabilité détectée par COS en risque résolu, plutôt qu’en ticket supplémentaire.

Snyk propose également un premier aperçu d’Evo Agentic Application Security, sa vision de la sécurité applicative autonome, où l’AppSec ne se contente plus de détecter les problèmes, mais les corrige et s’en défend de façon autonome. Au cœur de cette vision : la préversion publique de l’agent de correction de Snyk, disponible via la CLI et ADE. Il corrige automatiquement les vulnérabilités au lieu de remettre aux développeurs un backlog à trier, et s’accompagne d’un premier aperçu d’un nouvel agent de détection des malwares, conçu pour repérer le code malveillant avant sa mise en production. C’est la voie que prend la discipline, et le début du prochain chapitre de la plateforme.

Prévenir – Snyk Secrets est désormais disponible

Prévenir (Snyk Secrets) : la prévention évite à COS de détecter à nouveau les mêmes problèmes au prochain trimestre.

Enfin, Snyk Secrets, une solution de détection et de prévention des secrets conçue pour le cycle de développement agentique (ADLC), est désormais disponible. Le code généré par l’IA a fait des identifiants divulgués un problème majeur. Snyk Secrets s’appuie sur un moteur propriétaire de détection par machine learning qui analyse le contexte autour de chaque secret potentiel afin de réduire les faux positifs, et met en place des barrières de prévention dans les agents de codage IA, les IDE, les pull requests et les pipelines CI/CD. C’est une solution tout indiquée pour sécuriser le développement logiciel agentique : elle empêche les identifiants d’atteindre la production tout en permettant aux développeurs de continuer à avancer.

« 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 utilisions depuis des années. Il est impossible de planifier pour maîtriser une surface de risque en constante évolution. Nous avons besoin de tests offensifs capables de suivre le rythme auquel nous développons réellement des logiciels aujourd’hui, avec un contexte suffisant pour nous concentrer sur ce qui est véritablement exploitable, et non sur ce qui est seulement possible en théorie. », Gabriel Brolo, ingénieur principal en sécurité, Yalo

Pourquoi est-ce important ?

Prenons un peu de recul : ces quatre annonces défendent une même idée. L’IA a accéléré toutes les étapes de la création logicielle et, ce faisant, a étendu la surface d’attaque à l’ensemble du cycle de vie : le code écrit par l’IA, les identifiants et les composants utilisés pour le créer, les modèles et agents qui y sont intégrés, ainsi que l’application en cours d’exécution qu’un adversaire cherche à sonder. Les outils ponctuels et les tests réalisés à un instant donné ont été conçus pour un monde plus lent et plus linéaire. Sécuriser les logiciels accélérés par l’IA, c’est les tester comme ils sont développés et attaqués aujourd’hui : en continu, avec le contexte de toute la plateforme et des résultats fiables, car le modèle qui a détecté la faille n’est pas celui qui l’a évaluée.

Sécuriser l’ensemble du cycle de vie des logiciels accélérés par l’IA, c’est donc sécuriser leur mode de développement, les éléments qui les composent et la façon dont ils sont attaqués.

Disponibilité

Evo Continuous Offensive Security et Snyk Secrets sont désormais disponibles. Les fonctionnalités améliorées d’AI-SPM sont dès à présent accessibles aux clients existants. L’agent de correction d’Evo Agentic AppSec est en préversion publique via la CLI Snyk, tandis que l’agent de détection de code malveillant est en préversion privée. Réservez une démo pour en savoir plus sur Evo dès aujourd’hui.

Webinaire à la demande

OpenAI a corrigé sa propre copie, puis a compromis un environnement de production

Regardez le webinaire à la demande pour comprendre pourquoi l’auto-validation échoue par nature, pourquoi une architecture multi-modèle aggrave le problème et à quoi ressemble une validation indépendante en pratique. Repartez avec un cadre pour gouverner chaque ressource d’IA dans votre environnement, quel que soit le laboratoire qui l’a développée.

Lire la suite

Blog

Snyk UNFILTERED : dans les coulisses de notre tout premier sommet clients

Lors du premier sommet clients de Snyk, des responsables de la sécurité ont partagé sans détour leurs points de vue sur les risques liés à l’IA, la correction des vulnérabilités et la gouvernance des agents autonomes. Cinq thèmes révèlent comment les équipes adaptent la sécurité au rythme de l’IA.