Risques liés aux modèles, aux données et à la chaîne d’approvisionnement

Une application LLM est constituée de nombreux composants tiers : modèles de base, affinages, jeux de données, représentations vectorielles, plug-ins et dépendances logicielles classiques. Chaque maillon peut servir de point d’insertion pour une compromission.

Contrairement aux logiciels traditionnels, les artefacts d’apprentissage automatique sont souvent de gros binaires opaques récupérés depuis des plateformes publiques dont la provenance est peu fiable. Un fichier de poids empoisonné ou un jeu de données contenant une porte dérobée est difficile à repérer par simple inspection.

Sécuriser la chaîne consiste à suivre et à vérifier chaque composant, de la source jusqu’à la production.

L’empoisonnement des données manipule les données d’entraînement ou d’affinage afin de corrompre le modèle obtenu. Un attaquant capable de contribuer à une fraction, même réduite, des exemples d’entraînement peut modifier le comportement de manière mesurable.

• Attaques visant la disponibilité : elles dégradent la précision globale.
• Attaques ciblées : elles provoquent des erreurs de classification spécifiques.
• Attaques par porte dérobée : elles implantent un déclencheur caché (voir la scène suivante).

Les données extraites du web et les documents RAG fournis par les utilisateurs sont des points d’entrée courants pour l’empoisonnement, car ils sont volumineux et peu vérifiés.

Une porte dérobée est une attaque par empoisonnement qui fait se comporter normalement le modèle, sauf lorsqu’un déclencheur secret apparaît dans l’entrée. Le déclencheur peut être une expression rare, une séquence de jetons ou un motif de filigrane.

Exemple : un modèle de complétion de code affiné avec des données empoisonnées se comporte correctement jusqu’à l’apparition d’un commentaire magique, puis produit du code non sécurisé. Les portes dérobées sont difficiles à détecter, car les évaluations de référence standard semblent normales.

Défenses : utilisez uniquement des modèles provenant de fournisseurs fiables qui les signent ; effectuez des analyses de détection des déclencheurs et des anomalies ; affinez le modèle avec des données vérifiées que vous contrôlez.

Les poids d’un modèle ne sont pas de simples données : certains formats exécutent du code lors du chargement. pickle de Python (utilisé par les anciens fichiers .bin et .pt de PyTorch) peut exécuter du code arbitraire pendant la désérialisation.

Charger un modèle picklé non fiable revient à exécuter un programme non fiable.

• Préférez safetensors, qui ne stocke que des tenseurs et ne peut pas exécuter de code.
• Analysez ou isolez dans un bac à sable tout fichier pickle que vous devez charger.
• Traitez les fichiers de modèles provenant de plateformes publiques comme des binaires non fiables.

Déterminez l’origine de chaque artefact et vérifiez qu’il n’a pas été modifié.

• Épinglez les versions et révisions exactes des modèles et des jeux de données ; n’utilisez jamais latest.
• Vérifiez les sommes de contrôle ou les hachages par rapport à une valeur connue comme valide.
• Préférez les artefacts signés et vérifiez les signatures lorsque l’éditeur les fournit.
• Conservez une ML-BOM (nomenclature des composants) répertoriant les modèles, les jeux de données et leurs sources.

Les modèles peuvent mémoriser puis restituer des parties de leurs données d’entraînement, notamment des secrets, des PII ou des textes protégés par le droit d’auteur. Les attaquants utilisent des attaques d’extraction pour obtenir ce contenu.

• Nettoyez les PII et les secrets des corpus d’entraînement et d’affinage.
• Appliquez la déduplication : la mémorisation est corrélée à la répétition des exemples.
• Envisagez des techniques de confidentialité différentielle pour les jeux de données sensibles.
• Testez les modèles avec des sondes d’extraction avant leur publication.

Deux attaques visant la confidentialité ciblent les modèles déployés :

• Inférence d’appartenance : déterminer si un enregistrement précis figurait dans le jeu d’entraînement. Cela peut constituer en soi une violation de la confidentialité, par exemple dans le cas d’un jeu de données médicales.
• Inversion de modèle : reconstruire des entrées d’entraînement représentatives à partir du comportement du modèle ou de ses représentations vectorielles.

Atténuez ces risques en limitant l’exposition des scores de confiance, en ajoutant de la régularisation ou de la confidentialité différentielle, et en restreignant l’accès libre aux requêtes des modèles à forte valeur.

Les systèmes RAG stockent les représentations vectorielles des documents dans une base de données vectorielle. Celles-ci présentent leurs propres risques :

• Inversion des représentations vectorielles : les représentations vectorielles peuvent révéler suffisamment d’informations pour permettre de reconstruire partiellement le texte source ; il s’agit donc de données sensibles.
• Fuite entre locataires : une récupération sans contrôle d’accès peut exposer les documents d’un autre locataire.
• Empoisonnement de l’index : un document malveillant ajouté à l’index peut détourner les récupérations ultérieures (injection indirecte).

Imposez le contrôle d’accès au moment de la récupération et vérifiez les documents avant leur indexation.

Au-delà des modèles, les applications LLM dépendent de la chaîne d’approvisionnement logicielle habituelle, ainsi que de plug-ins et de connecteurs qui dotent le modèle de nouvelles capacités.

• Un plug-in malveillant ou compromis peut lire le contexte et exfiltrer des données.
• Les paquets PyPI/npm dont le nom a été imité ou qui ont été détournés peuvent installer une porte dérobée dans l’application.
• Les dépendances transitives vulnérables élargissent la surface d’attaque.

Utilisez des fichiers de verrouillage, analysez les dépendances avec des outils SCA, vérifiez les autorisations des plug-ins et préférez des sources vérifiées et signées.

Traitez la chaîne d’apprentissage automatique comme toute autre chaîne CI/CD de production, avec des contrôles robustes :

• Isolez les environnements d’entraînement et d’affinage ; limitez les personnes autorisées à envoyer des données.
• Signez et vérifiez les artefacts à chaque étape ; rejetez ceux qui ne sont pas signés ou qui ne correspondent pas aux valeurs attendues.
• Validez les jeux de données à l’aide de la détection des anomalies et de vérifications de provenance.
• Surveillez en continu les modèles déployés afin de détecter les dérives et les comportements inattendus.

Des cadres tels que MITRE ATLAS et le cadre de gestion des risques liés à l’IA de NIST aident à structurer ces contrôles.

La sécurité des modèles, des données et de la chaîne d’approvisionnement repose sur la confiance et la vérification tout au long du cycle de vie :

• Connaissez vos sources (provenance, signatures, ML-BOM).
• Traitez les poids et les jeux de données comme potentiellement malveillants tant qu’ils n’ont pas été vérifiés.
• Protégez la confidentialité contre les fuites, l’inférence et l’inversion.
• Sécurisez strictement les dépendances, les plug-ins et les bases vectorielles.

Le moyen le moins coûteux d’arrêter un artefact empoisonné est de le faire avant qu’il n’entre dans votre chaîne.

Évaluez votre compréhension de la sécurité de la chaîne d’approvisionnement des modèles.

Risques liés aux modèles, aux données et à la chaîne d’approvisionnement :

• La chaîne d’approvisionnement de l’apprentissage automatique couvre les modèles de base, les affinages, les jeux de données, les représentations vectorielles, les plug-ins et les dépendances.
• L’empoisonnement et les portes dérobées corrompent l’entraînement ; vérifiez et signez les sources de données.
• Évitez les formats pickle non sûrs ; préférez safetensors pour les poids non fiables.
• Vérifiez la provenance à l’aide des versions, des sommes de contrôle, des signatures et d’une ML-BOM.
• Protégez la confidentialité contre les fuites, l’inférence d’appartenance et l’inversion ; sécurisez les représentations vectorielles et les bases vectorielles.
• Verrouillez les dépendances et les plug-ins ; sécurisez la chaîne de bout en bout en vous appuyant sur ATLAS et le cadre de gestion des risques liés à l’IA de NIST.