Cartographier la chaîne d’approvisionnement de l’IA : où LiteLLM 1.107.0 aurait dû être arrêté

Le 21 octobre, une version compromise de LiteLLM, la 1.107.0, a été publiée sur PyPI. Elle s’est aussi retrouvée dans les images de conteneur officielles du projet. Deux jours plus tard, Microsoft a publié son analyse : le paquet installait un startup hook Python, et la charge malveillante ramassait des données d’authentification dans les outils de développement, les applications d’IA, les environnements cloud, les navigateurs et l’infrastructure.

Le détail qui compte tient en une phrase du rapport de Microsoft : une application n’avait pas besoin d’importer LiteLLM pour que la charge s’exécute.

« On n’utilise pas ce paquet » : pas une réponse

Python traite les fichiers .pth de site-packages chaque fois que l’interpréteur démarre. Une ligne de ce fichier qui commence par import est exécutée. Un paquet qui en dépose un exécute du code dans chaque processus Python de cette machine ou de cette image, qu’un programme l’importe ou non.

Ça fait tomber la première question que la plupart des équipes ont posée : « Quelles applications dépendent de LiteLLM ? » La question utile était : « Quels environnements l’ont installé ? » Ce sont deux listes différentes. Le portable d’un développeur qui a essayé une gateway IA une fois, une image CI partagée, un serveur de notebooks et le conteneur d’un agent peuvent tous contenir un paquet qu’aucune application ne déclare.

Un scan de dépendances qui lit requirements.txt voit ce que votre code demande. Il ne voit pas ce que l’environnement exécute au démarrage.

La gateway IA, une cible de choix

LiteLLM est une gateway : une seule interface devant plusieurs fournisseurs de modèles. Les organisations qui font rouler plusieurs modèles font passer leur trafic par ce genre de composant. Ces composants détiennent donc les clés de tous les fournisseurs à la fois, et sont souvent à côté des identifiants cloud des agents qui les appellent.

Le plan de contrôle de l’IA fait donc partie de votre supply chain logicielle, avec un rayon d’impact plus grand que la plupart des bibliothèques. Un paquet de journalisation compromis fait fuir des logs. Une gateway compromise peut faire fuir toutes les clés d’API de modèles, plus les identifiants cloud et d’outils de chaque agent sur le même hôte.

La carte en huit couches

Pour chaque agent ou application d’IA, tracez un chemin, du modèle jusqu’aux données qu’il touche. À chaque couche, posez une seule question : où la provenance ou l’intégrité est-elle vraiment vérifiée, et par qui ?

1. Le modèle. Quel modèle, quelle version, de quel fournisseur ou registre ? Vérifié par : une version ou un digest figé, ou « ce que le fournisseur sert aujourd’hui ».
2. La gateway. Qu’est-ce qu’il y a entre votre code et le modèle : un proxy, un routeur, une gateway hébergée ? Vérifié par : les mêmes contrôles de mise en production que n’importe quel service, ou aucun parce que c’était « juste de la config ».
3. Le SDK et les paquets. Quelles bibliothèques appellent le modèle, et qu’est-ce qu’elles amènent avec elles ? Vérifié par : un lockfile avec empreintes, une installation depuis un miroir que vous contrôlez, et un délai avant d’admettre les nouvelles versions.
4. Le conteneur. Quelle image de base, quelles images en amont ? Vérifié par : des images figées par digest et des signatures vérifiées, pas un tag latest modifiable. Les images officielles de LiteLLM contenaient aussi la charge.
5. L’exécution. Où le processus roule-t-il, et qu’est-ce qui est installé d’autre à cet endroit ? Vérifié par : un inventaire de l’environnement installé, startup hooks compris, pas seulement des dépendances déclarées.
6. Les identifiants. Quels secrets le processus peut-il lire : variables d’environnement, fichiers montés, rôles d’instance, trousseau d’un développeur ? Vérifié par : des identifiants éphémères et limités, pour qu’un vol expire avant d’être utile.
7. Les outils et MCP servers. Quels outils l’agent peut-il appeler, et d’où vient chacun ? Vérifié par : une liste d’autorisation de serveurs approuvés, à des versions figées. Un MCP server local, c’est un paquet, avec sa propre supply chain.
8. Les données. Au bout du compte, que peut lire ou écrire ce chemin ? Vérifié par : des accès accordés par tâche, pour que la compromission d’une couche du dessus soit bornée ici.

La plupart des premiers relevés trouvent une vérification aux couches 3 et 4 pour les applications en production, et presque nulle part ailleurs. Les gateways, les environnements d’exécution des agents et les postes des développeurs n’en ont généralement aucune.

Cinq contrôles qui auraient changé l’issue

• Une quarantaine pour les nouvelles versions. Installez depuis un miroir interne qui admet une nouvelle version d’un paquet seulement après un délai d’attente. Une version retirée en quelques heures n’atteint jamais vos builds.
• Des lockfiles avec empreintes. Un build qui installe exactement l’artefact examiné ne peut pas prendre une nouvelle version en silence.
• Des images figées par digest. Désignez les images de conteneur par leur digest, et rebâtissez selon votre calendrier, pas celui de l’amont.
• La surveillance des startup hooks. Levez une alerte sur tout fichier .pth nouveau ou modifié dans les images de production et sur les postes des développeurs. La liste est courte, et elle change rarement pour de bonnes raisons.
• Le contrôle du trafic sortant des hôtes IA. Une gateway doit joindre ses fournisseurs de modèles. Elle n’a pas besoin du reste d’Internet. Une liste d’autorisation transforme un vol d’identifiants en connexion bloquée, et en near miss que vous pouvez compter.

Quand une compromission est annoncée, la première heure sert à répondre à une question : où cette version a-t-elle roulé ? Si vous tenez déjà un inventaire des agents IA, les champs exécution et identifiants vous donnent la liste des hôtes et celle des secrets à renouveler. Sans lui, vous cherchez.

Besoin d’un deuxième regard ?

Notre évaluation de la sécurité de l’IA générative dresse cette carte pour vos agents et vos applications d’IA. On trace chaque chemin, on note où l’intégrité est vérifiée et on fait de chaque couche non vérifiée un constat avec un responsable et une correction. C’est de l’assurance de supply chain ordinaire, appliquée aux composants qui détiennent maintenant vos clés les plus précieuses.

Trois questions à poser à votre équipe

1. Si un paquet qu’on n’a jamais déclaré était compromis aujourd’hui, pourrait-on lister chaque environnement où il est installé ?
2. Lequel de nos systèmes détient les clés de plus d’un fournisseur de modèles, et qu’est-ce qui d’autre peut les lire ?
3. Combien de temps après sa publication une nouvelle version atteint-elle nos builds : quelques heures, ou un délai qu’on a choisi ?