Qu’est-ce que l’Agentic AppSec ?

L’Agentic AppSec (sécurité applicative agentique) consiste à confier à une équipe d’agents de sécurité IA l’ensemble du programme de sécurité applicative d’une organisation : comprendre l’application, modéliser ses menaces, détecter les vulnérabilités importantes, déterminer lesquelles méritent d’être corrigées, générer et valider les correctifs, puis prouver leur efficacité. Cette démarche s’applique en continu au nouveau code comme au backlog existant.

On confond facilement ce terme avec la sécurité de l’IA agentique, mais les deux désignent des approches opposées : la sécurité de l’IA agentique protège les agents IA contre les attaques, tandis que l’Agentic AppSec met les agents IA au service de la sécurité. Le recours à des agents pour gérer le programme répond à un problème de volume : les logiciels sont désormais livrés plus vite qu’un programme de sécurité piloté par des humains ne peut les traiter.

Pourquoi la sécurité applicative a-t-elle besoin d’un nouveau modèle opérationnel ?

La sécurité applicative a besoin d’un nouveau modèle opérationnel, car le rythme de production du code a changé et un programme dimensionné pour l’ancien rythme ne peut pas absorber le nouveau.

Un programme traditionnel détecte les problèmes et les transmet à des personnes. Ces personnes prennent alors en charge tout ce qui suit la détection : le triage, la priorisation, le correctif, le risque de régression et les échanges avec l’équipe de développement. Cette organisation fonctionnait tant que les humains écrivaient la majeure partie du code. Aujourd’hui, les agents de codage IA génèrent plus de code que les processus de revue ne peuvent en traiter, et les failles qu’ils introduisent se concentrent dans la logique métier et les autorisations, où l’analyse par détection de motifs n’a rien à repérer.

Le backlog existant accroît la pression. Chaque organisation accumule des années de problèmes non résolus, et les attaquants automatisent désormais l’inventaire de ce backlog et enchaînent des problèmes de faible gravité pour créer des exploits critiques. En juin 2026, Snyk observe environ six nouvelles vulnérabilités introduites pour chaque vulnérabilité corrigée.

Quand les nouvelles vulnérabilités arrivent plus vite qu’elles ne sont corrigées, une meilleure priorisation ne fait que produire une file d’attente mieux ordonnée, mais toujours aussi longue. Le principal obstacle n’est plus la détection des problèmes, mais leur résolution. À cette échelle, il faut un nouveau modèle opérationnel, pas simplement une version plus rapide du modèle actuel.

Que comprend le cycle de sécurité applicative ?

L’Agentic AppSec répond à ce défi en confiant le cycle de sécurité applicative à une équipe d’agents. Chaque agent a une mission et un déclencheur définis. Ensemble, ils travaillent en continu sur le nouveau code et sur tout ce qui a déjà été livré. Le cycle comporte six étapes, chacune s’appuyant sur le résultat de la précédente :

1. Comprendre l’application. Établir un modèle de son architecture, de ses flux de données, de leur classification, de ses frontières de confiance et de ce qui est réellement exécuté en production.

2. Modéliser ses menaces. S’appuyer sur ce modèle pour repérer les vecteurs d’attaque de l’application et les faiblesses susceptibles d’avoir de réelles conséquences, puis actualiser le modèle de menaces à mesure que le code évolue.

3. Détecter les vulnérabilités importantes. Combiner l’analyse déterministe à un raisonnement par IA capable de repérer les catégories qu’aucune signature ne décrit, comme les failles de logique métier et d’autorisation.

4. Déterminer ce qui mérite d’être corrigé. Hiérarchiser les problèmes à résoudre en priorité et définir à quoi ressemble un correctif adéquat, en s’appuyant sur l’atteignabilité, l’exploitabilité et l’historique des résultats des correctifs.

5. Générer et valider les correctifs. Produire des modifications qui résolvent le problème, passent en revue et sont fusionnées.

6. Prouver l’efficacité des correctifs. Confirmer chaque résultat à l’aide d’un système différent de celui qui l’a produit, et consigner la décision ainsi que son raisonnement.

Il s’agit d’un cycle, pas d’un pipeline : il s’exécute en continu plutôt qu’à un seul point de contrôle, et chaque étape s’appuie sur le modèle créé lors de la première. Les personnes responsables du programme cessent de gérer la file d’attente et se mettent à superviser le système qui s’en charge.

Quelles conditions faut-il réunir pour confier un programme de sécurité à des agents ?

Trois conditions permettent aux agents de gérer un programme de sécurité. La troisième distingue un programme réellement opérationnel d’une simple promesse convaincante.

• Les agents doivent disposer d’un contexte : Un agent qui raisonne sans modèle de l’application peut produire des constats assurés sur une base de code qu’il a en partie imaginée. Le modèle partagé créé à la première étape du cycle, que Snyk appelle le graphe de contexte applicatif, est consulté par chaque agent avant qu’il agisse.

• Le travail doit être délimité : Chaque tâche a une mission, un déclencheur, une entrée et une fin clairement définis. Les agents qui savent où chercher d’abord, parce que le modèle de menaces leur indique où regarder, sont plus précis et moins coûteux à exécuter que ceux qui effectuent des recherches étendues.

• La validation doit être effectuée par un autre système : On ne peut pas faire confiance à l’agent qui détecte une vulnérabilité pour valider son propre correctif. Un système qui évalue son propre résultat hérite de toutes les hypothèses de son analyse ; un modèle plus puissant ne fait que produire une réponse erronée plus convaincante. C’est pourquoi les moteurs déterministes sont d’autant plus importants dans un programme agentique : les agents les utilisent et ils vérifient indépendamment les résultats de ces agents. Dans Snyk VulnBench JS 1.0, près de la moitié des problèmes détectés uniquement par un LLM n’apparaissaient que dans l’une des cinq exécutions identiques.

Quelle est la différence entre l’Agentic AppSec et la sécurité de l’IA agentique ?

L’Agentic AppSec utilise des agents IA pour sécuriser les logiciels, tandis que la sécurité de l’IA agentique protège les agents IA eux-mêmes. Les conditions décrites ci-dessus concernent les agents qui effectuent des tâches de sécurité. La sécurisation des agents relève d’une discipline distincte, et bon nombre de contenus aux formulations similaires traitent plutôt de cette dernière.

• La sécurité de l’IA agentique protège les agents IA. Un agent dispose d’une mémoire, utilise des outils, détient des identifiants et agit sans qu’une personne approuve chacune de ses actions, ce qui crée des risques que la sécurité applicative traditionnelle n’a pas été conçue pour couvrir. L’injection de prompt, le détournement d’outils et les autorisations trop étendues des agents en font partie.

• L’Agentic AppSec met les agents IA au service de la protection des logiciels. Les agents sont les acteurs de la sécurité, et le programme de sécurité applicative constitue leur mission.

Toute organisation qui adopte le développement assisté par IA à grande échelle a besoin des deux approches. Elles requièrent des contrôles, des responsables et des critères d’évaluation différents. Une équipe qui en achète une en pensant qu’elle couvrira aussi l’autre laissera ce second besoin sans réponse.

Qu’est-ce qui change pour les équipes ?

Confier le cycle aux agents change le travail des personnes qui les entourent, mais pas leurs responsabilités. L’Agentic AppSec entraîne trois changements :

1. Les développeurs deviennent des approbateurs plutôt que des auteurs. Ils examinent des modifications qu’ils n’ont pas écrites, ce qui rend les preuves associées à chaque modification plus importantes qu’auparavant.

2. Les responsables AppSec deviennent les pilotes du programme plutôt que ses gardiens. Leur rôle ne consiste plus à trier une file d’attente qui grossit plus vite que quiconque ne peut la traiter, mais à définir les conditions permettant de faire confiance aux correctifs et à démontrer l’efficacité du programme.

3. Les responsabilités ne changent pas. La personne responsable du programme le reste. Le programme doit donc fournir une piste d’audit indiquant ce que l’agent a décidé, les éléments sur lesquels il a agi et la manière dont le résultat a été vérifié. La personne passe du rôle d’opérateur à celui d’auditeur ; la piste d’audit rend cette fonction possible.

L’Agentic AppSec en pratique

L’Agentic AppSec répond à un problème de rythme : le code arrive désormais plus vite qu’un programme piloté par des humains ne peut le traiter. Des agents qui disposent d’un modèle de l’application, travaillent dans des limites clairement définies et font l’objet d’une vérification indépendante permettent au programme de suivre la cadence, tandis que les équipes en définissent le fonctionnement et en apportent les preuves.

L’approche de Snyk en matière d’Agentic AppSec

Evo Agentic AppSec, qui fait partie de la Snyk AI Security Platform, met une équipe d’agents de sécurité aux côtés de chaque équipe d’ingénierie pour gérer l’ensemble du programme AppSec : comprendre, détecter, corriger et vérifier. Les agents exécutent les tâches, tandis que la couche d’intelligence de Snyk détermine ce qui constitue un bon correctif, en s’appuyant sur dix ans de données sur les résultats des correctifs, ainsi que sur l’analyse de l’atteignabilité, de l’exploitabilité et de la facilité de compromission. Les moteurs déterministes de Snyk vérifient ensuite le résultat de façon indépendante. Snyk s’intègre au flux de travail des développeurs déjà utilisé par les équipes et ne dépend d’aucun fournisseur de modèles ; la vérification reste donc distincte des modèles qui génèrent le code. Découvrez Evo Agentic AppSec en avant-première.

Vous souhaitez placer une équipe d’agents de sécurité aux côtés de chaque ingénieur ? Contactez dès aujourd’hui votre représentant Snyk.