Hugging Face et ModelAudit : la recherche a révélé les limites de la protection intégrée des modèles ML

Un chercheur a comparé les vérifications de sécurité intégrées de Hugging Face avec le scanner externe ModelAudit et a obtenu un résultat loin d'être évident : un outil peut détecter plus de signaux de risque, mais ce faisant crée beaucoup de bruit. La principale conclusion de l'article est que le nombre d'alertes critiques en soi ne nous dit presque rien sur le degré de malveillance réel d'un modèle.

Comment le test a été organisé

Dans la première expérience, l'auteur n'a pas pris tout Hugging Face, mais un sous-ensemble de dépôts avec les formats de stockage de modèles les plus risqués. La sélection incluait uniquement les modèles ouverts qui avaient des fichiers comme `.pkl`, `.pickle`, `.dill`, `.pt`, `.pth`, `.ckpt`, `.bin`, `.joblib`, `.npy` et `.npz`. De plus, les très gros dépôts et les modèles très populaires ont été exclus : la taille totale a été limitée à 1 Go et le nombre de téléchargements par mois à 10 000. L'idée est simple : si vous recherchez des problèmes réels, il est judicieux de d'abord regarder où la probabilité de sérialisation dangereuse est plus élevée.

• Dans le premier ensemble, 246 modèles ont été scannés
• ModelAudit a trouvé 271 avertissements critiques
• Au moins une alerte critique a été déclenchée par 34 modèles
• Pour la comparaison, les dépôts eux-mêmes ont été examinés, et non des points de contrôle individuels au sein d'eux

Mais dès le départ, il est devenu clair qu'un grand nombre de découvertes n'égale pas la qualité de la détection. Le modèle qui s'est avéré être le "plus riche" en détections était Ultralytics/YOLO11 : il a reçu 728 avertissements, dont 35 critiques. Sur le papier, cela ressemble à un signal fort de compromission, mais l'analyse manuelle a montré une image plus banale. Une partie importante des drapeaux critiques était liée à des éléments standards de Python qui se trouvent également dans des modèles légitimes. En d'autres termes, le scanner a correctement remarqué des modèles potentiellement dangereux, mais trop souvent les a interprétés comme une preuve directe d'une attaque.

Où les règles créent du bruit

L'analyse de YOLO11 a bien démontré le point faible de l'analyse statique. Certaines détections provenaient de `pickle_check` en raison de `__builtin__.getattr`, et d'autres de `pytorch_zip_check` en raison de `__builtin__.set` et d'indicateurs similaires. Le problème est que `getattr` peut effectivement être utilisé dans des chaînes malveillantes pour contourner des règles primitives, mais c'est aussi une fonction Python ordinaire qui apparaît dans le code normal. Avec `set`, la situation est encore plus révélatrice : un scanner ModelAudit interne considère qu'une telle importation est acceptable, tandis qu'un autre pourrait marquer l'espace de noms `builtin` entier comme suspect. C'est pourquoi l'auteur souligne spécifiquement : une haute densité même d'alertes critiques est une raison de triage manuel, pas une sentence pour le modèle.

Au cours de la première expérience, il a également analysé d'autres types de détections, y compris les suspicions de signatures exécutables dans les fichiers binaires, et s'est à nouveau heurté au même problème : les règles sont souvent pratiques pour trouver des candidats, mais fonctionnent mal comme un verdict final sans contexte, format de fichier et compréhension du cadre spécifique.

"Ce n'est pas comme ça que je l'ai imaginé quand nous avons commencé"

Comparaison avec Hugging Face

Dans la deuxième expérience, l'auteur a changé d'orientation et a compilé une liste de modèles que les auteurs des dépôts avaient déjà marqués comme malveillants, exploit, ace, deserialization ou poc. Après un filtrage supplémentaire via un LLM, cet ensemble a été exécuté à travers ModelAudit et les résultats ont été comparés aux statuts intégrés de Hugging Face. La comparaison de base a montré un accord assez fort : 154 dépôts ont été considérés comme dangereux par les deux côtés, et 49 ont été considérés comme sûrs. Cependant, il y avait 14 cas où ModelAudit voyait un problème tandis que Hugging Face ne montrait rien de suspect.

La nuance la plus importante ici est que certains des signaux utiles de ModelAudit existent non seulement aux niveaux d'avertissement et critique. L'article donne un exemple de `jossefharush/gpt2-rs`, où une alerte de niveau INFO contenait des signes d'activité réseau et un lien vers Pastebin. Une vérification ultérieure a montré que ce lien contenait une porte dérobée qui envoie les résultats de l'exécution des commandes sur la machine de la victime à un attaquant. Autrement dit, le message "informatif" dans ce cas particulier s'est avéré être substantiellement plus important que de nombreux drapeaux critiques bruyants de la première expérience.

L'auteur a également analysé séparément les divergences inverses, lorsque Hugging Face signalait un danger mais que ModelAudit laissait passer le modèle. Initialement, ces manques se sont produits dans la version 0.2.24, mais après les mises à jour vers 0.2.28, puis vers 0.2.31, ces cas ont disparu. Le tableau final ressemblait à ceci : tous les dépôts que Hugging Face a finalement considérés comme dangereux ont également été capturés par ModelAudit, et en plus le scanner externe disposait de 17 dépôts supplémentaires avec des signaux dangereux qui n'étaient pas dans les avertissements intégrés du HF.

Ce que cela signifie

Aucun scanner unique ne résout le problème de sécurité des artefacts de ML, même s'il semble être le plus mature de sa classe. L'article sur Hugging Face et ModelAudit démontre une idée plus utile : les bons résultats ne viennent pas de parier sur un outil « meilleur », mais d'une combinaison de plusieurs vérifications, de mises à jour régulières des règles et d'une analyse manuelle obligatoire des détections les plus bruyantes.