Skip to main content

Evo Continuous Offensive Security est là : une couverture de pentest digne de ce nom 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 annonce la disponibilité générale d’Evo Continuous Offensive Security : un pentest autonome propulsé par l’IA qui comble le fossé entre vos pentests annuels ou semestriels et les 350 jours pendant lesquels les attaquants ne s’arrêtent jamais. COS est le nouvel atout d’une défense unifiée, conçue pour répondre à la question que tous les conseils d’administration posent désormais : comment nous préparer aux attaques autonomes menées par l’IA ?

Ce n’est plus une nouveauté : l’IA a profondément transformé le développement logiciel. Le code qui prenait autrefois des jours à livrer est désormais prêt en quelques minutes. Nous profitons tous des assistants de programmation IA et, de plus en plus, d’agents autonomes qui travaillent à nos côtés. Mais cette puissance s’accompagne d’une grande responsabilité : gérer cette accélération. Elle pose aux équipes de sécurité un problème dont elles commencent seulement à mesurer l’ampleur : une surface d’attaque considérablement élargie, que les attaquants peuvent désormais cibler tout en disposant des mêmes capacités de raisonnement par IA que les développeurs utilisent pour accélérer leur travail.

Le problème tient aussi au fait que la surface d’attaque s’étend désormais simultanément sur trois fronts : les failles architecturales que seuls des systèmes capables de raisonner peuvent détecter, les identifiants qui fuient 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. Les adversaires sondent maintenant ces trois fronts en même temps, à la vitesse des machines.

En juin, l’Alliance Five Eyes a averti que l’IA pourrait contourner les capacités actuelles de cybersécurité en quelques mois, et non en quelques années, tandis que le temps nécessaire aux adversaires pour s’introduire dans un système se compte désormais en secondes. Gartner prévoit que le délai avant 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 progresse plus vite que les programmes de sécurité ne peuvent le suivre. Pour se défendre contre tout cela, il faut quatre mesures, et non une seule.

Aujourd’hui, à Black Hat USA 2026, Snyk répond à cette évolution en élargissant plus que jamais la Snyk AI Security Platform. Pas avec une gamme de produits, mais avec une défense unifiée autour des quatre étapes dont les organisations ont besoin pour innover en toute sécurité : découvrir toute la surface d’attaque, corriger le backlog hérité, valider ce qu’un attaquant peut réellement exploiter et prévenir la création de nouveaux risques.

Au premier plan : la disponibilité générale d’Evo Continuous Offensive Security (COS), un pentest autonome propulsé par l’IA qui suit le rythme du développement accéléré par l’IA. Snyk annonce également une gestion de la posture de sécurité de l’IA améliorée, un premier aperçu d’Evo Agentic Application Security et la disponibilité générale de Snyk Secrets. Ensemble, ces solutions sécurisent l’ensemble du cycle de vie des logiciels développés avec l’IA : leur mode de création, leurs composants et la façon dont ils sont attaqués.

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

Face à un attaquant qui raisonne désormais sur votre application à la vitesse des machines, pour le prix de quelques jetons, une défense unifiée est le minimum requis :

  • Découvrir : visualiser toute la surface d’attaque logicielle et liée à l’IA : modèles, agents, serveurs MCP, compétences, outils et ressources accessibles à chacun. Cette première étape repose sur AI-SPM, l’AI-BOM et la Snyk AI Security Platform.

  • Corriger : résorber le backlog hérité avant que les attaquants autonomes ne le parcourent plus vite que les équipes ne peuvent réagir. Cette étape s’appuie sur l’intelligence applicative de Snyk et la correction autonome.

  • Valider : attaquer les applications en continu pour vérifier que les correctifs tiennent, montrer 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êcher les secrets, les packages malveillants et les nouvelles vulnérabilités de reconstituer le backlog pendant que les humains et les agents développent des logiciels. Cette dernière étape est assurée par Snyk Secrets, les contrôles de prévention et la protection 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 fonctionnalité renforce les autres au lieu d’ajouter un outil isolé de plus. C’est ce qui distingue une plateforme d’une simple gamme de produits.

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

Depuis plus de vingt ans, une distinction s’impose en sécurité des applications : 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 l’injection SQL, les scripts intersites, les erreurs de configuration ainsi que les injections et les motifs visibles dans le code. Des centaines de catégories 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 réelle et durable, qui n’est pas près de disparaître.

Mais les attaquants ont remonté la pile, 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 se trouvent dans les relations de confiance d’un système, pas dans son code : elles ne possèdent donc aucune signature détectable par un scanner. Voyons à quoi elles ressemblent :

  • En 2019, First American a exposé environ 885 millions de documents financiers. Il n’a pas fallu de logiciel malveillant ni de faille zero-day : il a suffi de modifier un seul chiffre dans une URL. Tous les scanners n’ont rien signalé et l’application a fait exactement ce que son code lui demandait. Elle n’aurait tout 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.

C’est ce type de faille que les attaquants exploitent aujourd’hui : des défauts d’autorisation au niveau des objets (BOLA) et des élévations de privilèges obtenues en manipulant des identifiants, des fuites interclients qui exfiltrent des données clients et des attaques en chaîne fondées sur la logique métier, où plusieurs problèmes de faible gravité se combinent pour permettre la prise de contrôle d’un compte. Une décennie de failles de faible et moyenne gravité restées en sommeil, auxquelles s’ajoute chaque nouvelle découverte, est désormais accessible et exploitable en chaîne à la vitesse des machines. Impossible d’écrire une règle de scanner pour « 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é le raisonnement humain, d’où le recours systématique aux tests d’intrusion manuels. Le pentest manuel reste irremplaçable, mais il est limité par le temps disponible. Une mission classique dure 15 jours et coûte entre 20 000 et 100 000 dollars, pour ne fournir qu’un instantané. La couverture s’arrête dès la remise du rapport, alors que l’application a déjà connu plusieurs nouvelles versions. Votre pentest couvre environ 15 jours par an. Que se passe-t-il pendant les 350 autres jours ? Le développement ne s’arrête pas, et les attaquants non plus. 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 lourds de conséquences.

L’IA change l’équation, pas la discipline

Voici ce qui a réellement changé. L’étape de raisonnement que seul un pentesteur humain pouvait effectuer — modéliser l’intention d’une application, puis trouver comment la détourner — est désormais à la portée d’un modèle suffisamment performant, de façon reproductible et à une fraction du coût. La discipline reste la même, mais son économie, elle, a radicalement changé.

Les preuves sont déjà publiques et à grande échelle. Entre le début et le milieu de l’année 2026, les signalements de vulnérabilités valides générés par l’IA sur HackerOne ont augmenté de 210 %, et ceux liés à l’injection de prompts de 540 %. Cette hausse concerne précisément les failles qui exigent un raisonnement et échappent aux scanners. La limite du raisonnement, qui avait tenu pendant vingt ans, ne s’est pas érodée progressivement : elle a cédé en l’espace d’une génération de modèles.

La conséquence vraiment dérangeante, c’est que les attaquants ont franchi le même cap au même moment et opèrent déjà de bout en bout. Dans une campagne de cyberespionnage commandité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 détecter et exploiter les failles que les scanners ne voient pas, mais si vos tests de sécurité offensive les trouvent avant les attaquants.

Evo Continuous Offensive Security, désormais disponible

Nous avons développé Evo Continuous Offensive Security pour combler précisément ce fossé. Cette capacité de pentest propulsée par l’IA s’appuie sur un environnement d’exécution IA de niveau entreprise, qui raisonne sur l’intention des applications pour 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 elle fait partie de la Snyk AI Security Platform, elle reçoit le contexte des résultats 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.. Elle peut ainsi orienter son raisonnement vers les failles que ces outils ne détectent pas, au lieu 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 de pentest à redécouvrir des bugs à 1 $ ?

Cette capacité repose sur trois composantes intégrées qui fonctionnent comme un programme de sécurité offensive continu, capable de raisonner là où c’est nécessaire, d’assurer une couverture exhaustive là où c’est utile et spécialement conçu pour la nouvelle surface d’attaque liée à l’IA :

  • Raisonner comme un attaquant - Pentest IA est le cerveau de COS. Cette fonctionnalité définit elle-même son périmètre, planifie une attaque en plusieurs étapes et valide la possibilité d’exploitation. Elle orchestre des agents spécialisés ainsi que tous les outils de son environnement pour découvrir les failles architecturales et les abus de la logique métier qui échappent aux scanners et aux tests manuels. Chaque vulnérabilité confirmée est accompagnée d’une preuve de concept exécutable : une preuve, pas une description.

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

  • Couvrir les vulnérabilités courantes - Tests dynamiques (DAST) assure une couverture exhaustive et hautement déterministe de chaque point de terminaison et d’injection pour les vulnérabilités courantes, comme les scripts intersites (XSS), l’injection SQL et les erreurs de configuration, avec un taux de faux positifs de 0,08 %. Au lieu de consacrer des cycles à valider des bugs courants, la couche de raisonnement utilise ces tests comme un outil : l’IA peut ainsi se concentrer sur les failles, plutôt que sur leur triage.

Les résultats ne se présentent pas sous la forme d’une liste plate d’alertes isolées. Ils forment des chaînes d’exploitation reliées entre elles, qui montrent comment une lacune d’autorisation et une faille logique peuvent se combiner pour créer un chemin d’attaque à fort impact, à l’image du raisonnement d’un 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 COS est donc vérifié par un juge de validation indépendant avant d’être présenté, avec 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 donc 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 convient d’être précis : un modèle performant ne constitue pas un test d’intrusion. Tout repose sur le système, pas sur le modèle : c’est le dispositif d’IA d’entreprise qui encadre le raisonnement et rend les tests offensifs autonomes fiables. Il apporte un contexte et une mémoire persistants d’une exécution à l’autre, un environnement d’exécution contrôlé et une gouvernance qui garantissent la sécurité des tests dans des environnements proches de la production, ainsi que la reproductibilité et les informations de la plateforme qui alimentent chaque évaluation. Les solutions ponctuelles repartent de zéro à chaque exécution, sans mémoire, sans contexte lié à la plateforme et sans gouvernance. C’est cette lacune que le dispositif 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 prendre en charge les catégories de problèmes au niveau de l’implémentation pour lesquelles ils excellent, les testeurs humains se concentrent sur les tâches qui exigent le plus de discernement, et COS couvre la couche continue qui nécessite du raisonnement entre les deux, en validant à nouveau la sécurité à chaque modification de votre application.

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

La validation est le fer de lance de la défense, mais elle n’est qu’une étape dans une boucle, et la solidité de cette boucle dépend de celle des éléments qui l’entourent. COS ne peut démontrer que ce qu’un attaquant pourrait exploiter, car la plateforme qui l’entoure détecte toute la surface d’attaque qu’il teste, résorbe le backlog qu’un attaquant pourrait autrement exploiter et empêche de nouveaux risques de s’accumuler plus vite que vous ne pouvez les tester. Trois annonces bouclent la boucle, et chacune rend COS plus efficace.

Détecter : gestion améliorée de la posture de sécurité de l’IA

Détecter (AI-SPM) : la détection oriente COS vers les bonnes cibles et, de plus en plus, lui fournit les informations nécessaires : les signaux AI-BOM et AI-SPM dont COS se sert pour tester les applications conçues autour 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 ses informations sur les risques de 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 liés aux compétences et aux serveurs MCP, directement présentée dans l’AI-BOM. Résultat : une visibilité sur ce avec quoi vos agents interagissent réellement, à savoir chaque modèle, compétence et serveur MCP utilisé. Vous disposez aussi d’une méthode plus précise et plus défendable pour évaluer les risques associés à chacun. Comme le montre clairement la nouvelle étude de Snyk, l’empreinte réelle de l’IA d’une organisation est bien plus vaste que ne le laisse penser son inventaire de modèles, et la majorité des programmes de gouvernance ne la couvrent toujours pas. Cette nouveauté comble cette lacune.

Corriger : premier aperçu des prochaines évolutions d’Evo Agentic AppSec

Corriger (Agentic AppSec) : la correction transforme un constat de 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 d’une sécurité applicative autonome, où l’AppSec ne se limite plus à détecter les problèmes, mais les corrige et s’en protège de manière autonome. Cette vision prend forme avec la préversion publique de l’agent de correction de Snyk, disponible via CLI et ADE. Celui-ci corrige automatiquement les vulnérabilités au lieu de remettre aux développeurs un backlog à trier. Snyk présente également un premier aperçu d’un nouvel agent de détection des logiciels malveillants, conçu pour repérer le code malveillant avant sa mise en production. C’est dans cette direction que la discipline évolue, et c’est là que commence le prochain chapitre de la plateforme.

Prévenir : Snyk Secrets, désormais disponible de manière générale

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

Enfin, Snyk Secrets, un produit de détection et de prévention des secrets conçu pour le cycle de développement agentique (ADLC), est désormais disponible de manière générale. Le code généré par l’IA a fait des identifiants exposés un problème majeur. Snyk Secrets s’appuie sur un moteur propriétaire de détection par apprentissage automatique, qui analyse le contexte d’un secret potentiel afin de réduire les faux positifs. Il intègre également des contrôles préventifs dans les agents de codage IA, les IDE, les pull requests et les pipelines CI/CD. C’est un élément naturel de la sécurisation du développement logiciel agentique : les identifiants sont empêchés d’atteindre la production, tandis que les développeurs continuent d’avancer.

« Le volume et le rythme de production du code généré par l’IA ont complètement dépassé les capacités du modèle de test d’intrusion que la plupart d’entre nous appliquent depuis des années. On ne peut pas résoudre un problème de surface d’attaque continue en multipliant les tests planifiés. Il nous faut des tests offensifs capables de suivre le rythme auquel nous développons réellement les logiciels aujourd’hui, avec suffisamment de contexte pour se concentrer sur ce qui est véritablement exploitable, et pas seulement théoriquement possible. », 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 élargi la surface d’attaque tout au long du cycle de vie : le code écrit par l’IA, les identifiants et composants utilisés pour le créer, les modèles et agents qui y sont intégrés, et l’application en cours d’exécution qu’un adversaire peut sonder. Les outils ponctuels et les tests effectué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 implique de les tester selon les méthodes actuelles de développement et d’attaque : en continu, avec le contexte de l’ensemble de 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 prendre en compte leur mode de développement, les éléments qui les composent et la manière dont ils sont attaqués.

Disponibilité

Evo Continuous Offensive Security et Snyk Secrets sont désormais disponibles de manière générale. 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 disponible en préversion publique via Snyk CLI, tandis que l’agent de détection de code malveillant est en préversion privée. Réservez une démonstration 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

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

L’analyse statique a détecté les failles, mais seuls des tests d’attaque en conditions réelles ont prouvé comment elles pouvaient être enchaînées pour provoquer des compromissions. Comparaison d’Evo COS, de Claude Security et de Claude Code Security.

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.

Blog

Pourquoi les agents de codage IA créent-ils sans cesse des failles de contrôle d’accès ?

Les agents de codage IA peuvent générer une logique d’autorisation qui compile et passe la revue, tout en exposant les données d’un tenant à un autre. Découvrez pourquoi les failles de contrôle d’accès sont difficiles à détecter et comment les prévenir.