Pendant la majeure partie de ma carrière, la sécurité de la chaîne d’approvisionnement logicielle consistait à examiner minutieusement ce que les développeurs intègrent : dépendances, images de base et paquets tiers.
Cette approche est désormais dangereusement incomplète.
Au cours de l’année écoulée, les attaquants sont remontés en amont, au-delà des paquets et jusque dans les outils que les développeurs utilisent pour écrire du code.
Les extensions d’IDE, les assistants de programmation fondés sur l’IA et les serveurs Model Context Protocol (MCP) font aujourd’hui partie de l’infrastructure standard des développeurs.
Ils ont accès aux bases de code, aux identifiants et aux pipelines CI/CD. Et la plupart des frameworks de sécurité n’ont jamais été conçus pour les prendre en compte.
Il s’agit d’un changement structurel, pas d’une hypothèse. Selon le rapport 2026 de JFrog sur l’état de la sécurité de la chaîne d’approvisionnement logicielle, 41 % des organisations utilisent désormais activement des bibliothèques d’IA et de ML, contre 34 % un an plus tôt, et l’organisation moyenne gère 47 % de paquets de ce type en plus par rapport à l’année dernière.
La chaîne d’approvisionnement n’a pas simplement ajouté une catégorie consacrée à l’IA. De plus en plus, l’IA est la chaîne d’approvisionnement.
À retenir
- Les outils des développeurs font désormais partie de la chaîne d’approvisionnement logicielle : extensions d’IDE, serveurs MCP, modèles d’IA et compétences d’agents créent de nouvelles voies d’attaque.
- La gouvernance peine à suivre l’adoption : seules 43 % des organisations disposent d’un ensemble d’outils de développement approuvés et encadrés par une politique.
- Les écosystèmes d’IA sont déjà détournés à des fins malveillantes : des extensions, des compétences d’agents et des modèles malveillants apparaissent dans les registres largement utilisés.
- L’exploitabilité compte davantage que le volume de vulnérabilités : sur 337 CVE très médiatisées testées, seules 12 % se sont révélées hautement exploitables dans des environnements réels.
- La visibilité doit déboucher sur l’action, ce qui exige des équipes de sécurité qu’elles relient la provenance, l’applicabilité, les politiques et les éléments de preuve d’audit sur l’ensemble du cycle de développement.
La surface d’attaque a suivi les développeurs
Il suffit de regarder ce qui s’est passé au niveau des outils. Le registre OpenVSX — utilisé par les IDE natifs de l’IA — est passé d’environ 1 000 extensions en 2023 à 3 803 en 2025, soit une hausse de 262 %.
Cette même année, 56 extensions malveillantes y ont été détectées, dont GlassWorm, le premier ver autoréplicatif ciblant les extensions VS Code.
GlassWorm dissimulait du code malveillant dans des caractères Unicode invisibles, dérobait les identifiants des développeurs pour se propager de manière autonome et a atteint environ 35 800 installations.
La couche agentique n’a pas fait mieux. JFrog Security Research a identifié plus de 20 vulnérabilités critiques d’exécution de code à distance dans des serveurs MCP en 2025, dont CVE-2025-6514, une faille notée 9,6 sur l’échelle CVSS dans l’utilitaire mcp-remote, largement utilisé.
Lorsque l’équipe a étendu l’analyse aux registres de compétences d’agents d’IA au début de 2026, elle y a trouvé 969 compétences d’agents malveillantes contenant des charges utiles à impact critique.
Du côté des modèles, 495 modèles malveillants ont été détectés dans des registres publics comme Hugging Face — les mêmes registres depuis lesquels 53 % des organisations récupèrent des modèles à héberger elles-mêmes.
Chaque endroit où les développeurs travaillent désormais — la marketplace d’extensions, le registre de compétences d’agents, le hub de modèles — est devenu un mécanisme de diffusion.
Le périmètre ne correspond plus à une frontière réseau. Il englobe désormais tout l’acte de créer, empaqueter et exploiter des logiciels.
Le paradoxe de la gouvernance
C’est ici que les données deviennent préoccupantes. Interrogées sur la gouvernance de l’utilisation de MCP, 97 % des organisations déclarent appliquer une forme ou une autre de liste certifiée.
Sur le papier, cela ressemble à une certaine maturité. Mais la gouvernance sans analyse continue n’est qu’une liste, pas un contrôle.
Le tableau plus large des outils confirme cette lacune.
Seules 43 % des organisations disposent d’un ensemble certifié d’outils de développement préapprouvés, encadré par une politique, et 39 % utilisent des contrôles automatisés pour bloquer ceux qui ne sont pas approuvés.
Pendant ce temps, 18 % n’ont aucune gouvernance ou une gouvernance de façade — et 10 % supplémentaires comptent entièrement sur les développeurs pour s’autoréguler sous la pression des délais, ce qui porte la part effective des organisations dépourvues de gouvernance à près d’un quart.
Face à un paysage de menaces qui a produit GlassWorm et une vulnérabilité MCP de gravité 9,6 en une seule année, il s’agit de la lacune la plus flagrante de la sécurité des entreprises aujourd’hui.
La précision, antidote au bruit
Rien de tout cela n’appelle davantage d’alertes. L’étude défend la thèse inverse.
Nous avons conçu des analyseurs d’applicabilité pour 337 CVE très médiatisées publiées en 2025 — en vérifiant non seulement si du code vulnérable existe, mais aussi si les conditions nécessaires à son exploitation sont effectivement réunies dans des environnements d’entreprise réels.
Seules 40 de ces CVE, soit environ 12 %, se sont révélées hautement exploitables en pratique.
Le triage fondé sur le volume échoue auprès des équipes de sécurité : davantage de CVE à traiter ne signifie pas davantage de risques réels.
Cela signifie davantage de bruit, et c’est dans le bruit que se dissimulent les véritables menaces.
Pour les RSSI, c’est l’argument à présenter au conseil d’administration.
La question n’est pas de savoir combien de détections vos outils génèrent, mais si vous pouvez démontrer lesquelles comptent dans votre environnement et agir avant l’attaquant.
La visibilité sans responsabilité n’est pas de la gouvernance
Un autre chiffre devrait faire réfléchir tous les responsables de la sécurité : 59 % des organisations déclarent bénéficier d’une visibilité complète sur la provenance en production, mais 48 % ont encore besoin d’une semaine ou plus pour produire les éléments de preuve nécessaires aux audits de conformité.
Ces deux chiffres ne peuvent pas refléter simultanément un programme sain.
Si la visibilité était réelle — structurée, accessible et prête pour l’audit — il faudrait quelques minutes, et non des semaines, pour produire les preuves.
Pour de nombreuses organisations, la « visibilité complète » signifie que les données existent quelque part, pas que quiconque puisse agir à partir d’elles.
C’est pourquoi je suis sceptique face à la réaction réflexe du secteur : ajouter une nouvelle solution ponctuelle à chaque nouvelle surface d’IA.
Un registre MCP par-ci, un analyseur d’extensions par-là, puis un fournisseur chargé de contrôler les modèles.
Fait notable, 38 % des organisations déclarent désormais s’appuyer principalement sur les capacités de sécurité de leur plateforme DevOps existante — reconnaissant ainsi que les îlots de données fragmentés constituent eux-mêmes un risque.
Votre mission n’a jamais été de sécuriser une petite catégorie d’artefacts après l’autre.
Elle consiste à sécuriser l’application d’IA dans son ensemble, de la première ligne de code assisté par l’IA jusqu’à l’agent exécuté en production.
Le rôle du RSSI moderne est d’aider l’entreprise à avancer rapidement tout en restant en sécurité — à permettre la vitesse qu’exige l’ère agentique, et non à la ralentir.
Cela exige un système de référence unique couvrant tout ce que les développeurs utilisent pour construire et tout ce que l’IA touche : un endroit où la provenance, l’applicabilité et les politiques coexistent.
Les organisations qui y arriveront les premières ne seront pas seulement plus sûres. Elles seront aussi plus rapides — car elles consacreront leur temps aux risques réels, et non au bruit qui ne l’est pas.