J'ai trouvé des modèles d'IA dotés de portes dérobées sur Hugging Face — comme tous ceux qui ont pris la peine de regarder
C'était un mardi soir, et je regardais l'un de mes ingénieurs faire quelque chose qui aurait dû être routinier : charger un modèle pré-entraîné depuis Hugging Face dans un environnement de test. Rien d'extraordinaire. Nous l'avions fait des centaines de fois. Mais cette fois-là, je venais de terminer la lecture de la divulgation de JFrog de février 2024 — celle où leurs chercheurs en sécurité avaient découvert plus de 100 modèles malveillants hébergés sur Hugging Face, dont certains dotés de portes dérobées donnant aux attaquants un accès distant dès l'instant où vous les chargiez — et je n'arrivais pas à détacher mon regard du terminal.
« Attends », ai-je dit. « Dans quel format est ce modèle ? »
Pickle.
J'ai senti mon estomac se nouer.
C'est à cet instant que j'ai compris que nous traitions les modèles d'IA comme l'industrie traitait les bibliothèques open source en 2014 — comme des artefacts intrinsèquement dignes de confiance qu'il suffit de récupérer sur Internet et d'exécuter. Et j'ai su, avec ce genre de certitude qui ne vient que lorsqu'on voit ses propres hypothèses s'effondrer en temps réel, que ce serait l'une des crises de sécurité qui définiront la décennie à venir.
Le modèle qui appelle sa base
Voici ce qui s'est réellement passé sur Hugging Face. Un utilisateur nommé « baller423 » a mis en ligne un modèle PyTorch qui semblait parfaitement normal. Un nom raisonnable, une description plausible, des métriques d'apparence correcte. Mais enfouie dans ses poids sérialisés en pickle se trouvait une charge utile qui, à l'instant même où quelqu'un exécutait torch.load(), ouvrait un reverse shell vers une adresse IP appartenant au Korea Research Environment Open Network.
Pas une attaque théorique. Pas une preuve de concept. Un modèle bien réel, militarisé, hébergé sur le hub de modèles d'IA le plus populaire au monde, attendant que quelqu'un le télécharge.
Et « baller423 » n'était pas seul. JFrog a trouvé une centaine de modèles de ce type — chacun un cheval de Troie déguisé en artefact pré-entraîné utile.
Quand vous exécutez torch.load() sur un fichier pickle, vous ne chargez pas des données. Vous exécutez du code. Et vous n'avez aucune idée de ce que fait ce code avant qu'il ne soit trop tard.
Je dois expliquer pourquoi c'est si dangereux, parce que la plupart des gens — même la plupart des ingénieurs — ne comprennent pas ce qu'est réellement pickle. Le format pickle de Python n'est pas qu'une méthode de sérialisation de données. C'est une machine virtuelle à pile. Il peut exécuter des fonctions Python arbitraires pendant la désérialisation. Quand votre data scientist charge un modèle, pickle peut silencieusement appeler os.system() ou subprocess.run() en arrière-plan. Le modèle fonctionne très bien. Les prédictions ont l'air normales. Et pendant ce temps, quelqu'un à l'autre bout du monde dispose d'un shell sur votre serveur.
Ce n'est pas un bug. C'est ainsi que pickle a été conçu. Nous n'avons simplement jamais pris la mesure de ce que cela implique quand les fichiers proviennent d'inconnus sur Internet.
Pourquoi les scanners ne l'ont-ils pas détecté ?
C'est la partie qui m'a tenu éveillé cette nuit-là. Nous avions des outils de sécurité. L'industrie disposait de PickleScan, l'outil standard pour contrôler les fichiers de modèles. Hugging Face l'exécute lui-même. Les scanners allaient forcément détecter quelque chose d'aussi flagrant, non ?
Non, ils ne l'ont pas fait. Et c'est encore pire que ça.
JFrog a découvert par la suite trois vulnérabilités zero-day dans PickleScan lui-même — dont une enregistrée sous la référence CVE-2025-10155 — qui permettaient aux attaquants de contourner totalement la détection en manipulant les extensions de fichiers ou en exploitant des incohérences d'archives ZIP. Un modèle malveillant pouvait être signalé comme « sûr » par l'outil même conçu pour vous protéger.
Le tableau statistique est sombre : jusqu'à 96 % des alertes actuelles des scanners sont des faux positifs. Pensez à ce que cela fait à une équipe de sécurité. Après la centième fausse alerte, on cesse de regarder. On se met à cliquer sur « approuver » par réflexe. Et c'est exactement à ce moment-là que la vraie menace franchit la porte.
J'ai eu une discussion houleuse à ce sujet avec l'un de mes responsables d'équipe. Il pensait que nous surréagissions. « Nous ne récupérons des modèles qu'auprès d'organisations vérifiées », m'a-t-il dit. Je lui ai montré les données de JFrog. Je lui ai montré que même des formats plus récents et « sûrs » comme GGUF — spécifiquement conçus pour éviter les problèmes de pickle — s'étaient révélés héberger dans leurs métadonnées des templates Jinja malveillants qui s'exécutent pendant l'inférence, et non pendant le chargement. Le scanner ne le voit jamais, parce que l'attaque se produit plus tard, quand le modèle tourne déjà.
Il est resté silencieux un long moment. Puis il a dit : « Alors, à quoi faisons-nous réellement confiance ? »
C'est la bonne question.
Que se passe-t-il quand votre IA abrite un agent dormant ?
L'incident Hugging Face concernait des charges utiles grossières et détectables — reverse shells, exécution de code évidente. Mais la menace plus profonde, celle qui me fait vraiment peur, c'est l'empoisonnement des données. Et la recherche sur le sujet est terrifiante.
L'AI Red Team de NVIDIA, en parallèle des résultats d'Anthropic, a démontré qu'il est possible d'implanter définitivement un comportement caché dans un modèle de 13 milliards de paramètres en empoisonnant seulement 0,00016 % des données d'entraînement — soit environ 250 documents sur des millions.
Laissez ce chiffre faire son chemin. Deux cent cinquante documents.
Le modèle empoisonné réussit tous les benchmarks. Il se comporte de façon identique à un modèle sain sur les tests standard. Mais lorsqu'il rencontre un déclencheur précis — une chaîne de texte particulière, un motif d'image, voire une manipulation des données d'entrée au niveau du bit — il change de comportement. Il pourrait contourner l'authentification. Il pourrait exfiltrer des données. Il pourrait générer du code malveillant qui sera transmis à un système en aval.
Un modèle d'IA empoisonné est l'agent dormant parfait : il réussit tous les tests, brille à tous les benchmarks, et attend patiemment un déclencheur que seul l'attaquant connaît.
Et voici le coup de massue mathématique : ajouter davantage de données saines ne corrige rien. Une fois que la porte dérobée atteint un seuil — typiquement 50 à 100 occurrences du déclencheur pendant l'entraînement — elle est définitivement gravée dans les poids. Impossible de l'éliminer par l'entraînement. Impossible de la diluer.
NVIDIA a formalisé cela dans ce qu'elle appelle l'AI Kill Chain : cinq étapes — Recon, Poison, Hijack, Persist, Impact — qui décrivent la manière dont les attaquants compromettent systématiquement les systèmes d'apprentissage automatique. J'ai écrit sur ce cadre et sur l'éventail complet des vecteurs d'attaque dans notre présentation de recherche interactive, et j'encourage toute personne qui déploie des modèles en production à y consacrer du temps.
L'implication pour toute entreprise qui affine des modèles sur ses propres données est sans appel : même si votre jeu de données propriétaire est irréprochable, le modèle de base que vous avez téléchargé depuis un dépôt public est peut-être déjà compromis. Vous construisez sur une fondation dont vous ne pouvez pas voir l'intérieur.
Le problème du Shadow AI dont personne ne veut parler
J'étais à un dîner avec la RSSI d'une société de services financiers de taille moyenne. Elle m'a raconté, presque avec désinvolture, que son équipe avait récemment découvert 47 modèles d'IA différents en production dans l'entreprise. Sa politique de gouvernance de l'IA en couvrait trois.
C'est cela, le Shadow AI, et c'est une épidémie. Les chiffres sont stupéfiants : 90 % de l'usage de l'IA en entreprise échappe au regard des équipes informatiques et de sécurité. Les développeurs et les métiers récupèrent des modèles non vérifiés dans des dépôts publics parce que le processus officiel prend trop de temps. Ils collent du code propriétaire et des données clients dans des outils d'IA publics — on a observé 77 % des salariés en train de le faire. Et chacun de ces modèles non autorisés est une porte dérobée potentielle qu'aucun scanner n'a jamais examinée.
L'impact financier n'a rien d'abstrait. Les incidents impliquant des outils d'IA non vérifiés augmentent le coût moyen d'une violation de données de 670 000 $. C'est la prime que vous payez pour « aller vite » sans gouvernance.
Je comprends l'impulsion. Vraiment. Quand vous êtes ingénieur, que vous essayez de livrer une fonctionnalité et que le processus de revue de sécurité prend trois semaines, bien sûr que vous êtes tenté de simplement récupérer un modèle sur Hugging Face et de le brancher. J'ai moi-même ressenti cette tentation. Mais la divulgation de JFrog aurait dû mettre fin à cette époque. Nous savons désormais, avec une certitude empirique, que les hubs de modèles publics contiennent des artefacts militarisés. Les traiter comme des sources de confiance, c'est l'équivalent, côté IA, d'exécuter curl | bash depuis un gist GitHub quelconque en production.
Pourquoi tout le monde navigue-t-il encore à l'aveugle ?
Le NIST a publié ses recommandations AI 100-2 en 2024 — une taxonomie complète des attaques adverses contre l'apprentissage automatique et de leurs mesures d'atténuation. C'est un bon travail. Elles donnent à l'industrie un langage commun pour ces menaces. Et presque personne ne les a mises en œuvre.
Les chiffres sont accablants :
- Seulement 17 % des organisations disposent de contrôles automatisés de sécurité de l'IA
- Seulement 12 % ont mis en place une gouvernance de l'IA complète
- Seulement 14 % ont une visibilité sur les flux internes de données de l'IA
- 83 % des organisations, selon la formule du NIST, « naviguent à l'aveugle »
J'ai vu ce fossé de près. Les organisations confondent le fait d'avoir un document de politique interne avec le fait d'avoir une sécurité opérationnelle. Elles vous montreront un PDF de gouvernance de l'IA magnifiquement mis en page pendant que leurs développeurs chargent des modèles pickle non signés dans des clusters Kubernetes de production. Le document existe. Les contrôles, non.
83 % des entreprises n'ont aucun contrôle automatisé sur leur chaîne d'approvisionnement de l'IA. Ce n'est pas un fossé — c'est une porte ouverte.
Comment nous nous sommes mis à traiter les modèles comme du code malveillant
Après la révélation de ce mardi soir, mon équipe chez Veriprajna a passé des semaines à repenser notre approche de l'ingestion de modèles. Le changement philosophique de fond était simple mais radical : traiter chaque modèle d'IA comme du code exécutable potentiellement malveillant jusqu'à preuve du contraire.
Pas « probablement sans danger ». Pas « issu d'une source réputée ». Potentiellement malveillant. Point final.
La nomenclature des composants de machine learning
La première chose dont nous avions besoin, c'était de la transparence. Les nomenclatures logicielles traditionnelles (SBOM) recensent les bibliothèques et les versions, mais les artefacts d'IA exigent davantage : un ML-BOM — une nomenclature des composants de machine learning — qui capture la provenance des données, la lignée du modèle, les dépendances de frameworks et les attestations cryptographiques.
D'où viennent les données d'entraînement ? Qui a affiné ce modèle, et sur quoi ? Quelle version de PyTorch a été utilisée, et présente-t-elle des vulnérabilités connues ? Pouvons-nous vérifier cryptographiquement que le modèle que nous chargeons est exactement l'artefact produit par un pipeline de confiance, sans altération pendant le transport ?
Si vous ne pouvez pas répondre à ces questions, vous ne savez pas ce que vous déployez.
Tuer pickle, tout signer
Nous avons pris deux décisions d'ingénierie immédiates. Premièrement : fini pickle. Point. Chaque modèle de notre pipeline utilise SafeTensors — un format qui ne stocke que des données de tenseurs avec des métadonnées JSON et qui ne peut pas exécuter de code au chargement. C'est moins souple que pickle, et c'est précisément l'objectif.
Deuxièmement : la signature cryptographique des modèles. Chaque artefact de modèle reçoit un hachage unique, signé à l'aide de notre infrastructure PKI interne. Nos serveurs d'inférence exécutent un contrôleur d'admission qui vérifie la signature par rapport à notre racine de confiance avant que les poids ne soient désérialisés en mémoire. Si la signature ne correspond pas, le modèle ne se charge pas. Aucune exception, aucune dérogation, aucun « mais c'est juste pour tester ».
L'un de mes ingénieurs s'y est fermement opposé. « Vous ajoutez de la friction au workflow de développement », m'a-t-il dit. Il avait raison. J'ai ajouté de la friction volontairement. Parce que l'alternative — la voie sans friction où n'importe qui peut charger n'importe quel modèle depuis n'importe où — c'est ainsi qu'on finit avec un reverse shell vers la Corée qui tourne sur son serveur d'inférence.
Surveillance à l'exécution : parce que les analyses statiques ne suffisent pas
La vulnérabilité des templates GGUF nous a appris que l'analyse statique ne couvre qu'une partie de la surface de menace. Un modèle peut être sain au chargement et malveillant à l'inférence. Nous avons donc ajouté une surveillance continue à l'exécution : validation des sorties par rapport à des références saines pour détecter les dérives, limitation du débit des requêtes pour prévenir les attaques par extraction de modèle, et des couches d'assainissement des entrées qui reformulent les requêtes avant qu'elles n'atteignent le modèle central, ce qui perturbe des charges utiles adverses soigneusement élaborées.
Pour l'architecture technique complète — y compris notre approche du confidential computing avec des Trusted Execution Environments adossés au matériel — voir l'analyse technique approfondie de notre document de recherche. On y trouve un niveau de détail d'implémentation qui dépasse ce que je peux couvrir dans un essai.
La vérité qui dérange à propos du « Deep AI » face aux wrappers d'API
Il y a une raison pour laquelle je reviens sans cesse à la distinction entre ce que j'appelle le « Deep AI » — des systèmes d'IA auto-hébergés, affinés, maîtrisés au niveau architectural — et l'approche par wrapper d'API qui domine le marché. Ce n'est pas seulement une préférence technique. C'est un argument de sécurité.
Quand vous encapsulez une API publique, vous externalisez votre chaîne d'approvisionnement de l'IA à quelqu'un d'autre. Vous n'avez aucune visibilité sur la provenance de leurs modèles, leurs données d'entraînement, leur posture de sécurité. Vous faites confiance au fait qu'OpenAI, Anthropic ou Google a accompli le travail difficile de sécuriser son pipeline. Peut-être l'ont-ils fait. Mais vous ne pouvez pas le vérifier, et en sécurité, la confiance sans vérification n'est que de l'espoir.
Quand vous construisez en profondeur — quand vous contrôlez les poids du modèle, le pipeline d'entraînement, l'infrastructure d'inférence — vous héritez de la responsabilité de toute la chaîne d'approvisionnement. C'est plus difficile. C'est plus coûteux. Cela exige le type de discipline d'ingénierie que je viens de décrire. Mais c'est la seule voie vers une sécurité vérifiable.
Un investisseur m'a dit un jour : « Utilisez simplement l'API de GPT et concentrez-vous sur le produit. » Je lui ai répondu que pour les secteurs que nous servons — où un modèle compromis peut signifier des données financières divulguées, des diagnostics médicaux manipulés ou des analyses juridiques corrompues — « utilisez simplement l'API » est un risque, pas une stratégie.
La sécurité de l'IA et la sécurité logicielle sont désormais le même problème
Voici l'idée qui a tout cristallisé pour moi : la sécurité de l'IA et la sécurité de la chaîne d'approvisionnement logicielle ne sont plus des disciplines distinctes. Elles ne peuvent pas l'être. Les modèles d'IA ne s'exécutent pas isolément — ils sont construits et déployés via les mêmes pipelines CI/CD, les mêmes registres de conteneurs et les mêmes arbres de dépendances que les logiciels traditionnels.
Si votre modèle est signé cryptographiquement mais que la bibliothèque Python dont il dépend a été compromise par une attaque de la chaîne d'approvisionnement, vous êtes compromis. Si votre pipeline d'entraînement s'exécute dans une image de conteneur corrompue, les poids de votre modèle ne sont pas dignes de confiance, quelle que soit la propreté de vos données d'entraînement.
L'industrie continue d'essayer de créer des équipes « sécurité de l'IA » et des équipes « sécurité applicative » séparées. Ce cloisonnement organisationnel est une vulnérabilité. La surface d'attaque est unifiée, et la défense doit l'être aussi.
À mesure que le code généré par l'IA accélère la vélocité du développement, le processus traditionnel de revue humaine du code s'effondre sous le volume. Les volumineuses pull requests générées par l'IA sont difficiles à relire attentivement sous la pression des délais, ce qui crée une culture de la « revue superficielle » qui supprime l'un des derniers contrôles de sécurité avec l'humain dans la boucle. Dans cet environnement, la vérification automatisée et déterministe — ancrée dans les signatures cryptographiques et les ML-BOM — n'est pas optionnelle. C'est la seule chose qui passe à l'échelle.
« Mais nous ne sommes pas une cible »
On m'oppose toujours une variante de cet argument. « Nous ne faisons rien d'assez sensible pour justifier ce niveau de sécurité. » « Nos modèles ne servent qu'à de l'outillage interne. » « Personne ne se donnerait la peine d'empoisonner un modèle pour nous attaquer. »
J'ai entendu les mêmes arguments à propos de la sécurité des bibliothèques open source en 2018. Puis il y a eu SolarWinds. Puis Log4Shell. Puis la porte dérobée de XZ Utils — une campagne d'ingénierie sociale de plusieurs années visant à compromettre une seule bibliothèque de compression utilisée par SSH sur tous les serveurs Linux du monde.
La chaîne d'approvisionnement de l'IA suit la même trajectoire, en plus rapide. La surface d'attaque est plus vaste (les poids des modèles sont des blobs binaires opaques qu'on ne peut pas auditer comme du code source), l'outillage est moins mature (PickleScan a des zero-days) et le déficit de gouvernance est plus large (83 % des entreprises n'ont aucun contrôle automatisé).
Vous n'avez pas besoin d'être une cible pour être une victime. Il suffit d'être sur le chemin.
À quoi ressemble une sécurité de l'IA ennuyeuse
Mon objectif — et cela peut sembler étrange — est de rendre le déploiement de l'IA ennuyeux. Pas passionnant, pas à la pointe, pas « aller vite et casser des choses ». Ennuyeux. Prévisible. Auditable.
Ennuyeux signifie que chaque modèle a un ML-BOM. Ennuyeux signifie des signatures cryptographiques vérifiées au moment du chargement. Ennuyeux signifie plus jamais de pickle. Ennuyeux signifie une surveillance à l'exécution qui détecte la dérive avant qu'elle ne devienne une violation de données. Ennuyeux signifie un registre centralisé des actifs d'IA où chaque modèle, jeu de données et dépendance est suivi, contrôlé et versionné.
Ennuyeux signifie que lorsque quelqu'un demande « quels modèles d'IA tournent en production ? », vous pouvez répondre en moins de cinq minutes, preuve cryptographique à l'appui.
L'objectif n'est pas de rendre le déploiement de l'IA palpitant. C'est de le rendre ennuyeux — prévisible, auditable et sûr. Une sécurité de l'IA palpitante, c'est le signe que quelque chose a mal tourné.
Les plus de 100 modèles malveillants trouvés sur Hugging Face n'étaient pas un incident isolé. Ils étaient le symptôme d'une industrie qui a bâti des capacités incroyables sur un socle de confiance aveugle. Nous téléchargions des modèles comme nous téléchargions autrefois des MP3 sur LimeWire — en espérant que tout se passe bien, en ignorant les risques évidents, et en jouant les surpris quand quelque chose tournait mal.
Cette époque est révolue. Les organisations qui survivront à la prochaine vague d'attaques contre la chaîne d'approvisionnement de l'IA seront celles qui auront décidé, dès maintenant, de traiter leurs modèles non comme des boîtes magiques mais comme du code exécutable, avec toute la surface d'attaque que cela implique. Celles qui ont choisi l'ennuyeux plutôt que le rapide. Celles qui ont regardé le terminal, vu le fichier pickle se charger, et dit : « Attends. C'est quoi ce format ? »
