Supply chain des modèles : poids, dépendances, provenance

Pourquoi la supply chain est la surface d'attaque la plus négligée

Quand on évalue la sécurité d'un système d'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire, le réflexe est de regarder le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, les entrées utilisateur, les permissions de l'API. C'est nécessaire, mais insuffisant : avant même que le modèle ne traite une seule requête, il a déjà traversé une chaîne d'approvisionnement longue — un jeu de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire assemblé par des tiers, un entraînement effectué sur une infrastructure externe, des poids publiés sur un registre public, un chargement via des bibliothèques dont personne dans l'équipe n'a lu le code, un déploiement qui hérite de dépendances transitives sur trois niveaux.

Chacun de ces maillons peut être compromis indépendamment des autres. Un modèle dont le code de fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire est irréprochable peut être livré avec des poids piégés. Une équipe qui audite ses propres scripts d'entraînement peut charger, sans le savoir, un fichier pickle qui exécute du code arbitraire au moment même du torch.load(). C'est cette dimension distribuée et largement invisible qui rend la supply chain IA différente d'une supply chain logicielle classique : la donnée d'entrée est du code d'exécution.

Un modèle IA n'est jamais un bloc unique de confiance. C'est un empilement de composants — dataset, poids, code de chargement, dépendances, infrastructure de déploiement — dont chacun peut avoir une provenance différente et un niveau de confiance différent. Traiter le modèle comme un tout homogène revient à ignorer où se situe réellement le risque.

Cartographie de la chaîne d'approvisionnement

La chaîne se découpe en cinq étapes principales, chacune avec son point d'injection caractéristique.

Ce schéma sert de fil conducteur au reste du chapitre : chaque section suivante détaille un maillon et son contrôle associé.

Les poids du modèle : le vecteur le plus sous-estimé

Les poids d'un modèle sont souvent traités comme une simple donnée binaire — un gros fichier numérique qu'on télécharge et qu'on charge en mémoire. C'est une erreur qui a des conséquences directes, parce que le format historique de sérialisation utilisé par PyTorch, pickle, n'est pas un format de données : c'est un format d'exécution.

Le module pickle de Python permet de sérialiser des objets arbitraires, y compris des instructions qui, à la désérialisation, invoquent des fonctions Python. Un fichier .pt ou .bin malveillant peut donc contenir, en plus des poids, un appel à os.system, subprocess.Popen ou tout autre exécuteur de commande. Le code s'exécute au moment du chargement, avant même que le modèle ne serve la moindre inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire. Un simple torch.load('model.bin') sur un fichier téléchargé depuis une source non vérifiée peut donc suffire à compromettre la machine qui l'exécute — poste de développeur, serveur d'entraînement ou nœud d'inférence en production.

Des chercheurs en sécurité ont démontré à plusieurs reprises la faisabilité de payloads pickle malveillants déposés sur des dépôts de modèles publics, capables d'obtenir une exécution de code arbitraire dès le chargement. Ce n'est pas un vecteur théorique : c'est un vecteur documenté et reproductible avec les outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire standard de l'écosystème.

Le format safetensors, développé notamment pour répondre à ce problème, sépare strictement les données numériques de toute logique d'exécution : il ne peut contenir que des tenseurs, pas de code. Charger un fichier .safetensors ne peut pas déclencher d'exécution arbitraire, quelle que soit la source. C'est aujourd'hui le format à privilégier par défaut pour tout poids provenant d'un tiers, et de plus en plus de hubs de modèles l'imposent ou le recommandent fortement.

Un deuxième piège, plus insidieux, concerne l'option trust_remote_code=True que l'on rencontre fréquemment lors du chargement de modèles depuis des bibliothèques comme transformers. Certains modèles publiés sur des hubs publics embarquent du code Python personnalisé (architecture non standard, tokenizer spécifique) qui est exécuté directement sur la machine de l'utilisateur lors du chargement, sans sandbox. Activer cette option revient à faire confiance intégralement à l'auteur du dépôt — un choix qui doit être explicite, documenté et réservé aux sources dont la provenance a été vérifiée, jamais activé par défaut ou par habitude.

Dépendances logicielles : du framework au paquet obscur

Un système d'IA repose rarement sur une seule bibliothèque. Un pipeline d'entraînement ou d'inférence typique importe un framework (PyTorch, TensorFlow, JAX), une bibliothèque de modèles (transformers, diffusers), des outils de tokenisationtokenisationIADécoupage d'un texte en unités (tokens) que le modèle traite. La fenêtre de contexte se compte en tokens, pas en mots.Voir dans le glossaire, de logging, de sérialisation, de calcul numérique — et chacune de ces bibliothèques importe elle-même des dizaines de dépendances transitives. Un projet Python moyen dans ce domaine compte facilement plusieurs centaines de paquets dans son arbre de dépendances complet, dont la grande majorité n'a jamais été auditée individuellement par l'équipe qui les utilise.

Cette profondeur crée deux familles d'attaques bien documentées dans l'écosystème des gestionnaires de paquets (PyPI, npm, conda) :

• Le typosquatting — publier un paquet au nom volontairement proche d'un paquet légitime et très utilisé (une lettre inversée, un tiret en plus, un pluriel différent), en pariant sur une erreur de frappe lors de l'installation.
• La dependency confusion — exploiter la résolution de noms entre dépôt interne et dépôt public : si une entreprise utilise en interne un paquet nommé acme-model-utils sans jamais l'avoir publié sur PyPI, un attaquant peut publier un paquet public du même nom avec un numéro de version plus élevé ; certains gestionnaires de paquets mal configurés iront chercher la version la plus haute, y compris sur le registre public, et installeront le paquet malveillant à la place du paquet interne attendu.

Une équipe data science installe un paquet censé accélérer le chargement de tenseurs, trouvé via une recherche rapide et un nom proche d'un outil connu. Le paquet exécute, lors de son installation (setup.py ou hook post-install), un script qui exfiltre les variables d'environnement de la machine — dont, potentiel­lement, des clés d'API de fournisseurs de modèles ou des identifiants de stockage cloud. Aucune ligne du code d'entraînement n'a été modifiée : la compromission est entièrement passée par l'installation de la dépendance.

Ce risque est amplifié dans l'écosystème IA par la vitesse de publication de nouveaux outils : les pratiques de vérification qui commencent à être matures dans le logiciel généraliste (revue de licence, scan de vulnérabilité systématique, gel des versions) sont encore inégalement appliquées sur les paquets spécifiques au machine learningapprentissage automatiqueIABranche de l'IA où le programme dégage lui-même ses règles à partir d'exemples, au lieu de les recevoir d'un développeur. C'est ce déplacement des règles écrites vers les régularités apprises qui définit l'IA moderne.Voir dans le glossaire, souvent installés « à la volée » dans des notebooks ou des environnements de recherche peu contrôlés.

Provenance, SBOM et signatures : vérifier plutôt que supposer

La réponse structurelle à ces deux familles de risques — poids piégés et dépendances compromises — n'est pas la vigilance individuelle mais la vérifiabilité systématique de la provenance à chaque étape de la chaîne.

Trois briques se combinent :

1. Le SBOM (Software Bill of Materials) et son équivalent ML-BOM. Un inventaire exhaustif et machine-readable de tous les composants d'un système — bibliothèques, versions exactes, licences, hachages — auquel s'ajoute, pour le ML-BOM, les jeux de données utilisés, les poids de modèles chargés et leur origine. Sans cet inventaire, une équipe ne peut tout simplement pas répondre à la question « sommes-nous exposés à la vulnérabilité X ? » sans audit manuel complet.
2. Les hachages et signatures cryptographiques. Chaque fichier de poids publié devrait être accompagné d'une empreinte (SHA-256 a minima) permettant de vérifier qu'aucun octet n'a été modifié entre la publication par l'auteur et le téléchargement par l'utilisateur. Au-delà du simple hachage, des cadres comme Sigstore permettent de signer cryptographiquement un artefact et de lier cette signature à une identité vérifiable, sans gestion manuelle de clés privées.
3. Les attestations de provenance de type SLSA / in-toto. Ces cadres formalisent une chaîne de preuves vérifiables sur comment un artefact a été produit : quel code source, sur quelle infrastructure de build, à quelle étape du pipeline. Appliqués à un modèle, ils permettent de répondre non seulement à « ce fichier est-il intact ? » mais à « ce fichier a-t-il bien été produit par le pipeline d'entraînement officiel, et non injecté après coup dans le registre ? ».

Un hash publié sur la même page que le fichier ne protège de rien : si l'attaquant contrôle la page, il contrôle aussi le hash affiché. La vérification n'a de valeur que si l'empreinte de référence provient d'un canal indépendant de celui qui sert le fichier — dépôt de commit signé, registre de provenance séparé, ou signature liée à une identité vérifiable via une autorité tierce comme Sigstore.

Ces pratiques restent minoritaires dans l'écosystème IA comparé au logiciel traditionnel, en partie parce que la culture du domaine vient de la recherche, où la reproductibilité scientifique a longtemps prévalu sur la vérifiabilité sécuritaire. Cela change progressivement, poussé par les hubs de modèles eux-mêmes, qui commencent à afficher des indicateurs de sécurité (scan automatique des fichiers pickle, badges de format sûr) — mais ces indicateurs restent des signaux d'aide à la décision, pas des garanties absolues, et ne dispensent pas d'une vérification indépendante pour tout déploiement sensible.

Étude de cas : PoisonGPT et l'usurpation de nom sur un hub public

En 2023, une démonstration publique a mis en scène un scénario resté depuis une référence pédagogique du domaine : des chercheurs ont pris un modèle open source reconnu, y ont introduit chirurgicalement une distorsion factuelle ciblée (le modèle donnait une réponse fausse à une question historique précise tout en se comportant normalement sur le reste), puis ont republié ce modèle modifié sur un hub public sous un nom très proche du modèle original, imitant l'organisation légitime.

Le résultat mesurable : le modèle piégé réussissait les benchmarks standards presque aussi bien que l'original, ce qui le rendait indiscernable lors d'une évaluation superficielle, tout en produisant une désinformation ciblée sur le sujet choisi. L'expérience visait à démontrer un point simple mais souvent sous-estimé : rien dans le processus habituel de sélection d'un modèle sur un hub public — nom familier, description convaincante, score aux benchmarks — ne garantit que les poids téléchargés correspondent réellement à ceux publiés par l'organisation qu'on croit reconnaître.

Vérifier le nom d'un modèle et son organisation affichée ne suffit pas. Il faut recouper l'identifiant exact du dépôt (namespace complet, pas seulement le nom affiché), le hash des poids par rapport à une source de référence indépendante, et, quand c'est disponible, la chaîne de commits ou l'historique de publication du dépôt — un modèle légitime a en général un historique cohérent, un dépôt cloné pour l'occasion n'en a pas.

Ce scénario illustre pourquoi la provenance ne peut pas reposer sur la réputation perçue d'un nom : un attaquant motivé peut reproduire cette réputation apparente à moindre coût. Seule une vérification cryptographique ancrée dans un canal indépendant ferme réellement cette porte.

Checklist de durcissement de la supply chain

Aucun de ces contrôles n'est suffisant isolément. C'est leur combinaison, appliquée systématiquement plutôt que ponctuellement, qui réduit réellement la surface d'attaque — un seul maillon non vérifié suffit à annuler les efforts sur tous les autres.

Ce qu'il faut retenir

La sécurité d'un système d'IA ne se limite pas à la robustesse du modèle face aux entrées malveillantes : elle commence en amont, dans la manière dont les poids, le code et les dépendances arrivent jusqu'à l'environnement de production. Le format de sérialisation des poids, la profondeur de l'arbre de dépendances et l'absence de vérification cryptographique systématique constituent, ensemble, une surface d'attaque au moins aussi large que celle exposée par l'interface du modèle lui-même.

Traiter cette chaîne comme un ensemble de maillons vérifiables — plutôt que comme une boîte noire de confiance implicite — est la seule approche qui tienne à l'échelle d'une organisation. Le chapitre suivant s'appuie sur cette cartographie pour détailler les mécanismes de détection d'anomalies au moment de l'inférence, une fois le système effectivement en production.