Qu'est-ce que l'empoisonnement des données ?

Toutes les équipes de sécurité sont formées à surveiller le code lors de son déploiement. Presque aucune n'est formée à surveiller les données à leur arrivée, et c'est précisément cette lacune que l'empoisonnement des données exploite. Lorsqu'un modèle infecté arrive en production, la vulnérabilité n'a jamais été détectée lors de la revue de code. Elle se trouvait dans un ensemble de données qui n'avait fait l'objet d'aucun audit des mois auparavant.

Cette entrée de glossaire explique ce qu'est l'empoisonnement de données, comment les attaques par empoisonnement de données se déroulent en pratique et pourquoi l'empoisonnement de données par l'IA est devenu l'un des principaux problèmes. Les risques qui croissent le plus rapidement à l'ère de l'IA SDLCet à quoi ressemble une véritable défense contre cela.

Signification de l'empoisonnement des données #

L'empoisonnement des données consiste à manipuler délibérément les données utilisées pour entraîner, affiner ou initialiser un modèle d'IA, afin que ce dernier apprenne des choses erronées, se comporte comme le souhaite l'attaquant ou divulgue des informations qu'il ne devrait jamais révéler. Au lieu d'attaquer le modèle après son déploiement, l'attaquant s'attaque aux données brutes à partir desquelles il est construit.

L'idée fondamentale de l'empoisonnement des données est simple et inquiétante : la fiabilité d'un modèle d'IA dépend entièrement des données qui ont servi à son apprentissage. Si ces données sont corrompues, biaisées ou piégées avant même le début de l'entraînement, aucune analyse de code, aucun test, aucune surveillance en aval ne permettra de déceler la faille sous-jacente, car le modèle fonctionnera exactement comme on le lui a (malveillantement) appris.

Empoisonnement des données par l'IA vs. vulnérabilités logicielles traditionnelles #

La sécurité des applications traditionnelles part du principe que le danger réside dans le code : une fonction défectueuse, une bibliothèque non corrigée, un serveur mal configuré. L’empoisonnement des données par l’IA remet totalement en cause ce principe. Il n’y a aucune ligne de code vulnérable à identifier, car la corruption s’est produite dans un ensemble d’entraînement, un ensemble de données d’ajustement ou un index de recherche, bien avant l’écriture du moindre code ou le déploiement du moindre modèle.

C’est pourquoi l’empoisonnement des données par l’IA est particulièrement difficile à détecter avec les outils traditionnels. SAST Un scanner lit le code. Un scanner de dépendances lit les manifestes des paquets. Aucun des deux ne lit un corpus d'entraînement de plusieurs gigaoctets ni une base de données vectorielle pleine de documents intégrés, ce qui est précisC'est là que l'empoisonnement des données par l'IA fait des ravages. Les chercheurs en sécurité les découvrent et les divulguent de manière responsable. D'autres sont d'abord repérées et utilisées à des fins malveillantes par des attaquants, ce qui est le scénario le plus dommageable.

Comment fonctionnent réellement les attaques par empoisonnement de données ? #

Les attaques par empoisonnement de données prennent généralement l'une des formes suivantes :

• Empoisonnement des données de formation: un attaquant insère des exemples manipulés, mal étiquetés ou malveillants dans l'ensemble de données utilisé pour entraîner un modèle à partir de zéro ou pour affiner un modèle existant, ce qui lui fait apprendre un biais caché ou un comportement de porte dérobée.
• Retournement d'étiquette: une version plus subtile de ce qui précède, où un attaquant ne modifie que les étiquettes d'un petit sous-ensemble d'exemples d'entraînement, faussant discrètement ce que le modèle apprend à associer à quoi.
• RAG et empoisonnement du contexteDans les systèmes de génération augmentée par récupération, un attaquant insère des documents empoisonnés dans la base de connaissances ou le magasin de vecteurs que le modèle récupère lors de l'exécution, de sorte que le modèle répète avec assurance des informations fausses ou manipulées comme s'il s'agissait de faits vérifiés.
• Déclencheurs de porte dérobée: un attaquant intègre un modèle spécifique dans les données d'entraînement de sorte que le modèle se comporte normalement dans presque tous les cas, mais produit une sortie choisie par l'attaquant dès qu'une phrase ou une entrée de déclenchement cachée apparaît.
• Empoisonnement de la chaîne d'approvisionnement: un attaquant compromet un ensemble de données public ou partagé, un point de contrôle de modèle pré-entraîné, ou un plongement pipeline En amont, de sorte que chaque équipe en aval qui s'en inspire hérite du poison sans jamais toucher à l'attaque d'origine.

Ce qui unit toutes ces attaques par empoisonnement de données, c'est le facteur temps. Les dégâts sont causés avant même que le modèle ne réponde à un utilisateur réel, ce qui explique pourquoi l'expression « avant même qu'il n'écrive une seule ligne de code » décrit si bien cette menace.cisely : le modèle est compromis à sa base, pas à son résultat.

Comment les attaquants corrompent-ils un modèle d'IA avant même qu'il n'écrive une seule ligne de code ? #

Chaque attaque par empoisonnement de données décrite ci-dessus présente le même avantage temporel : la compromission se produit en amont, bien avant qu’un modèle ne génère la moindre sortie visible par l’utilisateur. Il n’y a aucune fonction vulnérable à corriger ni aucune action malveillante. commit Il faut le vérifier lors de l'analyse, car le modèle n'a encore rien écrit. Il a seulement appris, et ce qu'il a appris est déjà faux.

C’est ce qui distingue fondamentalement l’empoisonnement des données d’IA des vulnérabilités que les équipes de sécurité des applications sont formées à traquer. Un modèle infecté par une porte dérobée est identique à un modèle sain dans une comparaison de code. Il réussit un test de sécurité. pull request La procédure de vérification est simple : le système compile, déploie et répond correctement à la plupart des requêtes, jusqu’à ce que la faille introduite par un attaquant se manifeste en production. Dès lors, la question n’est plus « quel code a introduit cette faille ? », mais « quelles données l’ont provoquée et jusqu’à quand remontent-elles ? »

Pourquoi l’empoisonnement des données par l’IA est-il une priorité croissante ? #

L’empoisonnement des données par l’IA n’est plus une préoccupation théorique. Il est formellement reconnu comme LLM04 : Empoisonnement des données et des modèles Dans le Top 10 de l'OWASP pour les applications LLM, au même titre que l'injection rapide et les risques liés à la chaîne d'approvisionnement, elle figure parmi les menaces majeures de l'ère de l'IA générative. Trois tendances la placent au centre des préoccupations de toutes les équipes de sécurité :

• Les dégâts sont invisibles jusqu'à ce qu'ils soient déclenchés. Un modèle empoisonné peut réussir tous les tests fonctionnels et se comporter parfaitement pendant des mois, jusqu'à ce que la condition de déclenchement spécifique implantée par un attaquant apparaisse finalement en production.

• La génération augmentée par la récupération est omniprésente. Tout système qui permet à un modèle d'extraire un contexte en direct de documents, de wikis, de tickets ou d'une base de données vectorielles dispose d'une nouvelle surface d'entrée non auditée, et c'est précisément cette surface que ciblent les attaques par empoisonnement de données.

• Les ensembles de données sont désormais des atouts pour la chaîne d'approvisionnement. Les équipes utilisent régulièrement des modèles pré-entraînés, des plongements lexicaux et des ensembles de données publics provenant de sources externes, de la même manière qu'elles utilisent des packages open source. Or, tout comme un package compromis, un ensemble de données compromis peut propager silencieusement l'attaque dans toutes les équipes qui l'utilisent.

Détection et protection contre l'empoisonnement des données #

Étant donné que l'empoisonnement des données se produit en amont du modèle lui-même, la défense doit également commencer en amont :

• Soyez attentif aux sources de données anormales, et pas seulement au code anormal. La détection comportementale et des anomalies doit s'étendre jusqu'au point d'entrée des données. pipeline, ne pas s'arrêter aux limites du dépôt.

• Connaître chaque ensemble de données dans le pipeline. Il est impossible d'évaluer un risque d'empoisonnement dans un ensemble de données dont on ignore l'existence. La découverte continue d'ensembles de données d'entraînement, d'évaluation et de récupération constitue la première ligne de défense.

• Suivre le parcours des données, du jeu de données au modèle, jusqu'au résultat. Cartographier le chemin emprunté par un ensemble de données dans un modèle, puis d'un modèle vers un agent, un point de terminaison ou un outil de codage, c'est ce qui transforme « nous avons obtenu un mauvais résultat » en « nous savons exactement quel ensemble de données l'a introduit ».

• Examinez attentivement les sources de récupération, et pas seulement les ensembles d'entraînement. Dans les systèmes RAG, le magasin de vecteurs et la base de connaissances nécessitent les mêmes contrôles d'intégrité que les données d'entraînement, car l'empoisonnement du contexte se produit au moment de la requête, et non au moment de l'entraînement.

Comment Xygeni contribue-t-il à combler le fossé en matière d'empoisonnement des données ? #

Se protéger contre la manipulation des données commence par une visibilité dont la plupart des organisations ne disposent tout simplement pas. Xygeni'L'inventaire IA de s découvre en permanence chaque ressource IA à travers le SDLC, y compris les jeux de données sous-jacents : données d’entraînement, ensembles d’évaluation et sources RAG ou de récupération, et les mappe dans un graphe de relations dynamique allant du jeu de données au modèle jusqu’au point de terminaison agent vers serveur MCP à l'outil de codage. Ce graphique permet de transformer un résultat de modèle suspect en une question traçable : quel jeu de données a servi à l'alimenter et d'où provient-il ?

En plus de cet inventaire, celui de Xygeni Sécurité de l'IA Détecte les faiblesses des vecteurs et de l'encodage, notamment le contexte empoisonné lors de la récupération et RAG. pipelines, alignés sur le Les 10 meilleures candidatures OWASP pour le LLM. Au lieu de supposer que les sources d'entraînement et de récupération d'un modèle sont propres, Xygeni les considère comme faisant partie de la surface d'attaque, de la même manière qu'il considère déjà le code, les dépendances et pipelines. Si vous ne pouvez pas actuellement répondre à la question « quelles données ont servi à entraîner ce modèle, et pouvons-nous le prouver ? », c’est précisément cette lacune qu’il convient de combler avant qu’un incident de contamination des données d’IA ne vous oblige à vous poser la question.

QFP #