Les développeurs s’appuient de plus en plus sur les grands modèles de langage (LLM) pour accélérer la production de code, afin de répondre aux exigences croissantes de productivité de leurs organisations. Cependant, une étude de Cornell University révèle que les utilisateurs d’assistants IA écrivent nettement moins de code sécurisé que ceux qui n’en utilisent pas, et, plus préoccupant encore, ils sont davantage enclins à croire que leur code comporte moins de vulnérabilités. Face à ces enjeux de sécurité, plutôt que de limiter l’utilisation de l’IA, les organisations doivent explorer des moyens d’en tirer parti tout en atténuant les risques associés.
L’intelligence artificielle (IA) pose aujourd’hui des défis majeurs pour les flux de travail des développeurs et les équipes de sécurité applicative. Les modèles de langage étendu (LLM) ne sont pas formés pour garantir un codage sécurisé et les développeurs qui utilisent ces outils contribuent à la prolifération de code vulnérable au sein de leur organisation.
De plus, les études montrent que la plupart d’entre eux font implicitement confiance au code généré le considérant comme sécurisé. Ce code finit par se retrouver entre les mains d’équipes de sécurité applicative (AppSec) déjà en en sous-effectif et qui peinent à hiérarchiser et à analyser les vulnérabilités.
Un risque croissant de vulnérabilités
L’IA générative, comme toute nouvelle technologie, introduit de nouveaux vecteurs d’attaque, les pirates adaptant sans cesse leurs méthodes en fonction de l’utilisation croissante des LLM, du changement de comportement des développeurs et de leur dépendance à l’IA générative.
Ils peuvent par exemple manipuler les modèles en introduisant ou en « injectant » des invites, ce qui incite le système à adopter des comportements ou des résultats indésirables.
Ils peuvent aussi faire des suggestions de packages qui sont des hallucinations, créer un package malveillant portant le même nom, ou ajouter des paquets malveillants à un modèle disponible publiquement sur un forum communautaire — attendant qu’un utilisateur non méfiant introduise du code infecté dans son système sans le savoir.
Au-delà des attaques, il existe également le risque de fuites accidentelles. Par exemple, lorsque les développeurs saisissent leur code dans un outil GenAI pour le modifier, le LLM peut s’entraîner sur ce code et le régurgiter plus tard à d’autres développeurs externes à l’entreprise. Cela représente une perte de contrôle facile sur la propriété intellectuelle.
Face à ces enjeux, il est donc important de développer une approche stratégique pour accompagner les organisations à mieux exploiter l’IA.
Quelques exemples d’attaques sur l’IA selon l’OWASP
* Injection de prompt : Si des pirates accèdent à un LLM via un jailbreak ou si le développeur accepte des entrées provenant d’une source contrôlée par l’attaquant, le LLM peut être manipulé pour exécuter des actions malveillantes.
* Gestion insécurisée des sorties: Du contenu malveillant peut être injecté avant que l’information ne soit transmise au développeur, entraînant une exécution de code à distance ou une élévation de privilèges.
* Empoisonnement des données d’entraînement: La manipulation des données d’entraînement initiales peut compromettre le modèle, le rendant capable de fournir des informations inexactes ou dangereuses.
* Attaques par déni de service (DoS) :Les LLM sont vulnérables aux attaques par déni de service distribué (DDoS) de la même manière que tout autre système. Si un attaquant consomme suffisamment de ressources, la qualité du service peut être dégradée ou les coûts peuvent grimper en flèche.
* Attaques sur la chaîne d’approvisionnement: Les développeurs peuvent facilement s’appuyer sur des téléchargements ou des packages tiers, qui peuvent être vulnérables, obsolètes, voire corrompus par un contributeur tiers.
* Divulgation d’informations sensibles: Sans assainissement des données, toute entrée peut être utilisée pour entraîner davantage un modèle. De plus, les LLM peuvent divulguer par inadvertance des informations sensibles telles que la propriété intellectuelle ou des algorithmes.
* Conception de plugins non sécurisés: Les acteurs malveillants peuvent créer des requêtes malveillantes, incluant l’exfiltration de données ou l’exécution de code à distance, et les faire passer via l’utilisation d’un plugin utilisé par n’importe quel modèle.
* Dépendance excessive : Les développeurs peuvent trop se fier aux LLM qu’ils utilisent ce qui peut conduire à une dépendance excessive et à l’absence de vérification des hallucinations ou de validation des résultats.
* Vol de modèle : Dans certains cas, des attaquants peuvent voler et manipuler des LLM authentiques, créant un modèle parallèle, volant les données contenues dans le LLM ou trompant les utilisateurs pour qu’ils y saisissent leurs propres données.
Intégrer la protection directement dans le flux de travail des développeurs
Renforcer la protection de l’IA, implique de s’assurer que les systèmes ne génèrent pas ou ne propagent pas de code insécurisé. Il faut pour cela prendre en compte un certain nombre de paramètres.
Premièrement évaluer les vulnérabilités, c’est à dire identifier et corriger les failles potentielles dans les systèmes d’IA pour garantir qu’ils ne deviennent pas des vecteurs d’attaques.
Deuxièmement, sécuriser le code généré par l’IA, c’est-à-dire s’assurer que le code produit ou assisté par des outils d’IA, tels que les LLM, respecte les normes de codage sécurisé.
Troisièmement, automatiser la détection des failles, en utilisant des outils basés sur l’IA pour améliorer la détection et doter les équipes de solutions innovantes pour optimiser leur flux de travail face à l’augmentation du volume de codes générés par IA.
En outre, pour pallier le risque de fuite accidentelle de données, des outils tels que Prompt Security aident à sécuriser l’ensemble des utilisations d’IA générative au sein de l’organisation.
Comprendre ce qui est transmis à un modèle et fournir des moyens d’assainir et de bloquer le partage des données indésirables est indispensable pour renforcer la posture de sécurité.
Les développeurs utilisent et continueront largement d’utiliser l’IA pour générer leur code. Outre la compréhension du profil de risque de chaque outil IA et LLM utilisé, les organisations devront aider leurs développeurs à maintenir des conditions optimales de sécurité sans que cela freine leur rythme de travail, tout en leur proposant des solutions capables d’intégrer les outils IA et LLM au sein de leurs processus. Le code pourra ainsi être sécurisé dès la première ligne, et avec lui, l’ensemble de la chaîne d’approvisionnement logicielle. _______________________________________
Par Fabien Petiau, Country Manager France de Checkmarx
puis