Hugging Face et ModelAudit : une étude révèle les limites de la protection intégrée des modèles de ML

Un chercheur a comparé les contrôles de sécurité intégrés de Hugging Face au scanner externe ModelAudit et obtenu un résultat peu évident : un outil peut voir davantage de signaux à risque, tout en générant beaucoup de bruit. La conclusion principale de l'article est que le nombre d'alertes critiques ne dit presque rien, à lui seul, du caractère réellement malveillant d'un modèle.

Comment le test a été conçu

Dans la première expérience, l'auteur n'a pas pris tout Hugging Face, mais un sous-ensemble de dépôts utilisant les formats de stockage de modèles les plus risqués. L'échantillon ne comprenait que des modèles ouverts contenant des fichiers comme `.pkl`, `.pickle`, `.dill`, `.pt`, `.pth`, `.ckpt`, `.bin`, `.joblib`, `.npy` et `.npz`. Les dépôts trop volumineux et les modèles trop populaires ont aussi été écartés : la taille totale a été plafonnée à 1 Go et les téléchargements mensuels à 10 mille. L'idée est simple : pour chercher de vrais problèmes, mieux vaut commencer là où la probabilité de sérialisation dangereuse est la plus élevée.

• Le premier jeu comptait 246 modèles analysés
• ModelAudit a relevé 271 avertissements critiques
• Au moins une alerte critique a touché 34 modèles
• La comparaison portait sur des dépôts entiers, et non sur des checkpoints isolés à l'intérieur

Mais dès le départ, il est apparu qu'un grand nombre de détections n'équivaut pas à une bonne qualité de détection. Le modèle le plus « riche » en déclenchements est Ultralytics/YOLO11 : 728 avertissements, dont 35 critiques. Sur le papier, cela ressemble à un fort indice de compromission, mais l'analyse manuelle a montré un tableau plus banal. Une part importante des drapeaux critiques reposait sur des éléments standard de Python, qui peuvent aussi apparaître dans des modèles légitimes. Autrement dit, le scanner repérait correctement des motifs potentiellement dangereux, mais les traitait trop souvent comme une preuve directe d'attaque.

Où les règles font du bruit

L'analyse de YOLO11 a bien illustré le point faible de l'analyse statique. Certains déclenchements venaient de `pickle_check` à cause de `__builtin__.getattr`, d'autres de `pytorch_zip_check` à cause de `__builtin__.set` et d'indices similaires. Le problème : `getattr` peut effectivement servir dans des chaînes malveillantes pour contourner des règles primitives, mais c'est aussi une fonction Python ordinaire, présente dans du code normal. Avec `set`, le cas est encore plus parlant : un scanner interne de ModelAudit juge cet import acceptable, tandis qu'un autre peut marquer tout l'espace `builtin` comme suspect.

C'est pourquoi l'auteur insiste : une forte densité d'alertes, même critiques, est une raison de procéder à un tri manuel, pas un verdict contre le modèle. Au fil de la première expérience, il a examiné d'autres types de déclenchements, notamment des soupçons de signatures exécutables dans des fichiers binaires, et s'est heurté au même problème : les règles sont souvent pratiques pour dénicher des candidats, mais fonctionnent mal comme verdict final sans contexte, sans connaître le format du fichier ni comprendre le framework concerné.

«

Ce n'est pas ce que j'imaginais quand nous avons commencé »

Comparaison avec Hugging Face

Dans la seconde expérience, l'auteur a changé d'angle et constitué une liste de modèles que les auteurs des dépôts avaient eux-mêmes étiquetés malicious, exploit, ace, deserialization ou poc. Après un filtrage supplémentaire par un LLM, cet ensemble a été passé dans ModelAudit et les résultats ont été confrontés aux statuts intégrés de Hugging Face.

La comparaison de base a donné une concordance assez forte : les deux outils ont jugé 154 dépôts dangereux et 49 sûrs. Il y a aussi eu 14 cas où ModelAudit voyait un problème alors que Hugging Face n'affichait rien de suspect.

La nuance la plus importante est qu'une partie des signaux utiles de ModelAudit ne se trouve pas seulement aux niveaux warning et critical. L'article cite l'exemple de `jossefharush/gpt2-rs`, où une alerte de niveau INFO contenait des indices d'activité réseau et un lien vers Pastebin. Une vérification ultérieure a montré que ce lien héberge une porte dérobée qui envoie à l'attaquant les résultats des commandes exécutées sur la machine de la victime. Dans ce cas précis, le message « informatif » s'est donc révélé plus important que bien des drapeaux critiques tapageurs de la première expérience.

L'auteur a aussi examiné les écarts inverses, lorsque Hugging Face signalait un danger et que ModelAudit laissait passer le modèle. Ces ratés existaient au départ dans la version 0.2.24, mais ont disparu après les mises à jour vers la 0.2.28, puis la 0.2.31. Le tableau final : tous les dépôts que Hugging Face a fini par juger dangereux ont aussi été détectés par ModelAudit, et le scanner externe conservait en plus 17 dépôts présentant des signaux dangereux absents des avertissements intégrés de HF.

Ce que cela signifie

Un seul scanner ne règle pas le problème de sécurité des artefacts de ML, même s'il paraît le plus mûr de sa catégorie. L'article sur Hugging Face et ModelAudit en tire une leçon plus utile : les bons résultats ne viennent pas d'un pari sur un seul « meilleur » outil, mais de la combinaison de plusieurs contrôles, de mises à jour régulières des règles et d'un examen manuel obligatoire des déclenchements les plus bruyants.