Vous avez corrigé LiteLLM, mais connaissez-vous votre surface d’exposition liée à l’IA ?

Pendant une courte période, un package open source très utilisé dans l’écosystème de l’IA a été compromis par un malware dérobant des identifiants.

LiteLLM, une passerelle de modèles utilisée pour acheminer les requêtes vers plus de 100 fournisseurs de LLM, a été téléchargée des millions de fois par jour. Pendant cette brève période, les versions malveillantes ont probablement été téléchargées des dizaines de milliers de fois avant d’être détectées.

En théorie, cela aurait dû être rassurant : le projet disposait de certifications de conformité, des outils de sécurité étaient en place, et le problème a été découvert puis corrigé rapidement. Mais c’est précisément là que le bât blesse.

Car cet incident ne concernait pas seulement une dépendance compromise. Il nous a rappelé comment les systèmes d’IA modernes sont réellement mis en échec : pas en surface, mais à travers des couches que nous ne voyons pas entièrement.

Un premier signe de l’impact se manifeste déjà. La start-up de recrutement par IA Mercor a confirmé qu’elle faisait partie des « milliers de » victimes indirectement touchées par l’attaque de la chaîne d’approvisionnement de LiteLLM. Dans son cas, la compromission ne s’est pas arrêtée à un package vulnérable : elle aurait entraîné une exfiltration de données à grande échelle, notamment du code source, après que des identifiants volés ont été utilisés pour accéder à des systèmes internes.

C’est ce que la plupart des équipes ne voient pas. Le risque ne réside pas dans la dépendance elle-même, mais dans ce à quoi elle peut accéder lors de l’exécution. Dès que LiteLLM se trouve dans le chemin d’exécution entre votre application et les fournisseurs de modèles, il devient un relais vers tout ce qui se trouve derrière : API, outils, workflows d’agents et données sensibles.

Mercor et les autres n’ont pas été victimes d’une violation simplement parce qu’ils « utilisaient LiteLLM ». Ils l’ont été en raison des connexions de LiteLLM.

Lors de la compromission initiale de LiteLLM, le malware était relativement rudimentaire. Il était bruyant, faisait planter les machines et a été détecté. Une version plus discrète, conçue pour exfiltrer furtivement des identifiants auprès de fournisseurs de modèles, d’API et de workflows d’agents, aurait pu passer inaperçue pendant des semaines.

Et si cela s’était produit, la plupart des équipes n’auraient pas su ce qui était réellement exposé. Elles auraient su qu’elles utilisaient LiteLLM.

Elles n’auraient pas su :

• Quels modèles étaient acheminés par son intermédiaire

• Quels fournisseurs étaient concernés

• À quels outils et systèmes ces modèles pouvaient accéder

• Comment ce risque se propageait dans leurs applications

Voilà le manque de visibilité. C’est pourquoi les incidents comme celui-ci ne sont plus de simples problèmes de chaîne d’approvisionnement : ils relèvent avant tout de la visibilité sur les systèmes d’IA.

Lorsque la compromission de LiteLLM a été révélée, la plupart des équipes ont réagi comme on pouvait s’y attendre. Elles ont vérifié leurs dépendances, identifié les versions vulnérables et rapidement installé un correctif ou verrouillé une version sûre. Du point de vue de la sécurité applicative traditionnelle, c’est du travail bien fait.

Mais cela soulève une question plus intéressante, que la plupart des équipes ne prennent pas le temps de poser : Qu’avez-vous réellement corrigé ?

Il faut aller au-delà de l’identification des endroits où LiteLLM était utilisé : découvrir ce qu’il faisait au sein de votre système, à quoi il était connecté et quels risques il introduisait au-delà du package lui-même. Car dans les applications d’IA, c’est là que les choses se compliquent.

Les limites de la visibilité traditionnelle

LiteLLM n’est pas une bibliothèque comme les autres, discrètement installée dans une base de code. Elle se trouve directement dans le chemin d’exécution entre votre application et les modèles dont elle dépend. Elle achemine les requêtes, fait abstraction des fournisseurs et façonne en définitive le comportement de votre système à l’exécution.

Ainsi, lorsque LiteLLM est compromise, l’impact ne se limite pas aux dépôts qui contiennent le package. Il s’étend aux modèles appelés par son intermédiaire, aux fournisseurs concernés, aux outils auxquels ces modèles peuvent accéder et aux workflows d’agents qui en dépendent.

C’est là que la plupart des équipes perdent en visibilité. Une simple ligne de code qui spécifie un modèle peut sembler anodine, mais elle encode toute une série de décisions concernant les fournisseurs, les fonctionnalités et les accès, qui ne sont consignées nulle part dans un graphe de dépendances.

Multipliez cela entre les dépôts, les équipes et les workflows d’agents en constante évolution, et vous obtenez autre chose qu’un simple problème de dépendances : un système difficile à voir ou à comprendre dans son ensemble

Le problème qu’Evo AI-SPM est conçu pour résoudre

Au lieu de se concentrer uniquement sur les dépendances présentes, Evo se concentre sur la manière dont l’IA est utilisée. Dans le cas de LiteLLM, cela signifie l’identifier comme une passerelle de modèles, cartographier les fournisseurs et les modèles dont elle achemine les requêtes, découvrir les outils et API avec lesquels ces modèles interagissent et relier le tout aux workflows d’agents qui définissent le comportement du système.

Vous obtenez ainsi un AI-BOM : une cartographie évolutive du système d’IA lui-même, et pas seulement des composants qui le constituent.

Pourquoi le contexte change tout

Ce contexte supplémentaire transforme fondamentalement la manière dont les équipes réagissent aux incidents. Si vous savez seulement que LiteLLM est compromise, la suite est évidente : corrigez le problème. Mais dès que vous comprenez comment elle est utilisée, votre réponse gagne en nuance.

Vous pouvez commencer par vous demander si le trafic est acheminé vers des fournisseurs de modèles non approuvés, quels agents dépendent de ce chemin, quels systèmes externes y sont exposés et si des politiques encadrent ces interactions. C’est ce qui distingue une réaction à une vulnérabilité de la compréhension de votre exposition réelle.

C’est déjà ainsi que les applications d’IA sont conçues

Cela reflète la multiplication des applications alimentées par l’IA qui sont déjà en cours de développement. Un développeur peut utiliser un framework pour orchestrer un agent, s’appuyer sur LiteLLM pour faire abstraction de l’accès aux modèles et connecter cet agent à des outils ou API externes pour accomplir des tâches. Du point de vue traditionnel, cela apparaît comme une dépendance vulnérable. À l’échelle du système, il s’agit d’une chaîne de décisions, d’intégrations et de comportements qui va bien au-delà du package lui-même.

L’IA dont vous ignorez la présence

Les équipes sont souvent surprises de découvrir la quantité d’IA déjà présente dans leurs environnements. Beaucoup pensent n’en être qu’au début de leur adoption de l’IA, avant de constater que des passerelles de modèles, des frameworks d’orchestration et de nouveaux modèles d’agents sont utilisés à différents endroits de leurs bases de code.

Rien de tout cela n’est centralisé, une grande partie n’est pas encadrée, et pourtant, ces éléments font déjà partie des systèmes de production. Les incidents comme la compromission de LiteLLM ne créent pas cette complexité : ils la révèlent.

Vous avez toujours besoin du SCA (mais pas seulement du SCA)

Il ne s’agit pas d’un échec de l’analyse de la composition logicielle (SCA). Des outils comme Snyk Open Source signalent les versions compromises de LiteLLM, indiquent dans quels dépôts elles sont présentes — y compris en tant que dépendances transitives — alertent rapidement les équipes et fournissent des conseils clairs pour y remédier.

Ce signal est fondamental : sans lui, les équipes ne sauraient même pas qu’un problème existe. Mais le SCA est conçu pour répondre à une question bien précise : « Cette dépendance est-elle vulnérable ? » Le problème, c’est que les systèmes d’IA modernes ne se limitent pas aux dépendances.

Face à ce type d’incident, on entend souvent : « Le SCA l’a déjà détecté. » C’est vrai, mais cela revient à supposer que la dépendance constitue le système. En réalité, elle n’en est que le point d’entrée. Le système englobe tout ce que cette dépendance rend possible : l’accès aux modèles, l’exécution des outils, l’orchestration des agents et la prise de décision dynamique. Si vous ne voyez pas cette couche, vous ne comprenez pas pleinement où se situe votre risque.

La compromission de LiteLLM n’est qu’un exemple, mais elle montre clairement l’évolution : si vous ne regardez que les dépendances, vous ne voyez pas le système. Le SCA vous indique qu’un problème existe ; Evo vous aide à comprendre ce qu’il implique dans le contexte de votre système d’IA et vous donne les moyens de le contrôler.

Comment utiliser Evo AI-SPM

Avec Evo AI-SPM, il est facile de voir rapidement ce qui se passe dans votre propre environnement. En quelques minutes, vous pouvez :

• Identifier où LiteLLM (et d’autres passerelles de modèles similaires) est présent dans vos dépôts

• Voir quels fournisseurs et modèles sont utilisés par leur intermédiaire

• Découvrir les outils, API, agents et workflows connectés

• Détecter l’« IA fantôme », invisible aux outils de sécurité traditionnels

• Appliquer des politiques pour contrôler les usages autorisés à l’avenir

La première analyse surprend la plupart des équipes, car la réalité est la suivante : si vous développez avec l’IA, vous avez déjà une chaîne d’approvisionnement de l’IA. Vous ne la voyez peut-être pas encore.

Snyk Open Source vous aide à détecter les vulnérabilités.

Evo AI-SPM vous révèle le système et vous aide à le sécuriser.

Commencez par là.