Stratégie

Comment sécuriser le code généré par des IA ?

---

Le code généré par l'IA se généralise, y compris dans les endroits où son utilisation est officiellement interdite. Introduisant de nouveaux risques en raison des caractéristiques intrinsèques de cette technologie. Voici ce que les RSSI peuvent faire pour s'assurer qu'il ne compromet pas la sécurité de l'organisation.

PublicitéEn 2023, l'équipe de la startup spécialisée dans l'extraction de données Reworkd était soumise à des délais serrés. Les investisseurs entendaient monétiser la plateforme et, pour ce faire, l'équipe devait au préalable migrer de Next.js à Python/FastAPI. Pour accélérer les choses, elle a alors décidé de confier une partie du travail à ChatGPT. Le code généré par l'IA semblait fonctionner, a donc été implémenté directement dans l'environnement de production.

Le lendemain matin, une mauvaise surprise attendait l'équipe de Reworkd : « plus de 40 notifications Gmail de plaintes d'utilisateurs, écrit le cofondateur de la start-up Ashim Shrestha dans un post de blog. Tout semblait avoir pris feu pendant la nuit. Aucun de ces utilisateurs ne pouvait s'abonner. »

Un bogue sur la ligne 56, générée par l'IA, a provoqué une collision d'identifiant unique au cours du processus d'abonnement, et il a fallu cinq jours pour identifier le problème et le résoudre. Ce bogue, cette « simple erreur de ChatGPT nous a coûté plus de 10 000 dollars », souligne Ashim Shrestha.

Bibliothèques hallucinées

Si Reworkd a révélé ouvertement son erreur, de nombreux incidents similaires passent sous les radars. Les RSSI en prennent souvent connaissance dans une réunion à huis clos. Les institutions financières, les systèmes de santé et les plateformes de commerce électronique ont tous rencontré des problèmes de sécurité, car les outils de complétion de code à base d'IA peuvent introduire des vulnérabilités, perturber les opérations ou compromettre l'intégrité des données. De nombreux risques sont associés au code généré par l'IA, des noms de bibliothèques résultant d'hallucinations à l'introduction de dépendances tierces non suivies et non vérifiées. « Nous sommes confrontés aux conditions idéales de déclenchement d'une crise : une dépendance croissante au code généré par l'IA, une croissance rapide des bibliothèques Open Source et la complexité inhérente de ces systèmes, souligne Jens Wessling, directeur technique de l'éditeur Veracode. Il est tout à fait naturel que les risques de sécurité augmentent. »

De plus, les outils de complétion de code tels que ChatGPT, GitHub Copilot ou Amazon CodeWhisperer sont fréquemment utilisés en cachette. Une enquête menée par Snyk montre qu'environ 80 % des développeurs font fi des politiques de sécurité de leur organisation, pour intégrer du code généré par l'IA. Cette pratique crée des angles morts au sein des entreprises, ces dernières peinant à atténuer les risques ainsi créés et les problèmes juridiques qui en résultent.

PublicitéA mesure que l'adoption des outils de codage automatisé progresse fortement, la discussion sur les risques qu'ils posent est devenue une priorité absolue pour de nombreux RSSI et responsables de la cybersécurité. Si ces outils sont peuvent accélérer le développement, ils posent également divers problèmes de sécurité, dont certains sont difficiles à détecter.

S'assurer que les packages logiciels sont identifiés

« Le code généré par l'IA se confond souvent avec le code développé par l'homme, ce qui rend difficile l'identification des risques de sécurité », explique Jens Wessling. Parfois, le code généré automatiquement peut inclure des bibliothèques tierces ou des dépendances masquées, c'est-à-dire des dépendances qui ne sont pas explicitement déclarées. Ces packages logiciels passant sous le radar peuvent échapper aux analyses de code. Or, ils renferment potentiellement des vulnérabilités, sans oublier le nécessaire suivi des patchs de sécurité de ces composants.

L'une des solutions consiste à utiliser des outils d'analyse de la composition des logiciels (SCA, Software composition analysis) et de sécurité de la supply chain logicielle, qui permettent d'identifier les bibliothèques utilisées, les vulnérabilités et les éventuels problèmes juridiques et de conformité que ces exploitations peuvent entraîner. « Un SCA bien réglé proposant une analyse en profondeur peut être une solution », dit Grant Ongers, CSO et cofondateur de Secure Delivery. Une solution cependant imparfaite. « Le plus gros problème, c'est que les SCA tendent à inclure des vulnérabilités dans des fonctions de bibliothèques qui ne sont jamais appelées », ajoute-t-il.

Le rapport 2024 Dependency Management Report d'Endor Labs souligne que 56 % des vulnérabilités signalées dans les bibliothèques se trouvent dans des dépendances 'fantômes' pour les organisations. « Les outils doivent pouvoir donner aux équipes de sécurité une visibilité sur tous les composants logiciels utilisés à des fins de conformité et de gestion des risques », indique Darren Meyer, ingénieur de recherche chez Endor Labs.

C'est pourquoi il est important que les organisations disposent d'un inventaire précis de leurs composants logiciels. « Sans cet inventaire, il est impossible d'identifier, et encore moins de gérer, les risques liés aux bibliothèques d'IA ou à toute autre bibliothèque tierce, reprend Darren Meyer. Si vous n'avez pas de moyen d'identifier les bibliothèques d'IA - intégrant des logiciels écrits, publiés et/ou consommés par votre organisation -, alors vous faites potentiellement face à un risque de conformité. »

Surveiller les modèles ML communautaires

Les organisations s'exposent également à des risques lorsque les développeurs téléchargent des modèles d'apprentissage machine (Machine Learning) ou des jeux de données à partir de plateformes communautaires comme Hugging Face. « Malgré les contrôles de sécurité effectués en entrée et en sortie, il peut arriver que le modèle contienne une porte dérobée qui devient active une fois le modèle intégré », explique Alex Ștefănescu, développeur de logiciels libres au sein de l'Organized Crime and Corruption Reporting Project (OCCRP). « Ce qui peut déboucher sur une fuite de données de l'entreprise exploitant ces modèles malveillants. » Début 2024, la plateforme Hugging Face hébergeait au moins 100 modèles ML malveillants, dont certains étaient capables d'exécuter du code sur les machines des victimes, selon un rapport de JFrog.

En ce qui concerne les outils de complétion de code comme GitHub Copilot, Alex Ștefănescu s'inquiète des hallucinations. « Un LLM générera toujours la suite la plus statistiquement probable d'un prompt donné, il n'y a donc aucune garantie réelle qu'il générera un vrai paquet issu de PyPI (le dépôt officiel des codes Python, NDLR) par exemple, après le mot 'import'. Certains attaquants en sont conscients et enregistrent des noms de paquets sur des plateformes telles que npm (gestionnaire de paquets pour Node.js, NDLR) et PyPI, en remplissant certaines fonctionnalités suggérées par les outils de complétion de code afin de donner l'impression que ces paquets sont légitimes. » Importés dans des applications exploitées en production, ces paquets peuvent évidemment causer de sérieux dommages.

Pour faire face à ces risques, les RSSI peuvent établir des protocoles de téléchargement et d'intégration de modèles de ML ou de jeux de données à partir de plateformes externes telles que Hugging Face. Il s'agit notamment de mettre en oeuvre des outils d'analyse automatisée afin de détecter les codes malveillants ou les portes dérobées, de bâtir une politique n'autorisant que les modèles provenant d'éditeurs vérifiés, ou d'effectuer des tests internes dans des environnements isolés.

Fuite d'information via les assistants de développement

Près de la moitié des organisations sont préoccupées par les systèmes d'IA qui apprennent et reproduisent des schémas intégrant des informations sensibles, selon l'enquête Voice of Practitioners 2024 de GitGuardian. « C'est particulièrement inquiétant car ces outils suggèrent du code basé sur des modèles entraînés sur des données pouvant, par inadvertance, inclure des informations d'identification codées en dur, par exemple », explique Thomas Segura, auteur de l'enquête chez GitGuardian.

Bien qu'il n'y ait pas de solution miracle, les entreprises peuvent prendre quelques mesures pour réduire ce risque. « L'utilisation de systèmes d'IA auto-hébergés, qui ne renvoient pas de données, est une solution efficace », souligne Grant Ongers (Secure Delivery).

Les développeurs, mais aussi les équipes data, marketing, etc.

Les outils basés sur l'IA ne sont pas uniquement exploités par des équipes composées d'ingénieurs logiciels. « Nous constatons qu'un grand nombre d'outils sont adoptés par les analystes de données, les équipes marketing, les chercheurs, etc. », explique Darren Meyer (Endor Labs).

Ces équipes ne développent pas leurs propres logiciels, mais écrivent de plus en plus d'outils assez simples qui exploitent des bibliothèques et des modèles d'IA, de sorte qu'elles ne sont souvent pas conscientes des risques encourus. « Cette combinaison de l'ingénierie de l'ombre et d'une sensibilisation à la sécurité applicative inférieure à la moyenne peut constituer un terrain propice à l'explosion des risques », ajoute Darren Meyer.

Pour s'assurer que ces équipes travaillent en toute sécurité, les RSSI doivent nouer des relations avec elles dès le début du processus. Autre piste : la mise en place de programmes de formation adaptés à ces équipes afin de les sensibiliser aux risques potentiels qu'embarquent les outils à base d'IA et les bibliothèques logicielles. « Plutôt que de payer des abonnements à des outils de complétion de code, le secteur devrait investir dans le développement des connaissances de son personnel », tranche Alex Ștefănescu (OCCRP).

Des budgets pour la sécurité applicative

« Les budgets de sécurité n'augmentent généralement pas au même rythme que le développement de logiciels, et l'adoption de l'IA ne fait que creuser ce fossé », reprend Darren Meyer. La sécurité applicative est donc sous-financée dans la plupart des organisations, alors que l'adoption de l'IA et le développement assisté accélèrent le rythme de création de logiciels. « Un portefeuille d'outils de sécurité de haute qualité aidant à combler ce fossé n'est plus optionnel, pense Darren Meyer. Et si les outils sont essentiels, il en va de même pour le personnel AppSec et ProdSec à même de collaborer efficacement avec les développeurs - y compris les profils atypiques - et comprendre les implications techniques, celles en matière de conformité et de sécurité de l'IA. »

Lorsqu'il s'agit d'obtenir des ressources suffisantes pour protéger les systèmes à base d'IA, certains interlocuteurs au sein des organisations peuvent hésiter, considérant qu'il s'agit d'une dépense facultative plutôt que d'un investissement essentiel. « L'adoption de l'IA est un sujet qui divise de nombreuses organisations, certains dirigeants et équipes y étant tout à fait favorables, tandis que d'autres y sont fermement opposés, explique Darren Meyer. « Cette tension peut représenter un défi pour les RSSI et responsables de la sécurité des informations métier. »

Les RSSI qui sont conscients des avantages et inconvénients de cet équilibre peuvent essayer de mettre en place des contrôles pour gérer les risques de manière efficace, mais cela peut donner l'impression qu'ils veulent l'innovation s'ils n'expliquent pas correctement leur démarche.

L'IA modifiant les pratiques d'écriture de code, l'industrie navigue sur une ligne de crête entre adoption d'une technologie riche en promesses et atténuation des risques qu'elle peut poser. Selon Grant Ongers, le plus important, est d'éviter les deux extrêmes : « soit une dépendance excessive à l'égard d'une IA imparfaite, soit l'ignorance totale de l'IA ».

Article rédigé par

Andrada Fiscutean, CSO (adapté par Reynald Fléchaux)

Partager cet article