Coder avec l'IA : les lignes directrices de l'ANSSI

Vous utilisez des assistants de programmation basés sur l'IA ? Prévoyez de renforcer vos équipes sécurité.

L'ANSSI et son homologue allemande font passer le message dans le cadre d'un focus sur les risques associés à ces outils. Les deux agences évoquent une compensation nécessaire des gains de productivité réalisés côté développeurs. Démarche qui se traduira par l'augmentation des effectifs... ou par l'usage de l'intelligence artificielle.

Davantage de code produit, c'est effectivement davantage de chances d'engendrer des vulnérabilités. A fortiori quand on s'appuie sur des IA, sujettes, entre autres, à l'obsolescence de leurs données d'entraînement. Et qui peuvent par là même recommander des bibliothèques non sécurisées. Y compris lorsque les problèmes sont clairement documentés, soulignent l'ANSSI et le BSI à l'appui d'une étude émanant de Stanford (Perry et al., 2024 : "Écrit-on du code moins sécurisé avec les assistants IA ?").

Questionner les outputs...

D'autres références à des études universitaires jalonnent le rapport. L'une provient de l'université de Melbourne. Centrée sur les modèles de traitement du langage naturel appliqués à la recherche clinique, elle pointe leurs limites en matière de généralisation. Un constat que les deux agences élargissent aux techniques d'atténuation proposées pour éviter la recommandation de bibliothèques non sécurisées - ou encore de méthodes non sécurisées, les outils d'IA conseillant encore fréquemment MD5 pour le chiffrement.

Face à l'insécurité potentielle des outputs, on emploiera, au possible, des tests de fonctions et des scans de vulnérabilités automatisés. On pourra aussi effectuer des revues inter-équipes, éventuellement avec le renfort d'un chatbot conçu pour questionner le code généré et des prompts utilisés.

... et protéger les inputs

Avant d'en arriver là, on aura établi des fondations solides pour protéger les inputs. Parmi elles :

• N'autoriser que l'usage de comptes sur lesquels l'entreprise a le contrôle et y assortir des règles d'usage claires pour éviter le shadow IT
• En cas de recours à un service cloud (on optera si possible pour l'hébergement de modèles open source en local, précisent l'ANSSI et le BSI), examiner les conditions contractuelles, notamment sur l'usage des données par le fournisseur et/ou des tiers
• Si nécessaire, appliquer une couche de sécurité spécifique aux éléments sensibles tels que les clés d'API

Pour ce qui est des risques d'attaque par injection de prompts et par empoisonnement des données ou des modèles, la sécurité dépend en premier lieu des fournisseurs.
On aura plus sensiblement la main face aux attaques fondées sur des packages malicieux. Par exemple en mettant en place une liste blanche, en constituant un SBOM, en isolant l'environnement de développement... et en contrôlant les éléments inconnus (date de création, degré d'utilisation, activité du repo, etc.).

À consulter en complément :

PoisonGPT : des LLM détournés à la racine
Confusion de dépendances : le strike à 140 000 $ d'un white hat
JetBrains pousse un LLM local pour la saisie semi-automatique
Les assistants IA, nouveau défi pour les RSSI
Le DevOps, un métier à part entière ?