Les assistants IA posent de nouveaux défis de cybersécurité. Leur utilisation dans le développement de code peut exposer les entreprises à des risques critiques.
Les assistants de codage alimentés par l’IA sont en train de transformer le développement logiciel. Mais derrière les promesses de productivité se cachent des risques de sécurité majeurs, parfois sous-estimés par les équipes techniques. En septembre 2024, l’ANSSI (France) et le BSI (Allemagne) ont publié un rapport conjoint qui fait l’effet d’un signal d’alarme pour les développeurs, DSI, RSSI et juristes tech.
Dans un monde où l’IA code à la place des humains, qui vérifie le code ?
🤖 Des opportunités réelles pour le développement logiciel
Les AI Coding Assistants (Copilot, CodeWhisperer, Tabnine, etc.) offrent déjà :
-
La génération automatique de blocs de code,
-
Des aides à la documentation, au test, à la traduction entre langages,
-
Une amélioration du confort des développeurs, surtout sur des tâches répétitives.
Mais ces assistants, basés sur des modèles de type LLM, ne garantissent ni la qualité ni la sécurité du code généré. Dès lors, Assistants IA et cybersécurité est-il un duo risqué ?
🧨 Des failles souvent invisibles… jusqu’à l’exploitation
Le rapport ANSSI-BSI identifie plusieurs menaces spécifiques :
1. Failles de sécurité dans le code généré
Même si les assistants produisent du code fonctionnel, des vulnérabilités critiques y sont souvent présentes : injections SQL, erreurs d’authentification, mauvaise gestion des entrées utilisateur…
🧠 “Le code généré par une IA doit être considéré comme non fiable par défaut”, rappellent les agences.
2. Attaques de la chaîne d’approvisionnement
Les LLM peuvent “halluciner” des bibliothèques ou paquets inexistants que les développeurs copieront sans vérifier. Cela ouvre la porte à des attaques par packages malveillants (ex: “typosquatting”).
3. Fuites de données sensibles
Des prompts peuvent contenir des clés API, configurations internes ou données personnelles. Ces données pourraient être utilisées pour réentraîner le modèle ou être interceptées.
🎯 Il est recommandé d’interdire l’usage de comptes personnels pour ces assistants IA dans le cadre de projets sensibles ou industriels.
4. Prompt injection indirecte
Un fichier source contaminé peut injecter des commandes dans un assistant AI si celui-ci lit le code. Cela permet à un attaquant de détourner l’IA à son insu.
✅ Recommandations clés du rapport ANSSI-BSI
Voici les bonnes pratiques identifiées par les autorités :
| Mesure | Objectif |
|---|---|
| 🔍 Vérification humaine systématique | Aucun code généré ne doit être intégré sans relecture. |
| 🛡️ Renforcer les tests de sécurité (DevSecOps) | Les gains de productivité doivent être compensés par des audits renforcés. |
| ☁️ Contrôle strict des outils cloud | Utiliser des comptes entreprise, avec politiques contractuelles claires. |
| 🧼 Hygiène de prompt | Ne jamais inclure d’identifiants ou d’informations confidentielles. |
⚖️ Quelles implications juridiques ?
Les entreprises utilisant ces outils doivent intégrer leur utilisation dans leur analyse de risques (obligation RGPD et NIS2), en particulier si des données personnelles ou sensibles sont en jeu.
🔒 L’utilisation d’un assistant IA dans un projet logiciel devient une décision de gouvernance à documenter dans le registre de traitements ou la politique de sécurité.
📌 À retenir
Les assistants IA sont utiles… mais pas inoffensifs. Utilisés sans garde-fous, ils peuvent introduire des failles de sécurité, faciliter des attaques ou générer des violations de conformité.
Les entreprises doivent les traiter comme tout autre outil d’ingénierie sensible : avec procédure, documentation, tests et vérification humaine.
Pour en savoir plus : https://lawgitech.eu/category/intelligence-artificielle/