OWASP Machine Learning Security Top 10 : viser le modèle, pas l’application

Ce référentiel a un mérite que les autres listes d’intelligence artificielle de l’OWASP n’ont pas : il vise le modèle lui-même. Pas l’application qui l’emploie, pas l’agent qui l’outille, pas le protocole qui le branche — le modèle, comme objet qu’on entraîne, qu’on interroge, qu’on vole et dont on déduit ce qu’il a vu. C’est précisément la distinction qui le rend utile à côté du Top 10 LLM, et il faut la poser avant toute chose, parce que les deux documents emploient les mêmes mots pour des choses différentes.

→ Lire l’explication complète de la marmotte

Les dix risques de l’édition 2023

Code	Titre officiel	Traduction
ML01:2023	Input Manipulation Attack	Attaque par manipulation des entrées
ML02:2023	Data Poisoning Attack	Attaque par empoisonnement des données
ML03:2023	Model Inversion Attack	Attaque par inversion de modèle
ML04:2023	Membership Inference Attack	Attaque par inférence d’appartenance
ML05:2023	Model Theft	Vol de modèle
ML06:2023	AI Supply Chain Attacks	Attaques sur la chaîne d’approvisionnement de l’IA
ML07:2023	Transfer Learning Attack	Attaque par apprentissage par transfert
ML08:2023	Model Skewing	Biaisage de modèle
ML09:2023	Output Integrity Attack	Attaque sur l’intégrité des sorties
ML10:2023	Model Poisoning	Empoisonnement de modèle

Ce que ce référentiel vise, et que le Top 10 LLM ne vise pas

La différence se lit entrée par entrée, et elle est nette.

Le Top 10 LLM décrit une application : un programme assemble une invite, l’envoie à un modèle, reçoit du texte et en fait quelque chose. Ses risques portent sur l’assemblage de l’invite, la confiance accordée à la sortie, la consommation de ressources, l’autonomie laissée au système. Le modèle y est un composant, souvent loué chez un tiers, dont on ne connaît ni les poids ni les données d’entraînement.

Celui-ci décrit un modèle : un objet qu’on a entraîné soi-même, dont on détient les poids, et dont la valeur est à la fois commerciale et confidentielle. Ses risques portent sur le cycle de vie de cet objet. ML03, l’inversion de modèle, décrit une rétro-ingénierie du modèle pour en extraire de l’information. ML04, l’inférence d’appartenance, décrit la détermination du fait qu’un exemple donné figurait dans le jeu d’entraînement — ce qui transforme une base de données confidentielle en base de données interrogeable à travers le modèle. ML05, le vol de modèle, décrit la reconstitution d’un modèle propriétaire. Aucune de ces trois attaques n’a de sens pour qui appelle une interface de programmation tierce : elles supposent qu’on a quelque chose à protéger dans le modèle.

Trois entrées décrivent l’empoisonnement, à trois moments différents, et c’est le découpage le plus instructif du document. ML02 empoisonne les données d’entraînement. ML10 manipule les paramètres du modèle. ML08 manipule la distribution des données, typiquement par les boucles de retour d’un système en production : le modèle apprend de ce qu’on lui renvoie, et ce qu’on lui renvoie est fabriqué. Les contre-mesures recommandées pour ML08 sont d’ailleurs les plus concrètes du référentiel — contrôler l’accès au système d’exploitation du modèle, journaliser et auditer les activités, et vérifier l’authenticité des données de retour par signature ou condensat, en rejetant ce qui ne correspond pas au format attendu.

Le site traite le fond de ces mécanismes dans l’apprentissage automatique et les réseaux de neurones pour les notions, l’empoisonnement des données d’entraînement pour ML02, la mémorisation et la confidentialité d’un modèle interne pour ML03 et ML04, et le filigrane des poids d’un modèle pour ML05.

ML07 et ML01 : deux entrées qui méritent d’être lues deux fois

ML07, l’apprentissage par transfert, décrit une attaque où l’adversaire entraîne un modèle sur une tâche puis l’affine sur une autre pour le faire se comporter de façon indésirable. Formulé ainsi, cela paraît abstrait ; en pratique, c’est le risque de la chaîne de modèles pré-entraînés. Une équipe part d’un modèle public, le spécialise sur ses données et le met en service ; si le modèle de départ portait un comportement conditionnel déclenché par un motif précis, l’affinage ne l’efface pas nécessairement. Le mécanisme recoupe directement ML06, la chaîne d’approvisionnement, et c’est la raison pour laquelle la provenance des poids compte autant que celle des dépendances logicielles. Les notions voisines sont traitées dans l’affinage d’un modèle et la quantification et le gel de couches.

ML01, la manipulation des entrées, est l’entrée la plus connue sous un autre nom : les exemples adverses. Une modification imperceptible d’une entrée produit une classification radicalement différente. C’est le sujet fondateur de la sécurité de l’apprentissage automatique, et il n’a pas d’équivalent dans le Top 10 LLM, qui parle d’injection de prompt — un phénomène de nature très différente, où l’instruction est lisible et compréhensible par un humain.

ML09, l’intégrité des sorties, mérite une mention pour son angle inattendu : l’attaquant ne touche pas au modèle, il modifie ce qui sort, entre le modèle et l’interface qui affiche le résultat. Les contre-mesures sont celles de n’importe quel canal de données — signature des résultats, transport authentifié — et c’est un rappel utile qu’un modèle correct branché sur un canal non protégé produit des décisions fausses sans avoir rien fait de mal.

ML06 : une chaîne d’approvisionnement plus large que celle du logiciel

L’entrée consacrée à la chaîne d’approvisionnement est celle dont le périmètre a le mieux résisté au temps, et l’argument des auteurs tient en une phrase : la chaîne d’approvisionnement de l’apprentissage automatique compte encore plus d’éléments que celle du logiciel classique. Au-delà des paquets et des dépendances habituels s’y ajoutent les plateformes d’exploitation de modèles, les plateformes de gestion de données, les logiciels de gestion de modèles et les dépôts publics de modèles — autant de composants spécialisés qui permettent de tester et de déployer, et autant de surfaces que l’inventaire logiciel traditionnel ne couvre pas.

Les contre-mesures recommandées sont, pour une fois, parfaitement concrètes : vérifier la signature des paquets avant usage, surveiller les versions et mettre à jour, n’installer que depuis des dépôts tiers qui appliquent un processus de validation, et déployer l’infrastructure d’exploitation de modèles en limitant l’accès de ses interfaces web depuis Internet. Cette dernière recommandation est la plus utile et la moins suivie : une plateforme d’orchestration de modèles exposée publiquement donne accès aux jeux de données, aux poids et aux pipelines d’entraînement, c’est-à-dire aux trois actifs que les neuf autres entrées cherchent à protéger.

Un dépôt public de modèles pose un problème que celui d’un dépôt de paquets n’a pas : on sait relire du code, on ne sait pas relire des poids. La seule vérification praticable porte sur la provenance et la signature, pas sur le contenu — ce qui rend ML06 et ML07 indissociables, et explique pourquoi un fichier de poids téléchargé sans provenance vérifiée est un exécutable dont personne n’a lu la source.

L’état du document : un brouillon qui a vieilli

Il faut le dire franchement, et sans dénigrer un travail bénévole dont le contenu technique reste exact.

Le document porte toujours la mention de brouillon. Le site du projet affiche « édition 2023, version 0.3 brouillon » avec un avertissement indiquant que le travail est modifié fréquemment ; le dépôt, lui, annonce une version 0.2. Les deux ne concordent pas, et la liste des dix entrées n’a pas bougé depuis 2023. La promesse de modification fréquente n’a pas été tenue, ce qui n’a rien d’infamant : les auteurs se sont, pour l’essentiel, déplacés vers les projets consacrés à l’IA générative, qui ont absorbé l’attention de la communauté.

Le texte lui-même porte les traces de son état. La description de ML04 annonce que l’inférence d’appartenance survient « lorsqu’un attaquant manipule les données d’entraînement du modèle », ce qui décrit un empoisonnement, pas une inférence d’appartenance ; la section des contre-mesures du même risque, elle, parle correctement de la difficulté à déterminer si un exemple donné figurait dans le jeu d’entraînement. On comprend ce que le document veut dire, et c’est la section des contre-mesures qui donne la bonne définition. Un lecteur qui citerait la seule description se tromperait.

Enfin, les recommandations de ML10 mélangent des contre-mesures de sécurité et des techniques de qualité d’apprentissage — la régularisation L1 ou L2 y figure comme protection contre l’empoisonnement de modèle. Ce n’est pas faux au sens strict, mais cela brouille la frontière entre robustesse statistique et sécurité, frontière que les référentiels plus récents tiennent mieux.

La conclusion d’usage est donc double, et elle rejoint ce que dit la page chapeau des Top 10 de l’OWASP sur la maturité inégale de la famille. Comme taxonomie des attaques propres au modèle, le document reste le meilleur point d’entrée disponible chez l’OWASP : les dix noms sont justes, bien choisis, et correspondent à une littérature de recherche abondante. Comme référentiel à citer dans un cahier des charges, il n’est pas mûr, et il vaut mieux s’appuyer sur les travaux du NIST en matière de taxonomie des attaques adverses, ou sur les référentiels de la famille IA générative pour ce qui relève de l’application.

Et comme pour tous les autres : ce n’est pas une norme, personne n’est en conformité avec ML05, et pour l’articulation avec une obligation réelle — notamment les exigences de robustesse du règlement européen sur l’intelligence artificielle — c’est la rubrique Normes qui porte le sujet.

🐝 Ce qui arrive si on s’en passe

Sans contrôle d’accès aux prédictions et sans limitation du débit d’interrogation, un modèle propriétaire se reconstitue par interrogation massive : rien n’est volé au sens d’une intrusion, et la copie n’apparaît dans aucun journal comme un incident. Sans protection contre l’inférence d’appartenance, un jeu d’entraînement confidentiel devient interrogeable à travers le modèle, et la confidentialité de la base est perdue sans que la base ait été touchée. Sans vérification d’authenticité des données de retour, un système qui réapprend de ce qu’on lui renvoie dérive dans la direction choisie par celui qui alimente la boucle, et la dérive se lit comme une évolution normale des données. Sans provenance des poids de départ, un comportement conditionnel introduit en amont survit à l’affinage et ne se déclenche que sur le motif prévu par son auteur, c’est-à-dire jamais pendant les tests. Sans intégrité du canal entre le modèle et l’interface, une décision correcte s’affiche modifiée, et l’enquête cherchera le défaut dans le modèle.

🦫 Explication de la marmotte 🍫

Un modèle d’apprentissage automatique n’est pas programmé règle par règle : on lui montre un très grand nombre d’exemples et il en tire lui-même des régularités. Cette façon de faire crée des vulnérabilités qui n’existent pas dans un logiciel ordinaire, et une association internationale de spécialistes en publie la liste depuis 2023.

Trois attaques visent ce que le modèle sait. On peut l’interroger de manière à lui faire restituer des informations contenues dans ses exemples d’apprentissage. On peut déterminer si une donnée précise — le dossier d’une personne, par exemple — faisait partie de ces exemples. Et on peut reconstituer une copie du modèle en lui posant simplement beaucoup de questions, sans jamais entrer dans le système qui l’héberge.

Trois autres attaques visent son apprentissage. On peut truquer les exemples qu’on lui donne au départ. On peut modifier directement les paramètres internes qu’il a calculés. Et on peut, quand le modèle continue d’apprendre en service à partir des retours des utilisateurs, fabriquer ces retours pour le faire dériver lentement dans une direction choisie.

Les dernières attaques portent sur ce qui entoure le modèle : les morceaux réutilisés pour le construire, qui peuvent avoir été modifiés avant qu’on les récupère, et le chemin entre le modèle et l’écran, où un résultat correct peut être remplacé par un autre.

Ce document est encore marqué comme un brouillon et n’a pas changé depuis plusieurs années. Les dix noms qu’il donne sont justes et servent à se comprendre ; il vaut mieux ne pas s’en servir comme d’une exigence contractuelle.

Pages voisines

OWASP Machine Learning Security Top 10 : viser le modèle, pas l'application

Elle cite

: les deux pages se citent l’une l’autre.