5 bonnes pratiques de sécurité pour adopter des assistants de programmation générative comme GitHub Copilot

Il n’y a pas si longtemps, l’IA était généralement considérée comme une idée futuriste, tout droit sortie d’un film de science-fiction. Des films comme Her et Ex Machina nous ont même mis en garde contre l’IA, qui pouvait être une boîte de Pandore dont l’ouverture entraînerait des conséquences inattendues. Depuis, les choses ont bien changé, notamment grâce à l’accessibilité et à l’adoption de ChatGPT ! Cette année, un sondage Gartner mené auprès de hauts dirigeants en mai a révélé que 89 % des organisations étudiaient ou mettaient en œuvre l’IA générative. Un rapport Gartner publié à la même période prévoit par ailleurs que plus de 80 % du code développé pour les produits sera généré par l’IA d’ici 2025.

L’IA générative a largement profité aux développeurs, qui utilisent des assistants de programmation comme GitHub Copilot, Amazon CodeWhisperer et ChatGPT d’OpenAI pour décupler leur productivité. Cependant, aussi puissants et révolutionnaires que soient ces outils d’IA, ils restent sujets aux erreurs et aux hallucinations. Ils doivent uniquement servir à renforcer les capacités des développeurs, et non à les remplacer. Il convient donc de valider soigneusement le code généré par l’IA, de mettre en place des outils de sécurité et des garde-fous, ainsi que d’autres mesures pour garantir une utilisation sûre des outils de programmation générative, afin d’innover en toute confiance. Découvrez ci-dessous comment adopter les outils de complétion de code par l’IA (comme Copilot) en toute sécurité grâce à ces 5 bonnes pratiques.

Bonne pratique 1 : gardez toujours un humain dans la boucle

Ne pas prévoir de vérification et de validation humaines, ou ne pas en prévoir suffisamment, est une erreur classique lors de l’adoption d’outils de programmation générative. Comme indiqué plus haut, ces outils sont là pour aider les développeurs et ne sont pas infaillibles. Les développeurs doivent donc conserver les mêmes bonnes pratiques qu’avant l’adoption des outils de programmation par l’IA et continuer à examiner attentivement leur code, qu’il soit généré par l’IA ou non.

Imaginez que l’IA soit un développeur inexpérimenté capable de lire des milliers de discussions Stack Overflow à la fois. Vous ne mettriez jamais en production le code d’un nouveau développeur sans le relire : ne laissez donc pas la rapidité de l’IA vous faire croire qu’elle est plus intelligente qu’elle ne l’est.

Les équipes doivent être sensibilisées aux risques liés au code généré par l’IA, ainsi qu’à ses avantages, et intégrer régulièrement des revues de code à leurs pratiques de développement logiciel. Validez, testez et corrigez le code dans l’IDE. Ces habitudes doivent être inscrites dans les politiques et procédures de l’entreprise. Des formations régulières doivent également être organisées pour veiller à ce que les équipes comprennent l’importance de ces pratiques et effectuent correctement les revues de code nécessaires.

Bonne pratique 2 : analysez le code généré par l’IA dans l’IDE à l’aide d’un outil de sécurité distinct et impartial

Ces deux aspects vont de pair. Tout d’abord, pour profiter pleinement des gains de productivité apportés par l’IA, vous ne pouvez pas ralentir les développeurs avec un examen de sécurité traditionnel. Les développeurs sont déjà beaucoup plus nombreux que les spécialistes de la sécurité, ce qui a conduit les équipes à adopter des pratiques de sécurité intégrées en amont du cycle de développement. Maintenant que l’IA augmente la production des développeurs, le volume de code vulnérable créé a lui aussi augmenté : intégrer la sécurité en amont n’est donc plus un choix, mais une nécessité. Le plus simple est d’intégrer l’analyse de sécurité directement dans l’IDE : le code est ainsi analysé dès qu’il est écrit et les vulnérabilités détectées de manière proactive, plutôt que recherchées après coup, une fois qu’elles se sont propagées dans le pipeline de développement.

Deuxièmement, l’analyse doit être effectuée par un outil de sécurité différent de celui qui écrit le code. C’est pour la même raison que vous disposez d’équipes distinctes pour le développement et la sécurité. Si vous confiez la sécurisation du code à l’équipe qui l’écrit, de nombreuses vulnérabilités passeront inaperçues. La sécurité est complexe et constitue une discipline différente du développement. 

L’IA qui alimente l’outil de génération de code a été entraînée sur du code fonctionnel afin d’écrire du code fonctionnel. À l’inverse, un outil de sécurité conçu spécifiquement pour une seule tâche — sécuriser le code — aura été entraîné uniquement sur des données axées sur la sécurité, afin de détecter et de corriger les problèmes de sécurité de manière fiable. De plus, les outils de sécurité doivent comprendre le contexte complet de votre application, et pas seulement l’extrait de code analysé, pour éviter que les corrections de sécurité ne créent des bogues ailleurs. C’est pourquoi Snyk Code utilise une IA symbolique basée sur des règles pour analyser les correctifs proposés par notre LLM, puis ne propose aux utilisateurs que des solutions qui ne créeront pas de problèmes supplémentaires. 

Avec l’IA, il vous faut deux outils différents (l’un pour écrire, l’autre pour sécuriser), tout comme vous avez deux équipes distinctes (développement et sécurité). Ces deux outils doivent comprendre le contexte complet de votre application pour éviter de produire des extraits de code qui n’ont de sens qu’isolément.

Bonne pratique 3 : validez le code tiers

En moyenne, le code open source représente 70 % du code d’une application. Cela signifie que 70 % de votre application a été écrit et sécurisé par des personnes qui ne travaillent pas dans votre entreprise et ne peuvent être tenues responsables si une vulnérabilité devient un point d’entrée pour des acteurs malveillants cherchant à dérober les données de vos clients.

Lorsque les développeurs utilisent des dépendances tierces, ils doivent toujours les analyser à l’aide d’un outil d’analyse de la composition logicielle (SCA) pour vérifier leur sécurité. Les outils SCA détectent les packages vulnérables, indiquent la nature de la vulnérabilité (type, gravité, etc.) et suggèrent des solutions pour y remédier.

Le code écrit par l’IA utilise également des dépendances tierces. Vous vous souvenez ? L’IA n’est qu’un autre développeur, qui écrit simplement du code incroyablement vite. Toutes les dépendances de ce code doivent elles aussi être analysées. D’autant plus qu’un outil d’IA basé sur un LLM accuse toujours un certain retard sur les dernières découvertes concernant les packages tiers et leurs nouvelles versions. L’IA a besoin de SCA. C’est pourquoi nous vous recommandons 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.

Bonne pratique 4 : automatisez les tests dans toutes les équipes et tous les projets

Si ce n’est pas automatisé, il y a de fortes chances que cela ne soit pas fait. L’automatisation est une bonne pratique si fondamentale qu’on la retrouve presque partout : des administrateurs Unix qui créent des tâches cron aux équipes QA qui mettent en place des tests automatisés, en passant par les équipes DevOps qui développent de vastes infrastructures maintenues par des scripts Python. L’automatisation ne facilite pas seulement le quotidien : elle rend impossible tout oubli.

Veillez à mettre en place des outils de sécurité qui sécurisent automatiquement vos applications depuis la CI/CD, ainsi que dans les workflows déjà utilisés par les équipes.

Bonne pratique 5 : protégez votre propriété intellectuelle

Lorsque vous définissez des règles d’utilisation des outils d’IA, il est essentiel de ne pas les laisser s’entraîner sur votre code propriétaire. En 2023, nous avons vu Samsung interdire l’utilisation de ChatGPT après la fuite de données propriétaires dans le cadre de l’entraînement basé sur l’utilisation. Vous ne voulez surtout pas que votre avantage concurrentiel soit proposé sous forme de code à des développeurs travaillant pour une autre entreprise de votre secteur. 

Cette pratique est un peu plus difficile à faire respecter au moyen de la technologie. Il est donc essentiel de documenter clairement vos règles d’utilisation de l’IA et de bien former vos équipes, en précisant les utilisations autorisées, les pratiques obligatoires et les conséquences possibles. Par ailleurs, partez du principe que toute donnée que vous fournissez à un LLM servira à son entraînement. Ne lui communiquez que le minimum d’informations (sans aucune donnée confidentielle) nécessaire à son travail et envisagez de mettre en place des contrôles des entrées et des sorties afin d’assainir les données fournies par les utilisateurs et les réponses de vos LLM.

Utilisez les assistants de programmation par l’IA en toute sécurité

Ne vous y trompez pas : les assistants de programmation par l’IA représentent l’avenir. Vos équipes iront plus vite que jamais et généreront plus de code que jamais. À vous de veiller à la sécurité des applications qu’elles livrent. Il vous faudra les bonnes politiques, les bonnes formations et, surtout, les bons outils de sécurité pour permettre aux équipes d’avancer rapidement. C’est là que Snyk peut vous aider.

Grâce à une intelligence de pointe et à une IA hybride avec intervention d’experts, la plateforme de sécurité des développeurs de Snyk analyse le code au fur et à mesure de son écriture, qu’il soit écrit par une personne ou par l’IA. Elle propose des corrections en un clic, directement dans l’IDE, pour permettre aux développeurs d’avancer sans ralentir et éviter aux équipes de sécurité d’être submergées. 

Faites confiance au code généré par l’IA grâce à Snyk. Réservez dès aujourd’hui une démo avec un expert pour découvrir comment Snyk peut être le copilote de sécurité dont Copilot a besoin.