Comment les organisations peuvent sécuriser leur code IA

Lucas Morel

Le code généré par l’IA fait surface partout, même dans les endroits où son utilisation est officiellement interdite. Voici ce que les responsables de la cybersécurité peuvent faire pour garantir que cela ne compromette pas la sécurité.

En 2023, l’équipe de la startup d’extraction de données Reworkd était soumise à des délais serrés. Les investisseurs ont fait pression sur eux pour qu’ils monétisent la plateforme et ils ont dû tout migrer de Next.js vers Python/FastAPI. Pour accélérer les choses, l’équipe a décidé de se tourner vers ChatGPT pour effectuer une partie du travail. Le code généré par l’IA semblait fonctionner, ils l’ont donc implémenté directement dans leur environnement de production. Et puis j’ai mis un terme à cette journée.

Le lendemain matin, ils se sont réveillés « avec plus de 40 notifications Gmail de plaintes d’utilisateurs », a écrit le co-fondateur Ashim Shrestha dans un article de blog. « Tout semblait avoir pris feu du jour au lendemain. Aucun de ces utilisateurs n’a pu s’abonner.

Un bug sur la ligne 56, généré par l’IA, a provoqué une collision d’ID unique pendant le processus d’abonnement, et il leur a fallu cinq jours pour identifier le problème et le résoudre. Ce bug, cette « une seule erreur ChatGPT nous a coûté plus de 10 000 $ », a écrit Shrestha.

Bien que Reworkd ait été ouvert sur son erreur, de nombreux incidents similaires restent inconnus. Les RSSI en apprennent souvent à huis clos. Les institutions financières, les systèmes de santé et les plateformes de commerce électronique ont tous été confrontés à des problèmes de sécurité, car les outils de complétion de code 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, aux noms de bibliothèques résultant d’hallucinations ou à l’introduction de dépendances tierces non suivies et non vérifiées.

« Nous sommes confrontés à une tempête parfaite : une dépendance croissante à l’égard du code généré par l’IA, une croissance rapide des bibliothèques open source et la complexité inhérente de ces systèmes », déclare Jens Wessling, directeur de la technologie chez Veracode. « Il est tout à fait naturel que les risques pour la sécurité augmentent. »

Souvent, des outils de complétion de code tels que ChatGPT, GitHub Copilot ou Amazon CodeWhisperer sont utilisés secrètement. Une enquête réalisée par Snyk a montré qu’environ 80 % des développeurs ignorent les politiques de sécurité pour incorporer du code généré par l’IA. Cette pratique crée des angles morts pour les organisations, qui ont souvent du mal à atténuer les problèmes de sécurité et juridiques qui en résultent.

Alors que les outils de codage automatisés sont de plus en plus adoptés, la discussion sur les risques qu’ils posent est devenue une priorité absolue pour de nombreux RSSI et responsables de la cybersécurité. Bien que ces outils soient révolutionnaires et puissent accélérer le développement, ils introduisent également divers problèmes de sécurité, dont certains sont difficiles à détecter.

S’assurer que les progiciels sont identifiés

Même si l’essor des outils de complétion de code basés sur l’IA a marqué le début d’une nouvelle ère d’efficacité et d’innovation dans le développement de logiciels, ces progrès s’accompagnent d’importants risques de sécurité. « Le code généré par l’IA s’intègre souvent parfaitement au code développé par l’homme, ce qui rend difficile la détermination de l’origine des risques de sécurité », explique Wessling.

Parfois, le code généré automatiquement peut inclure des bibliothèques tierces ou des dépendances fantômes, c’est-à-dire des dépendances qui ne sont pas explicitement déclarées dans un fichier manifeste. Ces progiciels non signalés peuvent ne pas être identifiés lors d’une analyse et peuvent potentiellement masquer des vulnérabilités.

Une façon de résoudre ce problème consiste à utiliser des outils d’analyse de la composition logicielle (SCA) et de sécurité de la chaîne d’approvisionnement logicielle qui aident à identifier les bibliothèques utilisées, les vulnérabilités et les problèmes juridiques et de conformité potentiels qui pourraient en découler.

Le rapport 2024 sur la gestion des dépendances d’Endor Labs révèle que 56 % des vulnérabilités de bibliothèque signalées se trouvent dans des dépendances fantômes pour les organisations ayant d’importantes empreintes de dépendances fantômes. « Nous nous attendons à ce que cela constitue un défi croissant pour les organisations, et les outils doivent être capables de donner aux équipes de sécurité une visibilité sur tous les composants logiciels utilisés à des fins de conformité et de gestion des risques », déclare 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 cela, vous ne pouvez pas identifier, et encore moins gérer, les risques provenant des bibliothèques d’IA, ni même de toute bibliothèque tierce », ajoute Meyer. « Si vous ne disposez pas d’un moyen d’identifier les bibliothèques d’IA, qui font partie des logiciels écrits, publiés et/ou utilisés par votre organisation, vous pouvez alors courir un risque de non-conformité. »

Surveillez les modèles ML des hubs communautaires

Les organisations s’exposent également à des risques lorsque les développeurs téléchargent des modèles ou des ensembles de données d’apprentissage automatique (ML) à partir de plateformes comme Hugging Face.

« Malgré les contrôles de sécurité aux deux extrémités, 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 open source de l’Organized Crime and Corruption Reporting Project (OCCRP). « Cela pourrait finalement conduire à une fuite de données de l’entreprise qui a utilisé les modèles malveillants. »

Début 2024, la plateforme Hugging Face hébergeait au moins 100 modèles de 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, Ștefănescu s’inquiète des hallucinations. « Un LLM générera toujours la suite la plus statistiquement probable d’une invite donnée, il n’y a donc aucune garantie réelle qu’il générera un véritable package à partir de PIPy, par exemple, après le mot » importer «  », disent-ils. « Certains attaquants en sont conscients et enregistrent les noms de packages sur des plates-formes telles que npm et PIPy, remplissant certaines fonctionnalités suggérées par les outils de complétion de code afin de donner l’impression que les packages sont légitimes. »

Si ces packages sont importés dans des applications réelles, ils peuvent causer de réels dégâts.

Pour faire face à ces risques, les RSSI peuvent établir des protocoles de téléchargement et d’intégration de modèles ou d’ensembles de données ML à partir de plateformes externes telles que Hugging Face. Cela inclut la mise en œuvre d’outils d’analyse automatisés pour détecter les codes malveillants ou les portes dérobées, la mise en place d’une politique autorisant uniquement l’utilisation de modèles provenant d’éditeurs vérifiés ou la réalisation de tests internes dans des environnements isolés.

Assurez-vous qu’aucune information sensible ne fuit via les assistants de codage IA

Selon l’enquête Voice of Practitioners 2024 de GitGuardian, près de la moitié des organisations s’inquiètent des modèles d’apprentissage et de reproduction des systèmes d’IA qui incluent des informations sensibles. «Cela est particulièrement inquiétant car ces outils suggèrent du code basé sur des modèles appris à partir des données de formation, qui pourraient par inadvertance inclure des informations d’identification codées en dur, par exemple», déclare Thomas Segura, auteur du rapport chez GitGuardian.

Les entreprises basées aux États-Unis étaient particulièrement préoccupées par la possibilité que des informations sensibles soient divulguées par inadvertance dans les bases de code en raison de l’utilisation par les développeurs d’outils de complétion de code basés sur l’IA.

Bien qu’il n’existe pas de solution miracle, les organisations peuvent prendre plusieurs 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 qui fonctionne », déclare Ongers. « Une autre solution consiste à garantir que les données ne puissent pas entrer. »

Regardez en dehors des équipes de développement traditionnelles

Tous les outils basés sur l’IA ne proviennent pas d’équipes composées d’ingénieurs logiciels. « Nous constatons une grande adoption par les analystes de données, les équipes marketing, les chercheurs, etc. au sein des organisations », explique Meyer.

Ces équipes ne développent pas traditionnellement leurs propres logiciels, mais écrivent de plus en plus d’outils simples qui adoptent des bibliothèques et des modèles d’IA, de sorte qu’elles ne sont souvent pas conscientes des risques encourus. « Cette combinaison d’ingénierie fantôme et de sensibilisation à la sécurité des applications inférieure à la moyenne peut constituer un terrain fertile pour les risques », ajoute-t-il.

Pour s’assurer que ces équipes travaillent en toute sécurité, les RSSI doivent envisager d’établir des relations avec ces équipes dès le début du processus. Les responsables de la cybersécurité pourraient également souhaiter mettre en place des programmes de formation adaptés aux équipes de développement non traditionnelles afin de sensibiliser les analystes de données, les professionnels du marketing et les chercheurs aux risques potentiels associés aux outils et bibliothèques basés sur l’IA.

Ressources sécurisées pour la sécurité des applications

« Les budgets de sécurité n’augmentent généralement pas au même rythme que l’accélération du développement logiciel, et l’adoption de l’IA ne fait qu’élargir cet écart », explique Meyer. La sécurité des applications est souvent sous-financée dans la plupart des organisations, mais il est essentiel d’y consacrer suffisamment de temps et de ressources, car l’adoption de l’IA et le codage assisté par l’IA accélèrent le rythme du développement logiciel.

« Un portefeuille d’outils de sécurité de haute qualité pouvant contribuer à combler cette lacune n’est plus une option », déclare Meyer. « Et si les outils sont essentiels pour combler l’écart, le personnel AppSec et ProdSec le sont également, capables de collaborer efficacement avec les développeurs, même les développeurs non traditionnels, et de comprendre les implications techniques, de conformité et de sécurité de l’IA. »

Lorsqu’il s’agit d’obtenir suffisamment de ressources pour protéger les systèmes d’IA, certaines parties prenantes pourraient hésiter, considérant cela comme une dépense facultative plutôt que comme un investissement critique. « L’adoption de l’IA est un sujet de discorde dans de nombreuses organisations, certains dirigeants et équipes étant « à fond » en faveur de l’adoption et d’autres étant fortement réticents », explique Meyer. « Cette tension peut présenter des défis pour les RSSI et les responsables de la sécurité des informations d’entreprise (BISO) perspicaces. »

Les RSSI conscients des avantages et des inconvénients de cette approche pourraient essayer de mettre en place des contrôles pour gérer efficacement les risques, mais cela pourrait donner l’impression que l’organisation freine l’innovation s’ils n’expliquent pas correctement ce qu’ils font. « Les organisations doivent développer des stratégies globales qui équilibrent les avantages en termes de productivité des outils d’IA avec des pratiques de sécurité robustes », explique Segura.

Le risque de bibliothèques open source dangereuses alimentées par l’IA

Alors que l’IA modifie les pratiques d’écriture de code, l’industrie se trouve sur une ligne ténue entre saisir les opportunités qu’elle peut offrir et atténuer les risques qu’elle peut poser. Selon Ongers, ce changement de paradigme suscite plusieurs inquiétudes. « Le plus important, je pense, est l’un des deux extrêmes suivants : soit une dépendance excessive à l’égard d’une IA défectueuse, soit l’ignorance totale de l’IA », dit-il.

Avec plus de cinq millions de bibliothèques open source disponibles aujourd’hui et environ un demi-milliard d’autres qui seront publiées au cours de la prochaine décennie, dont beaucoup seront alimentées par l’IA, les organisations sont confrontées à un défi sans précédent dans la gestion des risques de sécurité associés à leurs écosystèmes logiciels.

« Il s’agit d’un territoire inconnu pour l’industrie, et je pense que les risques doivent être pris en compte au niveau de l’industrie pour garantir la sûreté, la sécurité et la qualité des logiciels qui alimentent notre monde », déclare Wessling.

Il est également important de savoir comment ces problèmes seront résolus. À l’heure actuelle, on assiste à une explosion de fournisseurs de sécurité qui prétendent sécuriser l’IA, mais tous ne font pas un travail méticuleux. En conséquence, « les organisations risquent de ne disposer ni de la visibilité dont elles ont besoin pour prendre des décisions intelligentes en matière de risques, ni des capacités dont elles ont besoin pour agir en conséquence », explique Meyer. « Les RSSI ne veulent pas se retrouver dans la situation de développer de nouvelles capacités en cas de brèche dans l’actualité – ou pire, lorsque c’est leur organisation qui a été piratée. »

Pour éviter de telles situations, les RSSI doivent privilégier l’investissement dans leurs collaborateurs autant que dans les technologies d’IA. « L’industrie du développement de logiciels doit voir la véritable priorité de la formation et de l’amélioration des connaissances de sa main-d’œuvre », déclare Ștefănescu. « Au lieu de payer des abonnements à des outils de complétion de code, elle devrait investir dans le développement des connaissances de son personnel. »