European Cyber Week – Retrouvez-nous sur le stand 30

Sécurité de l’IA : le risque invisible du code malveillant dans les modèles de Machine Learning (CYBIAH x GLIMPS)

L’adoption fulgurante de l’intelligence artificielle (IA) pousse de nombreuses organisations, des PME aux grandes collectivités, à travailler avec des modèles d’IA. Cependant, cette introduction rapide et massive crée un angle mort majeur pour la cybersécurité : les attaques par code malveillant.

Cet article synthétise la vidéo réalisée par GLIMPS et CYBIAH sur ce sujet. CYBIAH est un projet cofinancé par l’Union européenne et la région Île-de-France qui accompagne les entreprises dans la gestion globale du risque cyber.

Dans cette vidéo, deux experts GLIMPS échangent autour du risque que représente le code malveillant dans les modèles d’IA : Sylvio Hoarau, Analyste CTI et Soufiane Kaissari, en charge de la valorisation de la recherche et membre du groupe de travail d’analyse des attaques sur les systèmes d’IA (lancé en 2024 par le Campus Cyber National, le Hub France IA et le CESIN). Ils alertent sur ces nouvelles menaces et partagent des pistes concrètes pour s’en prémunir.

Qu’est-ce qu’une attaque par code malveillant appliquée à l’IA ?

De manière générale, une attaque par code malveillant consiste à introduire clandestinement un programme nuisible (virus, trojan, ransomware, rootkit) dans un système d’information afin de compromettre son fonctionnement, dérober des données ou saboter l’infrastructure.

Mais lorsque l’on applique ce concept à l’intelligence artificielle, le fonctionnement change. Le code malveillant peut s’attaquer à l’infrastructure d’accueil, mais aussi compromettre le modèle ou son environnement d’exécution, voire l’altérer. Les cybercriminels peuvent ainsi injecter du code malveillant directement dans les scripts d’exécution associés aux modèles, modifier des règles de détection existantes ou introduire des fonctionnalités nuisibles lors de la phase d’apprentissage ou de réglage fin (finetuning). Les vecteurs et techniques d’attaques sont multiples : injections de prompts, empoisonnement des données d’entraînement, vol et extraction du modèle.

Le cas d’école du format « Pickle » : une bombe à retardement by design

L’un des scénarios d’attaque les plus redoutables et pourtant simples à mettre en œuvre s’appuie sur le format Pickle en Python.

Pourquoi est-ce une faille majeure ?

Le format Pickle est couramment utilisé dans l’écosystème Python pour sérialiser et désérialiser des données, notamment pour sauvegarder et charger des modèles d’IA. Le problème est que ce procédé exécute du code de manière arbitraire au moment du chargement, sans aucune vérification préalable. Il ne s’agit pas d’un bug ou d’une vulnérabilité involontaire, mais d’un comportement intégré by design dans le langage Python.

Le scénario de l’attaque

  1. La reconnaissance et ingénierie sociale : l’attaquant cible une entreprise et étudie les tendances du moment pour concevoir un modèle d’IA attractif.
  2. La préparation des ressources : l’attaquant forge un faux modèle d’IA contenant des scripts Pickle compromis, puis le publie sur des plateformes publiques comme Hugging Face ou GitHub sous un nom crédible et engageant.
  3. L’accès initial (ou l’hameçonnage de l’ingénieur) : un développeur ou chercheur interne, pressé par le temps ou manquant de sensibilisation, télécharge ce modèle pour l’expérimenter. Au moment où le système charge le modèle, le script malveillant s’exécute automatiquement.
  4. Le Reverse Shell (la porte dérobée) : le code malveillant ouvre discrètement une porte de communication (un reverse shell) vers le serveur de l’attaquant. L’attaquant reçoit une notification de connexion et obtient instantanément accès à une ligne de commande sur le système de l’entreprise.

Supply Chain AI : quand Hugging Face devient le nouveau npm

Le piège des modèles corrompus (comme ceux exploitant le format Pickle) s’inscrit dans un risque plus large : les attaques de la chaîne d’approvisionnement logiciel (Supply Chain). On peut dresser un parallèle direct avec la célèbre attaque Axios dans l’écosystème JavaScript, où des développeurs ont téléchargé des packages npm malveillants dont la promotion avait été astucieusement orchestrée par des attaquants.

Dans le monde de l’IA, le risque est démultiplié. Des plateformes comme Hugging Face hébergent des centaines de milliers de modèles publics. Or, tout ce qui y est publié n’est pas systématiquement contrôlé. Des chercheurs ont d’ailleurs récemment découvert plus de 100 modèles corrompus ou empoisonnés hébergés directement sur Hugging Face.

Un impact dévastateur sur la triade « CIA » (« CID »)

Lorsqu’un modèle d’IA corrompu est exécuté ou qu’un script malveillant s’infiltre dans l’infrastructure d’une entreprise, les répercussions sont majeures. La compromission affecte directement l’ensemble des piliers de la sécurité de l’information (Confidentialité, Intégrité, Disponibilité) ainsi que la fiabilité globale des systèmes.

Pilier de sécurité Impact d’une attaque par code malveillant dans un contexte d’IA
Confidentialité Vol de données d’entraînement sensibles, de fichiers internes, de clés d’API, entraînant des fuites massives de données soumises au RGPD.
Intégrité Modification silencieuse des poids du modèle, corruption du pipeline de Machine Learning (MLOps) pour fausser les résultats de manière indétectable.
Disponibilité Chiffrement ou destruction des serveurs de Machine Learning ou des modèles via un ransomware, paralysant totalement la production.

Comment se défendre ? Les clés de la remédiation et de la prévention

Face à des attaques rapides, peu coûteuses à mettre en œuvre et complexes à détecter de manière statique, la réaction doit être à la fois technique et organisationnelle.

La détection et la remédiation quand l’attaque a eu lieu

Mener une enquête après incident nécessite des investigations lourdes et coûteuses.

  • Le rôle du SOC (Security Operations Center) : ses équipes assurent la surveillance des systèmes, détectent et qualifient les alertes et participent à l’investigation lorsqu’un incident est identifié.
  • Le rôle du CERT / CSIRT : ces experts interviennent dans l’analyse approfondie de l’incident : analyse des logs et des artefacts, reconstruction de la timeline, identification de la cause et accompagnement des actions de remédiation.
  • La remédiation pratique : restauration des environnements à partir de sauvegardes saines, vérification des modèles et des pipelines de déploiement, et notification aux autorités compétentes (ex. CNIL) lorsque la réglementation l’exige, par exemple en cas de violation de données personnelles (ex. RGPD).

La prévention

Le coût de la remédiation étant exorbitant, l’accent doit être mis sur la prévention. Sylvio Hoarau livre ses conseils essentiels :

  1. Traiter l’IA comme n’importe quel logiciel classique : il faut impérativement sortir l’IA du Shadow IT. Un modèle d’IA doit respecter les mêmes exigences de validation, de traçabilité et de maintien en conditions de sécurité (MCS) que n’importe quelle autre brique applicative.
  2. Adopter l’AI-SBOM (Software Bill of Materials) : tenir un inventaire rigoureux et automatisé de tous les modèles d’IA utilisés, de leurs dépendances et de leur provenance. Il faut également exiger des garanties contractuelles d’intégrité de la part des fournisseurs.
  3. Mettre en place des signatures de code : utiliser la cryptographie pour vérifier l’authenticité et la provenance des modèles avant leur exécution.
  4. Sécuriser les chaînes CI/CD et MLOps : intégrer des contrôles automatiques à chaque étape de l’intégration et du déploiement continu en appliquant le principe du moindre privilège.
  5. Former : sensibiliser les développeurs, administrateurs et utilisateurs finaux aux risques spécifiques de l’IA (corruption de modèles, empoisonnement de jeux de données). L’erreur est humaine ; la formation doit être perçue comme un outil d’accompagnement et non comme une sanction.

Les fiches d’attaque comme boussole de sécurité

Pour aider les décideurs (DSI, RSSI, CEO) à évaluer leurs risques avant de déployer ou d’homologuer un système d’IA, le groupe de travail publie des fiches d’attaque basées sur les référentiels Mitre Atlas, NIST, OWASP et ANSSI. Le premier livrable contient déjà 17 fiches d’attaque (sur 34 prévues), rédigées en collaboration avec des experts en IA et cybersécurité.

Ces fiches d’attaque ne sont pas des contraintes administratives supplémentaires, mais de véritables outils d’aide à la décision pragmatiques. Dans une ère où l’adoption de l’IA s’accélère à pas de géant, anticiper le risque du code malveillant n’est plus une option, c’est une condition sine qua non de survie numérique.