Attaquants de la cha\u00eene d\u2019approvisionnement_863x300<\/p>\n
L\u2019atteinte \u00e0 la cha\u00eene d\u2019approvisionnement de LiteLLM en date du 24 mars 2026 n\u2019est pas un \u00e9v\u00e9nement isol\u00e9. C\u2019est le volet le plus r\u00e9cent, et sans doute le plus mena\u00e7ant, d\u2019un r\u00e9pertoire d\u2019attaques en mutation que JFrog Security Research analyse depuis des ann\u00e9es. L\u2019objectif a \u00e9volu\u00e9\u00a0: les cibles ne sont plus les d\u00e9veloppeurs, mais les agents d\u2019intelligence artificielle dont ils d\u00e9pendent pour d\u00e9velopper des applications.
\nLa cible a toujours \u00e9t\u00e9 le d\u00e9veloppeur
\nUne attaque de la cha\u00eene d\u2019approvisionnement ob\u00e9it \u00e0 un principe simple\u00a0: identifier un composant open source de confiance, le corrompre et laisser l\u2019\u00e9cosyst\u00e8me faire le travail de diffusion. Shai-Hulud, dont la d\u00e9couverte a \u00e9t\u00e9 signal\u00e9e en septembre 2025 et qui a fait l\u2019objet d\u2019une analyse approfondie par l\u2019\u00e9quipe JFrog Security Research, en constituait une parfaite illustration. S\u2019appuyant sur un ver auto-r\u00e9plicatif inclus dans des paquets npm, il \u00e9tait con\u00e7u pour d\u00e9rober les jetons d\u2019acc\u00e8s des d\u00e9veloppeurs et r\u00e9infecter automatiquement d\u2019autres packages g\u00e9r\u00e9s par ces derniers. Comme il s\u2019est propag\u00e9 de mani\u00e8re exponentielle sans aucune intervention directe des attaquants, il est consid\u00e9r\u00e9 comme l\u2019une des pires attaques de la cha\u00eene logistique JavaScript de l\u2019histoire.<\/p>\n
Afin d\u2019aider les entreprises \u00e0 se pr\u00e9munir contre ce type de\u00a0risque, JFrog Curation propose un m\u00e9canisme de filtrage automatis\u00e9 qui neutralise les packages open source malveillants et vuln\u00e9rables avant leur arriv\u00e9e dans les environnements de d\u00e9veloppement.
\nLe SDLC se transforme, et la surface d\u2019attaque fait de m\u00eameAuteurs d\u2019attaques de la cha\u00eene d\u2019approvisionnement agentique – image3Auteurs d\u2019attaques de la cha\u00eene d\u2019approvisionnement agentique – image1
\nOutre les d\u00e9veloppeurs eux-m\u00eames, les cybercriminels exploitent \u00e9galement les failles pr\u00e9sentes dans le code produit par l\u2019intelligence artificielle. Les d\u00e9veloppeurs ne comptent plus seulement sur leurs talents de codeurs, mais coordonnent \u00e0 la place plusieurs agents d\u2019intelligence artificielle en m\u00eame temps en vue de coder, tester, rechercher et d\u00e9ployer. Le cycle de vie du d\u00e9veloppement s\u2019est transform\u00e9, \u00e9voluant d\u2019un processus lin\u00e9aire et humain vers un pipeline distribu\u00e9 g\u00e9r\u00e9 par de multiples agents.<\/p>\n
Avant le code g\u00e9n\u00e9r\u00e9 par l\u2019IA :<\/p>\n
Apr\u00e8s le code g\u00e9n\u00e9r\u00e9 par l\u2019IA :<\/p>\n
Chaque d\u00e9veloppeur peut d\u00e9sormais ex\u00e9cuter plusieurs agents en parall\u00e8le, chacun s\u2019interfa\u00e7ant avec des packages d\u2019IA, des serveurs MCP, des mod\u00e8les et des comp\u00e9tences, ce qui entra\u00eene une expansion rapide de la surface d\u2019attaque.<\/p>\n
La cl\u00e9 pour appr\u00e9hender cette nouvelle surface d\u2019attaque r\u00e9side dans la compr\u00e9hension du fonctionnement d\u2019un agent. Un agent IA ne se r\u00e9sume pas \u00e0 un mod\u00e8le\u00a0; il s\u2019agit d\u2019une composition de ressources d\u2019IA :<\/p>\n
\tLe LLM dans son essence
\n \tLes r\u00e8gles et la m\u00e9moire qui fa\u00e7onnent son comportement
\n \tLes comp\u00e9tences d\u2019agent qu\u2019il peut ex\u00e9cuter
\n \tLes serveurs MCP qui le connectent aux syst\u00e8mes externes et aux donn\u00e9es
\nAuteurs d\u2019attaques de la cha\u00eene d\u2019approvisionnement agentique – image2
\nChacun de ces composants repr\u00e9sente un vecteur d\u2019attaque\/de risque potentiel.<\/p>\n
Composition d\u2019un agent IA<\/p>\n
Les agents sont d\u00e9sormais la cible
\nAlors que les mesures de s\u00e9curit\u00e9 sur la cha\u00eene logistique ont complexifi\u00e9 la corruption des environnements de d\u00e9veloppement, les pirates ont chang\u00e9 de strat\u00e9gie. S\u2019il est impossible d\u2019atteindre le d\u00e9veloppeur, autant cibler ses outils.<\/p>\n
Septembre 2025 postmark-mcp\u00a0: le premier serveur MCP malveillant dans la nature.<\/p>\n
Un acteur malveillant a clon\u00e9 le d\u00e9p\u00f4t l\u00e9gitime Postmark MCP et a publi\u00e9 un package npm quasi identique. Pendant quinze versions, il a fonctionn\u00e9 \u00e0 la perfection et a \u00e9t\u00e9 pl\u00e9biscit\u00e9 par des d\u00e9veloppeurs dans des centaines de workflows. Puis la version 1.0.16 a introduit une simple ligne de code, une copie cach\u00e9e (BCC),\u00a0 qui transf\u00e9rait discr\u00e8tement chaque e-mail envoy\u00e9 via le serveur MCP vers un domaine contr\u00f4l\u00e9 par un attaquant. Mots de passe r\u00e9initialis\u00e9s, factures et m\u00e9mos internes ont fait\u00a0 l\u2019objet d\u2019une exfiltration silencieuse au c\u0153ur m\u00eame des processus d\u2019agents d\u2019intelligence artificielle qui avaient aveugl\u00e9ment fait confiance au connecteur.<\/p>\n
Ce qui l\u2019a rendu particuli\u00e8rement dangereux, c\u2019est que les serveurs MCP fonctionnent avec une grande confiance et de larges privil\u00e8ges au c\u0153ur des cha\u00eenes d\u2019outils des agents. Loin de se limiter \u00e0 la contamination d\u2019une unique base de code,\u00a0 un serveur MCP compromis s\u2019\u00e9tablit comme un plan de contr\u00f4le en amont p\u00e9renne, en mesure de pirater un workflow complet pilot\u00e9 par l\u2019intelligence artificielle et tous ses environnements connect\u00e9s.<\/p>\n
Si l\u2019incident postmark-mcp constituait un avertissement, la br\u00e8che LiteLLM repr\u00e9sente quant \u00e0 elle une escalade majeure.
\nL\u2019attaque LiteLLM\u00a0: un nouveau niveau de sophistication
\nAgissant comme une passerelle universelle vers plus de 100 API de grands mod\u00e8les de langage \u2014 parmi lesquelles OpenAI, Anthropic, AWS Bedrock et Google VertexAI \u2014, LiteLLM s\u2019impose comme l\u2019un des packages les plus indispensables de l\u2019\u00e9cosyst\u00e8me de l\u2019intelligence artificielle. Le package enregistre environ 3,4 millions de t\u00e9l\u00e9chargements par jour et est pr\u00e9sent dans 36\u00a0% des environnements cloud. Il s\u2019agit par ailleurs d\u2019une d\u00e9pendance transitive courante au sein des extensions MCP et des environnements de travail pour agents intelligents, ce qui motive directement son choix comme cible. Consultez l\u2019analyse technique compl\u00e8te de l\u2019attaque par l\u2019\u00e9quipe de recherche en s\u00e9curit\u00e9 de JFrog pour plus de d\u00e9tails.<\/p>\n
Cette cyberattaque a \u00e9t\u00e9 orchestr\u00e9e par TeamPCP, le collectif responsable des intrusions r\u00e9centes visant le scanner Trivy d\u2019Aqua Security et l\u2019action GitHub KICS de Checkmarx. Loin d\u2019\u00eatre fortuite, cette attaque relevait d\u2019une campagne orchestr\u00e9e et cumulative.
\nComment cela s\u2019est produit
\nLe processus d\u2019int\u00e9gration et de d\u00e9ploiement continus (CI\/CD) de LiteLLM int\u00e9grait Trivy au moment du build, sans qu\u2019aucune version sp\u00e9cifique n\u2019ait \u00e9t\u00e9 fig\u00e9e. Le 19 mars, TeamPCP avait d\u00e9j\u00e0 compromis l\u2019action GitHub de Trivy. Au moment du build de LiteLLM, l\u2019action Trivy pi\u00e9g\u00e9e s\u2019est empar\u00e9e du jeton de publication PyPI du projet directement sur le runner GitHub Actions pour l\u2019envoyer \u00e0 l\u2019ext\u00e9rieur. Arm\u00e9s de ces identifiants, les pirates ont diffus\u00e9, le 24 mars au matin, les versions 1.82.7 et 1.82.8 de litellm\u00a0; celles-ci int\u00e9graient des charges offensives\u00a0 contournant totalement le processus de release classique de l\u2019outil.
\nCe que le logiciel malveillant a fait
\nUne fois d\u00e9clench\u00e9e, la charge utile a ex\u00e9cut\u00e9 une attaque en trois \u00e9tapes\u00a0:<\/p>\n
\tCollecte d’identifiants tels que les cl\u00e9s SSH, les jetons cloud AWS, GCP et Azure, les secrets Kubernetes, les portefeuilles crypto et les fichiers .env .
\n \tTentative de mouvement lat\u00e9ral \u00e0 travers les clusters Kubernetes en d\u00e9ployant des pods privil\u00e9gi\u00e9s sur chaque n\u0153ud.
\n \tInstallation d\u2019une porte d\u00e9rob\u00e9e systemd persistante qui interroge une infrastructure contr\u00f4l\u00e9e par l\u2019attaquant pour obtenir des fichiers binaires suppl\u00e9mentaires. Toutes les donn\u00e9es collect\u00e9es ont \u00e9t\u00e9 chiffr\u00e9es et exfiltr\u00e9es vers models.litellm.cloud \u2014 un domaine usurpant l\u2019identit\u00e9 de l\u2019infrastructure LiteLLM l\u00e9gitime, enregistr\u00e9 le jour m\u00eame de l\u2019attaque<\/p>\n
La version 1.82.8 s\u2019est r\u00e9v\u00e9l\u00e9e particuli\u00e8rement agressive, puisqu\u2019elle exploitait le m\u00e9canisme de fichiers .pth de Python, lequel s\u2019ex\u00e9cute \u00e0 chaque d\u00e9marrage de l\u2019interpr\u00e9teur Python, que LiteLLM soit explicitement import\u00e9 ou non. La charge utile \u00e9tait encod\u00e9e deux fois en base64 pour \u00e9chapper \u00e0 l\u2019analyse statique.
\nComment cela a \u00e9t\u00e9 d\u00e9couvert\u00a0 – \u00c0 l\u2019int\u00e9rieur d\u2019un agent
\nL\u2019incident a \u00e9t\u00e9 d\u00e9tect\u00e9 initialement au moment o\u00f9 l\u2019extension a \u00e9t\u00e9 appel\u00e9e sous forme de d\u00e9pendance transitive par un module MCP tournant dans l\u2019environnement de Cursor. L\u2019ordinateur d\u2019un chercheur s\u2019est fig\u00e9 en raison d\u2019une saturation de la m\u00e9moire vive, un dommage collat\u00e9ral li\u00e9 \u00e0 un bug de type fork-bomb propre au logiciel malveillant. Le package corrompu s\u2019\u00e9tait infiltr\u00e9 dans l\u2019espace d\u2019ex\u00e9cution d\u2019un agent intelligent sans qu\u2019aucune intervention humaine consciente n\u2019en ait act\u00e9 l\u2019installation pr\u00e9alable.
\nL\u2019impact organisationnel
\n\u00c9tant donn\u00e9 que LiteLLM s\u2019intercale directement entre les applications et diff\u00e9rents prestataires d\u2019IA, l\u2019outil centralise les cl\u00e9s d\u2019API, les variables d\u2019environnement ainsi que les informations de configuration confidentielles de l\u2019ensemble de l\u2019infrastructure IA de l\u2019entreprise. Un simple poste infect\u00e9 compromet les cl\u00e9s d\u2019acc\u00e8s de tous les services d\u2019IA exploit\u00e9s par une entreprise, peu importe l\u2019environnement d\u2019ex\u00e9cution de LiteLLM \u2014 qu\u2019il s\u2019agisse des postes de travail, des pipelines CI\/CD, des serveurs de staging ou de la production. Les versions malveillantes sont rest\u00e9es en ligne sur PyPI pendant environ trois heures. Compte tenu du volume de t\u00e9l\u00e9chargement du package, l\u2019exposition potentielle durant cette fen\u00eatre \u00e9tait consid\u00e9rable.
\nLe sch\u00e9ma est clair<\/p>\n
Attaque
\nVecteur
\nCible<\/p>\n
Shai-Hulud (npm)
\nVer auto-r\u00e9plicatif dans les packages open source
\nEnvironnements de d\u00e9veloppement<\/p>\n
postmark-mcp (npm)
\nServeur MCP malveillant
\nWorkflows d\u2019agents IA<\/p>\n
LiteLLM (PyPI)
\nPackage d’infrastructure d’IA empoisonn\u00e9 via un outil CI compromis
\nRuntimes d’agent + CI\/CD<\/p>\n
\u00a0<\/p>\n
Non seulement la surface d\u2019attaque s\u2019est \u00e9largie, \u00a0 mais elle se trouve d\u00e9sormais multipli\u00e9e par la quantit\u00e9 d\u2019agents que chaque d\u00e9veloppeur d\u00e9ploie. Une seule d\u00e9pendance d\u2019IA compromise peut se propager en cascade dans tous les environnements o\u00f9 les agents fonctionnent simultan\u00e9ment.
\nLe probl\u00e8me de la passerelle d\u2019IA open source
\nLe r\u00f4le de LiteLLM dans l\u2019\u00e9cosyst\u00e8me m\u00e9rite d\u2019\u00eatre examin\u00e9 de pr\u00e8s. \u00c0 la base, il s\u2019agit d\u2019une passerelle d\u2019IA open source utilisant une unique couche de routage interpos\u00e9e entre vos applications et chaque API de LLM que vous utilisez. Cette position architecturale est puissante. C\u2019est pr\u00e9cis\u00e9ment cette caract\u00e9ristique qui en fait une cible de choix aux cons\u00e9quences d\u00e9vastatrices pour les attaquants.<\/p>\n
Faire transiter tout votre trafic li\u00e9 \u00e0 l\u2019intelligence artificielle par un seul et m\u00eame package open source revient \u00e0 placer une confiance aveugle dans son int\u00e9grit\u00e9, dans la rigueur de ses mainteneurs en mati\u00e8re de s\u00e9curit\u00e9 ainsi que dans la cha\u00eene de publication qui l\u2019accompagne. L\u2019affaire du piratage de LiteLLM a mis en lumi\u00e8re la fragilit\u00e9 extr\u00eame d\u2019un tel niveau de confiance. Il a suffi d\u2019une simple d\u00e9pendance non verrouill\u00e9e dans un pipeline CI pour c\u00e9der aux assaillants le contr\u00f4le de l\u2019infrastructure IA globale d\u2019une structure, compromettant au passage\u00a0 chaque cl\u00e9 d\u2019API, chaque jeton cloud et chaque information sensible de l\u2019environnement.<\/p>\n
Bien entendu, il n\u2019est pas question de bouder la puissance offerte par les passerelles d\u2019intelligence artificielle. En revanche, nous d\u00e9fendons avec conviction l\u2019importance de les \u00e9difier sur des bases de s\u00e9curit\u00e9 solides. Une passerelle d\u2019intelligence artificielle positionn\u00e9e au c\u0153ur de votre cha\u00eene logistique d\u2019agents requiert une gouvernance dot\u00e9e de s\u00e9curit\u00e9s de niveau professionnel,\u00a0 plut\u00f4t qu\u2019une simple r\u00e9cup\u00e9ration sur un d\u00e9p\u00f4t public en croisant les doigts.
\nConstruire une cha\u00eene d\u2019approvisionnement agentique de confiance
\nIl ne s\u2019agit pas pour autant de ralentir ou de proscrire le d\u00e9ploiement de l\u2019intelligence artificielle. Il s\u2019agit d\u2019arr\u00eater de faire une confiance aveugle \u00e0 la couche d\u2019IA et de commencer \u00e0 la r\u00e9gir avec la m\u00eame rigueur que celle appliqu\u00e9e au reste de la cha\u00eene d\u2019approvisionnement logicielle.<\/p>\n
C\u2019est pr\u00e9cis\u00e9ment pour cette raison que nous avons lanc\u00e9\u00a0 JFrog AI Catalog et son AI Gateway, con\u00e7u d\u00e8s le d\u00e9part autour du principe selon lequel la fiabilit\u00e9 de vos agents d\u00e9pend enti\u00e8rement de ce qu\u2019ils ing\u00e8rent, produisent et diffusent.
\nLa passerelle d\u2019IA\u00a0: miser sur la s\u00e9curit\u00e9 native
\n\u00c0 la diff\u00e9rence d\u2019une passerelle open source qui se contente de router le trafic sans garantie, la solution JFrog AI Gateway est pens\u00e9e pour servir de couche de liaison s\u00e9curis\u00e9e et conforme aux r\u00e8gles \u00e9tablies. La solution centralise l\u2019ensemble\u00a0 des flux de consommation d\u2019IA, des serveurs MCP et des comp\u00e9tences d\u2019agents\u00a0 via un point de contr\u00f4le unique, unifiant ainsi la gouvernance de toute votre empreinte d\u2019intelligence artificielle. La plateforme veille par ailleurs \u00e0 ce que chaque demande soit authentifi\u00e9e et \u00e0 ce que chaque ressource en aval fasse l\u2019objet d\u2019un contr\u00f4le approfondi avant toute autorisation.<\/p>\n
Voici la nuance architecturale essentielle\u00a0: la JFrog AI Gateway ne sert pas seulement de proxy pour le trafic, elle garantit la s\u00e9curit\u00e9 d\u00e8s le point de connexion, en amont de toute interaction entre un agent et un mod\u00e8le ou un serveur MCP non certifi\u00e9.
\nLe registre MCP JFrog\u00a0: fini la confiance aveugle
\nLe registre JFrog MCP Registry a \u00e9t\u00e9 con\u00e7u pour faire face directement \u00e0 ce type d\u2019attaque bien pr\u00e9cis, illustr\u00e9 par postmark-mcp et LiteLLM. Il consid\u00e8re les serveurs MCP comme\u00a0 des composants r\u00e9gis de la m\u00eame fa\u00e7on que JFrog l\u2019a toujours fait pour s\u00e9curiser\u00a0 les packages logiciels, en int\u00e9grant directement des fonctions d\u2019analyse, de contr\u00f4le des r\u00e8gles et de versionnage.<\/p>\n
Concr\u00e8tement, le MCP Registry propose les fonctionnalit\u00e9s cl\u00e9s suivantes\u00a0:
\nS\u00e9curit\u00e9 native d\u00e8s la conception
\nBloquer de mani\u00e8re proactive les serveurs MCP malveillants ou non conformes avant qu\u2019ils ne soient t\u00e9l\u00e9charg\u00e9s ou ex\u00e9cut\u00e9s par des agents, plut\u00f4t que de les d\u00e9tecter apr\u00e8s une compromission.
\nGouvernance centralis\u00e9e
\nLes d\u00e9veloppeurs acc\u00e8dent \u00e0 un registre de serveurs MCP pr\u00e9-approuv\u00e9s directement depuis leurs IDE (Cursor, Claude Code, VS Code), sans avoir besoin de les r\u00e9cup\u00e9rer depuis des registres publics.
\nApplication de politiques de niveau entreprise
\nRemplacement de la \u00ab\u00a0confiance aveugle\u00a0\u00bb par des autorisations granulaires au niveau du projet qui contr\u00f4lent pr\u00e9cis\u00e9ment les serveurs MCP auxquels les agents sont autoris\u00e9s \u00e0 se connecter.
\nUne passerelle MCP locale
\nUn proxy l\u00e9ger qui g\u00e8re de mani\u00e8re transparente l\u2019authentification et les contr\u00f4les d\u2019autorisation sur la machine du d\u00e9veloppeur, garantissant que les agents de codage ne se connectent qu\u2019\u00e0 des serveurs pr\u00e9-v\u00e9rifi\u00e9s.
\nLa r\u00e9ussite de l\u2019attaque visant postmark-mcp d\u00e9coule du fait qu\u2019un d\u00e9veloppeur a import\u00e9 un serveur MCP issu d\u2019un registre public sans remettre en question sa fiabilit\u00e9. Le succ\u00e8s de l\u2019attaque contre LiteLLM s\u2019explique par le fait qu\u2019un processus de build a accord\u00e9 sa confiance aveugle \u00e0 un composant open source non verrouill\u00e9. Le registre JFrog MCP Registry est \u00e9labor\u00e9 pour emp\u00eacher que de tels sc\u00e9narios ne surviennent \u00e0 l\u2019insu du d\u00e9veloppeur\u00a0: chaque serveur MCP y est trait\u00e9 comme un composant contr\u00f4l\u00e9, et tout \u00e9l\u00e9ment non valid\u00e9 est stopp\u00e9 net \u00e0 l\u2019entr\u00e9e.<\/p>\n
Le registre JFrog MCP Registry est \u00e9labor\u00e9 pour emp\u00eacher que des attaques comparables \u00e0 postmark-mcp ou LiteLLM ne surviennent \u00e0 l\u2019insu des \u00e9quipes de d\u00e9veloppement et d\u2019exploitation\u00a0: chaque serveur MCP y est trait\u00e9 comme un composant contr\u00f4l\u00e9, et tout \u00e9l\u00e9ment non valid\u00e9 est stopp\u00e9 net \u00e0 l\u2019entr\u00e9e.
\nUn syst\u00e8me unique d\u2019enregistrement pour l\u2019ensemble de la cha\u00eene d\u2019approvisionnement agentique
\nL\u2019ambition plus vaste est d\u2019\u00e9tablir un r\u00e9f\u00e9rentiel unique supervisant l\u2019ensemble des \u00e9l\u00e9ments consomm\u00e9s et produits par les agents (mod\u00e8les, serveurs MCP, comp\u00e9tences d\u2019agents, code g\u00e9n\u00e9r\u00e9 par l\u2019intelligence artificielle et objets assembl\u00e9s), centralisant ainsi la gestion sous les m\u00eames exigences de s\u00e9curit\u00e9 et de conformit\u00e9 que l\u2019ensemble de la cha\u00eene logistique logicielle.<\/p>\n
C\u2019est ce que JFrog appelle une cha\u00eene d\u2019approvisionnement agentique de confiance. La solution transpose au domaine de l\u2019intelligence artificielle et \u00e0 ses nouveaux types de ressources les principes de s\u00e9curit\u00e9 \u00e9prouv\u00e9s depuis des d\u00e9cennies pour les cha\u00eenes logistiques de logiciels, incluant l\u2019immutabilit\u00e9, la tra\u00e7abilit\u00e9, le respect des r\u00e8gles et l\u2019analyse continue. Elle est valid\u00e9e par des partenariats avec des acteurs comme NVIDIA, dont l\u2019environnement d\u2019ex\u00e9cution OpenShell s\u2019appuie sur la plateforme JFrog en tant que point de terminaison administr\u00e9 pour diffuser des comp\u00e9tences d\u2019agents v\u00e9rifi\u00e9es \u00e0 grande \u00e9chelle.
\nComment JFrog aide \u00e0 prot\u00e9ger votre cha\u00eene d\u2019approvisionnement agentique
\nEn devenant partenaire de JFrog, vous pouvez commencer \u00e0 prot\u00e9ger votre organisation contre les derni\u00e8res attaques de la cha\u00eene d\u2019approvisionnement en suivant les \u00e9tapes suivantes\u00a0:<\/p>\n
\tAuditez vos cha\u00eenes de d\u00e9pendances d\u2019IA, y compris les d\u00e9pendances transitives r\u00e9cup\u00e9r\u00e9es par les agents et les plugins MCP
\n \tAssurez-vous de figer les versions car\u00a0l\u2019attaque LiteLLM a exploit\u00e9 des d\u00e9pendances non fig\u00e9es \u00e0 plusieurs points de la cha\u00eene
\n \tArr\u00eatez de voir dans les passerelles d\u2019intelligence artificielle open source des environnements de confiance par d\u00e9faut, et privil\u00e9giez un routage des flux via des passerelles professionnelles et s\u00e9curis\u00e9es par des r\u00e8gles strictes.
\n \tGouvernez vos serveurs MCP \u2014 utilisez JFrog MCP Registry pour veiller \u00e0 ce que les agents ne se connectent qu\u2019\u00e0 des serveurs v\u00e9rifi\u00e9s et approuv\u00e9s
\n \tEffectuez une rotation stricte des informations d\u2019identification apr\u00e8s toute suspicion de compromission en partant du principe que l\u2019ensemble du syst\u00e8me est compromis, et pas seulement en supprimant le package
\n \tCr\u00e9ez un catalogue d\u2019IA de confiance – utilisez JFrog AI Catalog comme syst\u00e8me d\u2019enregistrement unique pour les mod\u00e8les, les MCP, les comp\u00e9tences et les packages d\u2019IA<\/p>\n
Points cl\u00e9s \u00e0 retenir
\nLe SDLC a chang\u00e9. Les d\u00e9veloppeurs ne sont plus les seuls acteurs du pipeline, ils sont d\u00e9sormais les orchestrateurs de flottes d\u2019agents, chacun consommant des ressources d\u2019IA \u00e0 la vitesse de la machine. Les cybercriminels embo\u00eetent le pas aux \u00e9quipes dans tous les nouveaux environnements qu\u2019elles adoptent, sans \u00e9pargner leurs processus pilot\u00e9s par des agents.<\/p>\n
L\u2019incident LiteLLM a agi comme une v\u00e9ritable sonnette d\u2019alarme. L\u2019\u00e9v\u00e9nement a mis en lumi\u00e8re qu\u2019une passerelle d\u2019intelligence artificielle open source positionn\u00e9e au centre de votre architecture n\u2019a rien de neutre et constitue au contraire\u00a0 une cible de premier choix. Tout l\u2019enjeu est d\u00e9sormais de d\u00e9terminer si votre architecture de confiance est taill\u00e9e pour faire face \u00e0 cette nouvelle donne.<\/p>\n
Chez JFrog, notre conviction est que la s\u00e9curit\u00e9 doit faire partie int\u00e9grante de la plateforme d\u00e8s l\u2019origine, plut\u00f4t que d\u2019\u00eatre pr\u00e9sum\u00e9e ou greff\u00e9e a posteriori. Concr\u00e8tement, il s\u2019agit de s\u00e9lectionner les packages open source, d\u2019encadrer les mod\u00e8les d\u2019IA, de s\u00e9curiser les serveurs MCP au moyen d\u2019un registre dot\u00e9 de contr\u00f4les de conformit\u00e9 pr\u00e9ex\u00e9cutifs et de faire transiter l\u2019ensemble des flux d\u2019IA par une passerelle ax\u00e9e sur la s\u00e9curit\u00e9.<\/p>\n
En effet, dans un univers dop\u00e9 \u00e0 l\u2019intelligence artificielle, la rapidit\u00e9 ne constitue un atout qu\u2019\u00e0 la condition absolue de reposer sur des bases s\u00fbres.<\/p>\n
R\u00e9servez une d\u00e9mo avec l\u2019un de nos experts pour assister \u00e0 une d\u00e9monstration en direct des solutions JFrog. Vous pouvez \u00e9galement en savoir plus sur JFrog AI Catalog, le JFrog MCP Registry et JFrog Curation.<\/p>\n","protected":false},"excerpt":{"rendered":"
Attaquants de la cha\u00eene d\u2019approvisionnement_863x300 L\u2019atteinte \u00e0 la cha\u00eene d\u2019approvisionnement de LiteLLM en date du 24 mars 2026 n\u2019est pas un \u00e9v\u00e9nement isol\u00e9. C\u2019est le volet le plus r\u00e9cent, et sans doute le plus mena\u00e7ant, d\u2019un r\u00e9pertoire d\u2019attaques en mutation que JFrog Security Research analyse depuis des ann\u00e9es. L\u2019objectif a \u00e9volu\u00e9\u00a0: les cibles ne sont …<\/p>\n","protected":false},"author":590,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[9212],"tags":[],"class_list":["post-174379","post","type-post","status-publish","format-standard","hentry","category-non-classifiee"],"yoast_head":"\n