Session Infosecurity Europe : 4 conseils pour adopter l’IA en toute sécurité
Gerald Crescione
1 août 2024
0 minutes de lecture
L’adoption de l’IA par les entreprises du monde entier continue de s’accélérer à un rythme effréné. Un rapport de Coatue compare l’adoption de l’IA à celle des débuts d’Internet et révèle que la croissance de l’IA est deux fois plus rapide.
Alors que les entreprises adoptent des solutions de développement logiciel reposant sur l’IA, les équipes de sécurité doivent relever le défi de stimuler l’innovation tout en « levant le pied » lorsque c’est nécessaire afin de prévenir les risques liés aux outils d’IA, comme les suggestions de code non sécurisées et les hallucinations concernant les bibliothèques.
Liqian Lim, Senior Product Marketing Manager chez Snyk, s’est entretenue avec Kevin Fielder, client de Snyk et CISO chez NatWest Boxed & Mettle, lors d’Infosecurity Europe 2024. Ils ont examiné les nombreux risques et opportunités liés à l’IA et donné des conseils aux CISO qui souhaitent adopter ces technologies puissantes en toute sécurité. Voici quelques-unes de leurs principales recommandations :
1. Classez les usages de l’IA selon leur importance pour l’activité
Chaque secteur de votre entreprise présente un niveau de risque et d’importance qui lui est propre. Adopter l’IA dans un secteur non critique n’aura peut-être pas d’incidence sur le niveau de sécurité. En revanche, son utilisation dans un secteur essentiel pourrait modifier l’ensemble de votre posture de risque et compromettre des actifs sensibles. Pour gérer la sécurité liée à l’IA, les CISO peuvent gagner du temps et économiser des ressources en se concentrant sur les domaines présentant les risques potentiels les plus élevés.
Selon Fielder : « Par exemple, [prenons l’utilisation de l’IA] pour améliorer l’assistance à la clientèle. Le risque de préjudice lié à la sécurité des applications est en fait assez faible… mais certains secteurs comporteront des domaines plus risqués. Dans ces cas-là, avancez très lentement et faites preuve d’une grande prudence. »
Ne vous fiez pas uniquement aux LLM pour savoir si le code est sécurisé : utilisez plutôt des garde-fous pour l’IA
Comme les grands modèles de langage (LLM) apprennent à partir des prompts antérieurs, ils ont une capacité étonnante à saisir ce que les humains veulent voir et à produire des informations similaires. Plus étonnant encore, certains ont constaté que l’IA avançait des justifications trompeuses pour expliquer ses conclusions, car nos prompts lui ont appris ce que nous souhaitons entendre. Les entreprises ne peuvent donc pas compter sur les LLM eux-mêmes pour évaluer leur niveau de sécurité, expliquer les raisons d’une décision particulière, etc.
Vous devez plutôt recourir à d’autres ressources pour évaluer la sécurité et la qualité du code généré par l’IA. Pour illustrer ce point, Fielder a souligné l’importance de tester correctement les informations générées par l’IA et de prévoir une intervention humaine dans les domaines à haut risque. Si les tests du code généré par l’IA ressemblent à ceux d’autres types de code, ils présentent certaines différences importantes, notamment la nécessité de suivre le rythme et le volume du code généré par l’IA. Fielder a expliqué : « Lorsque l’IA produit le code, veillez à mettre en place les garde-fous appropriés, comme vous auriez déjà dû le faire. Ainsi, le résultat sera correctement testé et sécurisé. »
Il a résumé ces garde-fous essentiels en trois étapes :
Effectuer des revues de code
Ajouter une validation par les pairs
Analyser le code et effectuer des tests unitaires
Un outil SAST aussi rapide que l’IA et aussi précis que des experts, comme Snyk Code, peut vous aider à détecter et à corriger automatiquement, en temps réel, le code écrit par des humains et par l’IA, directement depuis l’IDE des développeurs, pour limiter les changements de contexte et les perturbations du workflow.
Soyez attentif au modèle d’entraînement et protégez-le contre les attaques.
Les intervenants ont également rappelé qu’il est important de savoir quels modèles d’entraînement vos outils d’IA utilisent pour produire leurs résultats et d’encourager les équipes chargées de l’entraînement à prendre des précautions. La prudence concernant les modèles d’entraînement de vos outils d’IA est essentielle : si vous ne sélectionnez pas soigneusement les données d’entraînement, les attaquants peuvent exploiter votre système au moyen de méthodes comme l’injection de prompt. Ces attaques peuvent survenir lorsque des utilisateurs malveillants formulent stratégiquement des prompts pour inciter les LLM à effectuer des tâches dépassant le cadre prévu. Pour empêcher votre modèle d’entraînement d’ingérer et d’utiliser des prompts malveillants, gardez un humain compétent dans la boucle et validez les entrées afin de bloquer celles qui présentent des signes évidents d’activité malveillante.
Comme l’a expliqué Fielder : « Les équipes de sécurité ne participent pas nécessairement à l’entraînement, mais elles peuvent guider les personnes qui s’en chargent et leur indiquer les éléments à prendre en compte : que se passe-t-il si quelqu’un pose une question inappropriée ? Si des informations erronées y sont intégrées ? Comment gérer ces situations ? Comment lui faire oublier des informations s’il a appris des choses incorrectes ? »
Ces recommandations peuvent également vous aider à poser des questions sur les solutions d’IA de vos fournisseurs tiers et à approfondir vos recherches sur leurs modèles d’entraînement. De manière générale, une approche « boîte noire » de l’entraînement des modèles d’IA doit vous alerter.
Identifiez les endroits où l’IA est utilisée dans votre pile technologique actuelle.
Il est également important de savoir que votre organisation utilise probablement déjà de nombreuses solutions d’IA. Il peut toutefois être difficile de repérer lesquelles sont déjà présentes dans votre entreprise, car de nombreuses applications tierces déploient des fonctionnalités d’IA sans en informer correctement leurs clients.
Fielder a déclaré : « L’IA s’intègre peu à peu aux applications professionnelles. Les fournisseurs la déploient, et ne vous donnent pas tous nécessairement la possibilité de ne pas l’utiliser. Ou alors, vous pouvez [refuser]… mais vous devez suivre une procédure compliquée pour ne pas utiliser les fonctionnalités d’IA. Par exemple, l’un de nos émulateurs de terminal utilisait un LLM pour proposer de meilleurs prompts… On pourrait penser qu’un émulateur de terminal est l’outil le moins risqué que l’on utilise, puis découvrir soudain qu’il intègre de l’IA. »
Les entreprises doivent donc relever le défi permanent d’inventorier toutes ces applications tierces et de comprendre comment et où elles utilisent l’IA. Là encore, commencer par les domaines les plus critiques pour l’activité de votre organisation, puis poursuivre l’analyse, peut vous aider.
Snyk : un allié pour sécuriser vos outils d’IA
La course aux progrès technologiques et à la victoire dans la « course à l’IA » peut sembler effrénée, mais avancer avec prudence pour des raisons de sécurité en vaut la peine. Vous n’avez toutefois pas besoin de freiner l’innovation ni de gêner les équipes de développement. Des solutions de sécurité compatibles avec les workflows de développement existants et capables d’évoluer au rythme de l’IA peuvent faire toute la différence.
Snyk complète les assistants de codage IA actuels grâce à des analyses SAST aussi rapides que l’IA et à la correction automatique des vulnérabilités en un clic. Nous proposons également :
Des contrôles des pull requests, qui ajoutent un filet de sécurité pour tenir compte de la vitesse accrue de génération et de validation du code par l’IA ;
Des actions suggérées et des explications en cas de détection d’une vulnérabilité, directement dans les IDE existants des développeurs ;
Des informations contextuelles adaptées au profil métier et au profil de risque propres à votre organisation.
Pour en savoir plus sur la manière de répondre à l’évolution rapide du paysage de l’IA, consultez notre antisèche pour développer en toute sécurité avec l’IA.