L’empoisonnement des modèles IA menace la cybersécurité mobile et logicielle : découvrez comment les attaquants contaminent le code généré par l’IA.
Accélération, automatisation… mais à quel prix ?
Les générateurs de code assistés par l’intelligence artificielle comme GitHub Copilot, Tabnine ou encore Google Gemini Code Assist se sont rapidement imposés dans les environnements de développement. Portés par des modèles de langage (LLMs) toujours plus puissants, ils promettent une écriture de code plus rapide, plus fluide et moins répétitive.
Mais derrière cette promesse de productivité se cache une menace bien réelle : et si les suggestions de code étaient compromises ?
La faille invisible : la contamination des données d’entraînement
Les LLMs ne créent pas de code à partir de rien : ils apprennent en analysant d’immenses datasets issues de sources publiques (GitHub, GitLab, Stack Overflow, etc.). C’est là que réside une faiblesse potentielle. Des acteurs malveillants peuvent introduire du code délibérément vulnérable dans ces bases de données, en espérant qu’il soit utilisé lors de l'entraînement des modèles.
Autrement dit : empoisonnez les données, et vous empoisonnez le modèle.
Exemple d’attaque : simple, discret, redoutable
Un attaquant peut créer des centaines de dépôts GitHub bien nommés, contenant du code :
- ✅ Fonctionnel et sans erreurs apparentes
- ✅ Bien commenté et facile à lire
- ✅ Optimisé pour remonter dans les résultats de recherche
- ❌ Mais incluant une faille cachée (backdoor, clé codée en dur, chiffrement faible...)
Ces dépôts finissent par être intégrés à des datasets d'entraînement.
Résultat : plusieurs mois plus tard, un développeur se voit proposer un extrait de code piégé par son assistant IA. Il l’accepte… et la faille part en production.
Ce n’est pas de la science-fiction
Les alertes s’accumulent :
- Harvard & Stanford (2022) : 40 % des suggestions Copilot dans des contextes sensibles étaient vulnérables.
- MIT & UC Berkeley (2023) : jusqu’à 70 % de réussite dans des attaques d’injection via données contaminées.
- OWASP (brouillon 2024) : l’empoisonnement des LLMs figure dans le Top 10 des menaces IA.
- NCC Group (2023) : prévoit que ce type d’attaque deviendra une menace majeure d’ici 2025.
Pourquoi est-ce si problématique ?
- Les développeurs font souvent confiance au code généré, surtout s’ils sont juniors.
- Les outils IA n’indiquent généralement pas si une suggestion est sécurisée ou non.
- Peu d’équipes disposent d’outils de revue de sécurité intégrés au moment de la suggestion.
- Et surtout : les mauvaises pratiques peuvent être apprises, répétées, et normalisées par les modèles.
Nos conseils pour réduire les risques
Pour les développeurs :
- ✅ Intégrer systématiquement des linters et analyseurs statiques
- ✅ Ne jamais valider du code généré sans revue de sécurité
- ✅ Maintenir une posture critique vis-à-vis des suggestions IA
Pour les équipes sécurité et IT :
- 🔐 Intégrer des étapes de contrôle (SAST/DAST) dans vos CI/CD
- 📚 Former les équipes aux enjeux spécifiques du développement assisté par IA
- 🛠️ Mettre en place des outils de suivi de l’usage du code généré
- 📝 Constituer une liste de bonnes pratiques et de snippets validés
- 🌐 Favoriser les LLMs entraînés sur des données open source transparentes
Ne pas faire confiance les yeux fermés
L’IA générative bouleverse le développement logiciel, mais elle n’est pas sans risques. L’empoisonnement des modèles devient un levier stratégique pour les attaquants. Pour s’en prémunir, les entreprises doivent adopter une approche “zero trust”, y compris envers le code généré par leurs propres outils.
