Les 5 meilleures pratiques de sécurité à respecter avec les assistants de codage par IA comme GitHub Copilot

Il n’y a pas si longtemps, l’IA était encore un fantasme tout droit venu du futur et restait l’apanage des films de science-fiction. Les films comme Her et Ex Machina nous laissaient même entendre que l’IA était une boîte de Pandore qui une fois ouverte, pourrait avoir des conséquences inattendues. Avec l’arrivée de ChatGPT, les choses ont bien changé ! Au mois de mai, un sondage mené par Gartner auprès de grands dirigeants a révélé que 89 % des entreprises déployaient l’IA générative ou étudiaient la possibilité de le faire. Un autre rapport publié par Gartner à la même période prédit quant à lui que plus de 80 % du code des produits logiciels sera généré par l’IA en 2025.

Les développeurs ont grandement profité des atouts de l’IA générative. Les outils d’aide au codage comme GitHub Copilot, Amazon CodeWhisperer et le célèbre ChatGPT d’OpenAI dopent leur productivité. Mais aussi puissants et révolutionnaires que sont ces outils, ils apportent aussi leur lot d’erreurs et d’hallucinations et doivent par conséquent être utilisés exclusivement pour aider les développeurs et non pour les remplacer. Une revue humaine minutieuse du code généré par l’IA, des outils de sécurité, des garde-fous et d’autres mesures assurant la sécurité des outils de codage basés sur l’IA générative sont indispensables pour vous permettre d’innover sans crainte. Nous allons voir comment utiliser des outils de complétion du code par IA (comme Copilot) en toute sécurité avec ces 5 meilleures pratiques.

Pratique n° 1 : toujours garder un humain dans la boucle

L’absence (ou l’insuffisance) des contrôles humains est une erreur que l’on retrouve souvent chez les entreprises qui adoptent les outils de codage basés sur l’IA générative. Comme nous l’avons vu, ces outils ne sont pas infaillibles et sont simplement censés aider les développeurs. Par conséquent, ces derniers doivent garder leurs habitudes et continuer à vérifier minutieusement leur code, qu’il soit généré ou non par l’IA.

Vous pouvez considérer l’IA comme un jeune développeur capable de lire des milliers de sujets sur Stack Overflow à la fois. Jamais vous ne pousseriez en production le code d’un petit nouveau sans le vérifier : ne surestimez pas la compétence de l’IA simplement car elle est rapide

Les équipes doivent être formées aux risques du code généré par l’IA, et pas seulement à ses avantages. Les revues régulières du code doivent faire partie de vos pratiques de développement logiciel standard. Validez, testez et corrigez dans l’IDE. Ces habitudes doivent être consacrées dans les politiques et procédures de votre entreprise. Des formations régulières doivent être mises en place pour garantir que vos équipes en comprennent l’importance et mettent en pratique les revues de code appropriées.

Pratique n° 2 : analyser le code généré par l’IA depuis l’IDE à l’aide d’un outil distinct et objectif

Ces deux qualificatifs sont liés. Tout d’abord, pour ne pas tuer dans l’œuf l’accélération de la productivité dont les développeurs profitent grâce à l’IA, vous devez éviter les systèmes de revue de sécurité classiques. Les développeurs sont déjà bien plus nombreux que les experts en sécurité, ce qui a imposé aux équipes d’adopter des pratiques de sécurité shift left. Maintenant que l’IA permet aux développeurs d’aller plus vite, la quantité de code vulnérable augmente aussi. Plus qu’un choix, le shift-left est désormais une obligation. Le plus simple consiste à intégrer les analyses de sécurité dans l’IDE pour que le code soit analysé à mesure qu’il est écrit et que les vulnérabilités soient interceptées de manière proactive, plutôt que d’être cherchées a posteriori, quand elles ont commencé à proliférer dans le pipeline de développement.

Par ailleurs, cette analyse doit aussi être réalisée par un outil de sécurité qui n’est pas celui qui écrit le code. C’est précisément pour cette raison que les équipes de développement et de sécurité sont distinctes. Si vous laissez l’équipe qui écrit le code le sécuriser, vous risquez de faire face à de nombreuses vulnérabilités. La sécurité est une discipline complexe, très différente du développement. 

L’IA derrière les outils qui écrivent du code est entraînée à partir de code fonctionnel dans l’optique d’écrire du code fonctionnel. A contrario, un outil de sécurité ne fait qu’une seule chose : sécuriser le code. Il n’est entraîné que sur des données liées à la sécurité pour détecter et corriger de manière fiable les problèmes. Par ailleurs, les outils de sécurité doivent comprendre le contexte de l’ensemble de votre application, et pas seulement l’extrait de code analysé pour éviter de proposer des correctifs de sécurité qui génèrent d’autres bugs. C’est pour cette raison que Snyk Code utilise une IA symbolique basée sur des règles pour analyser les correctifs suggérés par notre LLM et proposer aux utilisateurs des solutions appropriées. 

Avec l’IA, vous avez besoin de deux outils distincts, l’un pour écrire le code, l’autre pour le sécuriser, de la même manière que vous avez besoin de deux équipes pour le développement et la sécurité. Ces deux outils doivent comprendre le contexte complet de votre application pour vous éviter de générer des extraits de code qui ne fonctionnent qu’en vase clos.

Pratique n° 3 : valider le code tiers

En moyenne, 70 % du code d’une application est open source. Cela signifie que 70 % de votre application ont été écrits et sécurisés par quelqu’un qui ne travaille pas pour votre entreprise et ne peut être tenu responsable d’une vulnérabilité exploitée par des acteurs malveillants intéressés par vos données clients.

Lorsque les développeurs utilisent des dépendances tierces, ils doivent dans tous les cas les soumettre à une analyse de la composition des logiciels (SCA) pour s’assurer de leur sécurité. Les outils SCA détecteront les paquets vulnérables, indiqueront le type de la vulnérabilité (ainsi que sa gravité et d’autres informations) et suggéreront des correctifs.

Le code écrit par l’IA utilise lui aussi des dépendances tierces. Souvenez-vous ! L’IA est un développeur comme les autres. Il est simplement très très rapide. Les dépendances de ce code doivent donc elles aussi être analysées. Cette précaution se justifie d’autant plus si l’on tient compte du fait que les outils d’IA basés sur des LLM auront toujours un peu de retard sur les découvertes et mises à jour des paquets tiers. L’analyse SCA est un complément indispensable de l’IA. Nous vous recommandons donc de toujours vérifier manuellement les bibliothèques open source recommandées par l’IA et d’utiliser des outils comme Snyk Open Source pour les tester manuellement.

Pratique n° 4 : automatiser les tests pour l’ensemble des équipes et des projets

Un test qui n’est pas automatisé est un test qui ne sera sans doute jamais effectué. L’automatisation est une meilleure pratique de base que l’on retrouve presque partout, des administrateurs Unix qui écrivent des tâches CRON aux équipes d’assurance qualité qui déploient des tests automatisés en passant par les équipes DevOps qui développent des infrastructures étendues liées par des scripts Python. L’automatisation ne fait pas que simplifier les choses, elle empêche tout oubli.

Pensez à mettre en œuvre des outils qui sécurisent vos applications automatiquement depuis le pipeline de CI/CD et dans les workflows utilisés par vos équipes.

Pratique n° 5 : protéger votre propriété intellectuelle

Lors de la mise en place de politiques régissant l’utilisation de l’IA, vous devez absolument interdire aux outils de s’entraîner à partir de votre code propriétaire. En 2023, Samsung a par exemple interdit l’utilisation de ChatGPT après que des données propriétaires ont été communiquées à l’IA. Et en effet, votre avantage concurrentiel pourrait bien être proposé sous forme de code aux développeurs travaillant dans une autre entreprise du même secteur que le vôtre. 

Cette pratique est un peu plus difficile à mettre en œuvre à l’aide de la technologie. Aussi, il est donc extrêmement important de bien documenter vos politiques et de bien former vos équipes. Expliquez quelles utilisations de l’IA sont autorisées et quelles pratiques sont obligatoires, et illustrez clairement les conséquences potentielles de leurs violations. Vous devez également partir du principe que toutes les données que vous fournissez à un LLM seront utilisées pour son entraînement. Par conséquent, ne communiquez qu’un minimum d’informations et évitez toute donnée confidentielle. Envisagez également la mise en place de contrôles des entrées et des sorties pour nettoyer les données envoyées par les utilisateurs et celles générées par vos LLM.

Utilisez les assistants de codage par IA de manière sécurisée

Ne vous y trompez pas, les assistants de codage par IA sont l’avenir. Ils boosteront l’efficacité de vos équipes, mais vous devez vous assurer que les applications ainsi créées sont sûres. Vous aurez besoin des bonnes politiques, de la bonne formation et des bons outils pour ne pas ralentir vos équipes. C’est justement sur ce dernier point que Snyk peut vous aider.

Dotée d’informations de pointe et d’une IA hybride intégrant une expertise humaine, la plateforme de sécurité des développeurs de Snyk analyse le code à mesure qu’il est écrit (par des humains ou une IA) et fournit des correctifs en un clic directement dans l’IDE. Vos développeurs ne perdent ainsi pas de temps, et les équipes de sécurité ne sont pas débordées. 

Avec Snyk, vous allez pouvoir commencer à faire confiance au code généré par l’IA. Réservez dès aujourd’hui une démonstration avec un expert pour découvrir comment Snyk peut devenir le copilote de sécurité dont Copilot a besoin.