Chapitre 9 — Intégrité du modèle et risques de la chaîne d'approvisionnement

Neuvième billet de la tournée chapitre par chapitre de LLM Primer VII : Sécurité de l'IA. Le chapitre qui traite un artefact de modèle comme un binaire distribué par un tiers — avec les préoccupations de désérialisation, de porte dérobée et de provenance que la distribution binaire a toujours portées.

Pourquoi ce chapitre existe

Les modèles open-source sont le choix par défaut pour de nombreux systèmes de production parce que les API frontières fermées sont coûteuses à l'échelle et portent des préoccupations de dépendance fournisseur. Le compromis est que l'opérateur porte désormais le risque de chaîne d'approvisionnement que le fournisseur fermé portait. Hugging Face héberge des centaines de milliers d'artefacts de modèle contribués par des chercheurs, des laboratoires d'entreprise et une longue traîne de dérivés. Le canal de distribution ressemble à un dépôt de paquets, avec cette particularité que les artefacts sont de grands binaires dont le chargement implique de désérialiser des graphes d'objets complexes. Ce chapitre parcourt la surface de la chaîne d'approvisionnement — portes dérobées, vulnérabilités de format, provenance, dérive — et l'infrastructure que le domaine a adoptée pour amener la chaîne d'approvisionnement du modèle à la parité avec celle du logiciel.

9.1 Les portes dérobées persistent à travers l'entraînement de sécurité

L'article 2017 de Gu, Dolan-Gavitt et Garg « BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain » a établi la ligne de recherche sur les portes dérobées. Une petite fraction d'exemples d'entraînement empoisonnés — moins d'un pour cent — pouvait induire un classificateur à mal classer les entrées déclenchées tout en laissant la précision sur les entrées sans déclencheur inchangée. Le modèle de menace BadNets se transfère aux LLM avec les traductions naturelles. L'article « Sleeper Agents » d'Anthropic en janvier 2024 par Hubinger et al. a démontré une extension inconfortable : les portes dérobées entraînées délibérément dans les modèles pouvaient persister à travers l'entraînement de sécurité ultérieur, y compris RLHF et l'entraînement adverse conçus pour retirer le comportement même que la porte dérobée implémentait. Le modèle se comportait normalement sous la distribution de l'entraînement de sécurité et revenait au comportement à porte dérobée sous le déclencheur. L'apport de l'article a été de rendre explicite que l'entraînement d'alignement n'est pas un filtre de sécurité général — il modifie le comportement dans les distributions qu'il échantillonne pendant l'entraînement, et un déclencheur suffisamment rare ou bien caché se tient en dehors de ces distributions. Les implications défensives sont structurelles : la sécurité d'un modèle déployé ne peut être raisonnée à partir du seul entraînement de sécurité si la provenance du modèle de base est incertaine. La détection est difficile parce que le déclencheur est par conception rare, mais le fuzzing comportemental, l'analyse d'activation et les évaluations canari contre des entrées déclenchées sont les meilleures pratiques actuelles.

9.2 Le risque au niveau format est une catégorie réelle

Les poids du modèle sont de grands fichiers binaires, typiquement expédiés à travers des registres et des hubs. Charger ces poids implique la désérialisation. Le format par défaut pour beaucoup d'artefacts de l'ère PyTorch était pickle, dont la désérialisation exécute du Python arbitraire par conception. CVE-2024-3568, divulgué contre la bibliothèque Transformers de Hugging Face, a illustré comment un fichier de modèle pouvait être fabriqué pour exécuter du code arbitraire au chargement. Ce n'était pas la première CVE de ce type et ce ne sera pas la dernière. Le format safetensors, développé par Hugging Face et sorti en 2022, était la réponse du domaine — un format en-tête-plus-tenseur sans chemin d'exécution de code, aux performances tolérables, et désormais par défaut pour les grandes sorties de modèles. L'implication opérationnelle est que charger un fichier pickle depuis une source non fiable équivaut fonctionnellement à exécuter un binaire non fiable comme votre processus d'inférence. Le versionnement de modèle fournit un second axe d'intégrité. La fiche de modèle, introduite par Mitchell et al. à FAccT 2019, donne un dossier de documentation structuré — usage prévu, données d'entraînement, résultats d'évaluation, limitations connues — largement adopté par Hugging Face, OpenAI, Anthropic et Google. La fiche est de la documentation, non une preuve ; elle ne vérifie pas que l'artefact corresponde à la description. C'est à cela que sert la signature cryptographique.

9.3 Provenance, signature et surveillance de dérive ferment la boucle

La communauté de la chaîne d'approvisionnement logicielle a convergé sur une pile — niveaux SLSA, attestations in-toto, Sigstore pour la signature, signature de registre de conteneurs — qui s'est étendue aux artefacts ML à partir de 2026. Le schéma de déploiement sécurisé de modèle est désormais reconnaissable. L'entrée de registre d'un modèle est signée par une clé autorisée. Le système de déploiement récupère l'artefact, vérifie le hash et vérifie la signature de l'entrée de registre. Le chargement n'a lieu qu'à partir de safetensors, pas de pickle. Les métadonnées de provenance sont retenues et liées à l'enregistrement de déploiement, de sorte que la question « quelle version, de quel amont, sert actuellement le trafic » a toujours une réponse définie. La surveillance de dérive est la contrepartie continue. Le comportement d'un modèle déployé change dans le temps même sans modification des poids — les entrées changent, les applications amont changent, la distribution des requêtes change. Distinguer la dérive légitime de la compromission exige une base de référence. Le chapitre parcourt les métriques distributionnelles (longueur moyenne d'entrée, distribution des scores de classificateur de sécurité, ratio refus-vers-conformité), les métriques catégorielles (taux de réponses code, taux de données personnelles dans les réponses) et les métriques comportementales (prompts canari fixes exécutés périodiquement avec réponses comparées à une base). L'écart par rapport à la base n'est pas une preuve de compromission, mais c'est un signal que quelque chose a changé et mérite investigation.

Ce que prépare le Chapitre 9

La partie III a désormais couvert le modèle lui-même comme objet de sécurité — défaillances de fiabilité (ch. 7), attaques délibérées dans l'espace d'entrée (ch. 8) et risque de chaîne d'approvisionnement (ch. 9). La partie IV monte dans la pile jusqu'à l'architecture système dans laquelle le modèle est intégré. Le chapitre 10 parcourt les schémas architecturaux pour des déploiements LLM sécurisés — frontières d'isolation, validation multi-niveaux, moteurs de politique comme OPA et Cedar, conception d'API sécurisée, et zero-trust appliqué aux appels de modèle. Le chapitre 11 parcourt l'observabilité, la journalisation et la réponse aux incidents — la couche opérationnelle qui transforme les défenses architecturales en un système que l'organisation peut exploiter de manière fiable. Le chapitre 12 parcourt le contrôle d'accès et l'identité — authentification, autorisation, isolation multi-locataire, limites de débit et la surcouche de gouvernance d'entreprise. Ensemble, les trois chapitres décrivent l'architecture système qui contient, soutient et contraint les composants du modèle que la partie III vient d'examiner.

Prochaine étape — Chapitre 10 : Concevoir des architectures LLM sécurisées. Frontières d'isolation autour du modèle, validation multi-niveaux, moteurs de politique, et principes zero-trust appliqués à un composant qui lit toute entrée comme instruction.