Ce que près de 10 000 environnements de développement révèlent sur les risques du développement agentique

Principales conclusions

• La multiplication des outils de codage IA est courante : 43 % des développeurs utilisent au moins deux environnements de codage IA.

• L’adoption de MCP est déjà généralisée : 50,8 % des développeurs ont installé au moins un serveur MCP.

• Les risques liés à MCP sont déjà visibles : 1 développeur sur 7 disposant de serveurs MCP a rencontré au moins un problème de sécurité.

• Les compétences des agents ajoutent une autre couche de risque : 22,8 % des développeurs avaient installé au moins une compétence.

• L’injection de prompt est présente dans les outils utilisés : Snyk a détecté 392 cas avérés d’injection de prompt dans des descriptions d’outils.

Depuis des années, les équipes de sécurité des applications se concentrent sur des questions bien connues : Le code est-il sécurisé ? Les dépendances présentent-elles des vulnérabilités ? Le pipeline de compilation est-il protégé ? Les problèmes sont-ils détectés avant la mise en production ?

Le développement agentique soulève une nouvelle question : Quels systèmes, outils, instructions et autorisations ont contribué à produire ce code ?

Les agents de codage IA ne se contentent plus de suggérer des extraits ou de compléter des lignes de code. Ils sont de plus en plus connectés aux serveurs MCP, aux compétences, aux intégrations et à d’autres éléments de l’environnement de développement logiciel. Ils peuvent récupérer du contexte, appeler des services externes, exécuter des actions et générer du code d’une manière que les processus de sécurité existants n’ont pas été conçus pour détecter ni encadrer.

L’environnement de développement fait donc désormais partie de la chaîne d’approvisionnement logicielle que les équipes doivent comprendre et encadrer. Et selon les nouvelles recherches de Snyk, cette évolution est déjà visible dans les environnements réels des développeurs.

Snyk a analysé près de 10 000 environnements de développement, dont ceux d’adopteurs précoces d’ADS, et a constaté une exposition mesurable liée aux outils de codage IA, aux serveurs MCP et aux compétences des agents. Les données révèlent une évolution que les équipes AppSec ne peuvent plus considérer comme théorique : le développement agentique crée une nouvelle couche dans la chaîne d’approvisionnement logicielle, que la plupart des programmes de sécurité n’ont pas été conçus pour détecter ni encadrer.

Les outils de codage IA deviennent des environnements de développement connectés

Les outils de codage IA font désormais partie du quotidien des développeurs. Pourtant, dans de nombreuses organisations, leur adoption ne se limite pas à un seul outil approuvé ni à un environnement standardisé. Les développeurs peuvent utiliser simultanément plusieurs environnements de codage IA, notamment Claude, Cursor, Windsurf, Gemini, Copilot, Kiro et des extensions VS Code. Chaque outil peut avoir sa propre configuration, ses propres intégrations, sources de contexte et autorisations. Pour les équipes AppSec, cela pose un problème de visibilité.

La multiplication des outils IA devient un enjeu de sécurité lorsque chaque environnement peut se connecter à des systèmes externes, exploiter des instructions et influencer la création du code. Plus les outils utilisés sont nombreux, plus il devient difficile de répondre à des questions essentielles en matière de gouvernance :

• Quels environnements de codage IA sont installés ?

• À quoi sont-ils connectés ?

• De quelles autorisations disposent-ils ?

• Quelles instructions influencent leur comportement ?

• Fonctionnent-ils dans le cadre des contrôles de sécurité approuvés ou en dehors de celui-ci ?

Dans l’AppSec traditionnelle, les équipes peuvent souvent commencer par examiner le dépôt, le pipeline de compilation ou l’artefact déployé. Dans le développement agentique, les risques peuvent apparaître plus tôt, au sein même de l’environnement de développement, avant que le code ne soit validé.

Les serveurs MCP deviennent une nouvelle couche de la chaîne d’approvisionnement

MCP, ou Model Context Protocol, permet aux agents IA de se connecter à des outils et à des sources de données externes. En pratique, cela peut inclure des dépôts de code, l’automatisation de navigateurs, de la documentation, des fichiers locaux, des systèmes de suivi des problèmes, des outils de conception et d’autres services utilisés tout au long du cycle de développement logiciel. Les serveurs MCP ne sont donc pas qu’une simple couche de commodité : ils contribuent à définir ce à quoi les agents peuvent accéder et ce qu’ils peuvent faire.

Il s’agit de configurations actives qui permettent aux agents d’interagir directement avec des outils et services externes depuis les machines des développeurs.

Dans le développement logiciel traditionnel, la chaîne d’approvisionnement se compose souvent de paquets, de dépendances, de conteneurs et d’artefacts. Ces éléments peuvent être analysés, inventoriés, encadrés et surveillés à l’aide de processus bien établis.

Mais les serveurs MCP fonctionnent différemment et font partie de la couche d’accès : ils déterminent ce que les agents peuvent voir et faire. Ils sont souvent installés localement ou configurés en dehors des processus de contrôle centralisés. Ils peuvent aussi donner aux agents accès à des systèmes sensibles avant que le code n’atteigne un dépôt, un pipeline CI ou un point de contrôle de sécurité standard. Des signes de risque apparaissent déjà dans les environnements de développement agentique.

En pratique, ce risque ne se présente pas nécessairement sous la forme d’un paquet vulnérable intégré à une application. Il peut plutôt s’agir d’un serveur MCP ou d’une configuration d’agent qui influence les actions de l’agent, les systèmes auxquels il peut accéder ou les instructions qu’il suit.

Par exemple, des risques d’injection de prompt peuvent apparaître à des endroits que les analyses traditionnelles ne vérifient pas forcément. Snyk a détecté 392 cas avérés d’injection de prompt intégrés à des descriptions d’outils, ainsi que 98 cas avérés de schémas de code malveillant dans des fichiers de compétences d’agents, dans des environnements qui étaient déjà actifs au moment de l’analyse.

Les configurations d’outils peuvent créer des voies d’accès inattendues, le comportement des agents peut être influencé par des instructions présentes en dehors des dépôts de code et, dans des flux de travail hautement autonomes, un agent peut agir avant qu’un humain ait examiné le résultat. Les organisations doivent donc sécuriser l’environnement dans lequel ces outils fonctionnent.

Les compétences des agents créent une autre couche de risque

Une analyse distincte des environnements de partenaires de conception en entreprise a porté sur une deuxième couche de la chaîne d’approvisionnement : les compétences des agents. Il s’agit de fichiers d’instructions qui définissent le comportement, les paramètres par défaut, les personnalités, les flux de travail et les capacités réutilisables d’un agent. Ils peuvent aider les équipes à standardiser le comportement des agents, mais ajoutent aussi une autre couche à la chaîne d’approvisionnement : des instructions susceptibles d’être partagées, modifiées, récupérées depuis des écosystèmes tiers ou exécutées en dehors des processus habituels de revue de code.

Les compétences peuvent présenter des risques de plusieurs manières :

• Récupération d’instructions depuis des sources externes

• Exposition des agents à du contenu tiers non contrôlé

• Mauvaise gestion des secrets

• Inclusion d’instructions cachées qui manipulent le comportement de l’agent

Et comme les compétences sont souvent partagées ou récupérées depuis des écosystèmes tiers, elles peuvent jouer le rôle d’un composant de la chaîne d’approvisionnement, même si elles ne ressemblent pas à une dépendance traditionnelle.

Une étude distincte de Snyk sur l’écosystème public des compétences d’agents montre comment ces risques peuvent se manifester dans des situations réelles. Dans l’étude ToxicSkills, les chercheurs de Snyk ont analysé 3 984 compétences provenant de ClawHub et de skills.sh. Ils ont constaté que 13,4 % d’entre elles comportaient au moins un problème de sécurité critique, tandis que 36,82 % présentaient au moins une faille de sécurité. Une validation avec intervention humaine a également confirmé la présence de charges malveillantes conçues pour voler des identifiants, installer des portes dérobées et exfiltrer des données.

Lorsque des instructions externes peuvent influencer le comportement d’un agent, sécuriser le code généré ne suffit pas. Les organisations doivent aussi comprendre la couche d’instructions qui influence le fonctionnement de l’agent.

Pourquoi les contrôles AppSec traditionnels doivent évoluer

L’AppSec traditionnelle a été conçue autour du code, des dépôts, des pipelines et des artefacts. Le développement agentique introduit des risques plus tôt, au sein des outils, des instructions et des configurations qui influencent le code avant même qu’il existe.

Les agents de codage IA peuvent introduire des risques avant la validation du code. Par exemple, des serveurs MCP peuvent être installés sur les machines des développeurs sans figurer dans l’inventaire centralisé, des compétences peuvent influencer le comportement de l’agent sans être examinées comme le code source, et des agents peuvent se connecter à des outils et agir en dehors des limites traditionnelles de SAST, SCA, CI/CD ou des contrôles liés aux dépôts.

Cela ne rend pas l’AppSec existante obsolète. L’analyse SAST, la SCA, l’analyse IaC, la sécurité des conteneurs et les contrôles des pipelines restent essentiels, mais ne suffisent peut-être plus à eux seuls. Pour suivre l’évolution du développement logiciel, les équipes de sécurité doivent étendre leurs programmes au-delà de la sécurisation des artefacts de code et protéger également les systèmes qui les produisent.

Cela comprend les agents, les outils, les intégrations, les instructions et les configurations utilisés dans le développement assisté par l’IA. Le principal enjeu est la visibilité : si les équipes de sécurité ne savent pas quels agents sont utilisés, à quoi ils sont connectés ni quelles instructions ils exploitent, elles ne peuvent pas encadrer efficacement les risques.

5 mesures à prendre dès maintenant par les équipes de sécurité

Le développement agentique évolue rapidement, mais il ne s’agit pas de bloquer l’adoption de l’IA ou de ralentir les développeurs. Les équipes de sécurité doivent intégrer visibilité et gouvernance aux flux de travail que les développeurs utilisent déjà, en commençant par cinq mesures.

1. Identifiez les outils utilisés par les développeurs et les agents : inventorie les environnements de codage IA, les serveurs MCP, les compétences et les intégrations dans l’ensemble des environnements de développement. Les équipes ne peuvent pas encadrer ce qu’elles ne voient pas.

2. Considérez la configuration des agents comme un élément de la chaîne d’approvisionnement logicielle : les revues de sécurité doivent aller au-delà du code et des dépendances pour inclure les outils, les instructions et les composants externes dont dépendent les agents.

3. Étendez les politiques aux serveurs MCP et aux compétences : les organisations doivent pouvoir définir ce qui est autorisé, limité, soumis à approbation ou bloqué en fonction du risque.

4. Évaluez les garde-fous pour les actions des agents : à mesure que les agents gagnent en autonomie, les contrôles de sécurité doivent intervenir au plus près de l’action, et pas uniquement après la production du code.

5. Intégrez la sécurité du développement agentique aux programmes AppSec existants : cela ne doit pas créer un silo de gouvernance isolé, mais élargir l’AppSec pour l’adapter aux nouvelles méthodes de développement logiciel.

C’est sur ces capacités que repose l’approche Agentic Development Security de Snyk : découvrir et encadrer les serveurs MCP et les compétences avant leur intégration aux flux de travail des agents, appliquer des garde-fous dans la boucle d’exécution des agents et valider le code généré par l’IA au fur et à mesure de sa création.

Sécuriser les systèmes qui contribuent au développement logiciel

Sécuriser le code généré par l’IA est nécessaire, mais cela ne suffit plus à lui seul. À mesure que les agents s’intègrent davantage au développement logiciel, les équipes de sécurité doivent comprendre non seulement le code qu’ils produisent, mais aussi les outils, les instructions, les intégrations et les autorisations qui influencent ce résultat. La chaîne d’approvisionnement logicielle comprend les systèmes agentiques qui contribuent à la création des logiciels.

Le rapport complet présente l’ensemble des résultats : les serveurs MCP les plus largement installés et les profils de risque associés, la répartition des types de problèmes liés aux compétences dans les environnements d’entreprise, l’ensemble des données sur les injections de prompt et les schémas de code malveillant, ainsi qu’un cadre détaillé de mesures recommandées pour les équipes de sécurité. Téléchargez-le dès aujourd’hui pour en savoir plus.