Copilot : une IA qui reproduit les vulnérabilités de votre base de code

Le saviez-vous ? GitHub Copilot risque bien de vous suggérer du code vulnérable si votre base de code présente déjà des problèmes de sécurité. A contrario, si votre base de code est sécurisée, Copilot a moins de chances de générer de nouvelles failles. Les assistants de codage par IA peuvent vous suggérer du code vulnérable, car ils ne comprennent pas réellement votre base de code. En effet, ils se contentent d’imiter des patterns qui leur ont été appris ou d’exploiter le contexte fourni sans l’analyser. En offrant à Copilot une meilleure base d’entraînement, vous pouvez améliorer son comportement, mais sans pour autant garantir votre protection contre les failles de sécurité. Ce phénomène n’est pas sans rappeler la théorie de la vitre brisée, qui avance que les signes visibles de criminalité, de comportements nuisibles et de troubles sociaux génèrent un environnement urbain qui encourage davantage le crime et la délinquance.

Dans cet article, nous allons vous présenter un exemple concret montrant que Copilot peut répliquer des problèmes de sécurité venus tout droit de votre propre code. Cet exemple place Copilot dans le contexte d’un projet comportant de nombreuses vulnérabilités. Cette IA utilise le code des onglets voisins, à savoir les fichiers ouverts dans l’IDE, afin d’obtenir du contexte. Dans le cas présent, ce contexte abrite des vulnérabilités, et les suggestions de Copilot aggravent donc les problèmes de sécurité du projet. Ainsi, toute dette de sécurité dans un projet peut encore aggraver les conséquences des lacunes en matière de sécurité des développeurs qui utilisent Copilot. Nous reviendrons sur ce point plus en détail dans la section suivante.

À l’inverse, Copilot risque moins de suggérer du code non sécurisé dans les projets déjà sûrs, car il pourra s’appuyer sur un contexte solide. Par conséquent, vous avez tout à gagner à consacrer du temps à l’élimination des failles de votre base de code, car vous éviterez ainsi l’inclusion future de nouvelles vulnérabilités par les assistants de codage par IA générative. D’après les données que nous avons pu réunir, un projet commercial comporte en moyenne 40 vulnérabilités dans son code interne. Presque un tiers de ces problèmes présentent une gravité élevée. Or, c’est sur ce contexte que se basent les outils d’IA générative pour proposer leur code. Les principaux problèmes repérés par Snyk dans les projets commerciaux sont le cross-site scripting (XSS), la traversée de répertoire, les codes secrets et identifiants codés en dur et les injections SQL.

Explication du problème

Les assistants de codage par IA générative comme GitHub Copilot, AWS CodeWhisperer et ChatGPT permettent de coder plus rapidement et efficacement. Pour autant, ils ne comprennent pas réellement la signification du code et ne sont donc pas en mesure de le juger. En vérité, ces outils répliquent simplement ce qu’ils ont vu lors de leur entraînement. En leur fournissant de meilleurs modèles, vous pourrez donc améliorer leur comportement, sans toutefois jamais avoir la certitude qu’ils vous proposent du code sécurisé. Pour obtenir cette assurance, vous devez mettre en place un garde-fou.

La pertinence des assistants est fortement liée à leur exploitation du contexte. 

De base, Copilot génère des extraits de code en s’appuyant sur les patterns et structures tirés de nombreux dépôts. Pour être pertinent, il déduit un contexte à l’aide de l’ingénierie de prompt, mais aussi des onglets voisins. Ces onglets peuvent correspondre à des fichiers de votre projet que vous avez ouverts récemment. Cette approche présente divers avantages, mais aussi un inconvénient majeur en matière de sécurité.

À l’origine, Copilot ne pouvait former le contexte que sur la base du fichier dans lequel vous codiez. Bien entendu, ses suggestions étaient moins pertinentes à l’échelle du projet, car ses algorithmes ne pouvaient pas s’appuyer sur le reste de la base de code. Par conséquent, l’éditeur de Copilot a créé une bibliothèque de prompts qui contient une vaste quantité de données sur le contexte de développement et comprend mieux le prompt de l’utilisateur afin de proposer une réponse plus précise. Pour cela, Copilot utilise des algorithmes qui donnent la priorité aux données les plus contextualisées. Enfin sont arrivés les onglets voisins, une technique par laquelle Copilot peut utiliser les fichiers ouverts dans l’IDE du développeur, en donnant la priorité à ceux adjacents au fichier actif. En ouvrant un maximum de fichiers pertinents pour leur projet, les développeurs obtiendront des résultats plus intéressants. Le responsable de la communauté de GitHub Copilot, Akash Sharma, a récemment commenté cette fonctionnalité en expliquant que ce comportement a permis de presque doubler le nombre de suggestions de Copilot acceptées, passant de 20 à 35 %. 

Mais que se passe-t-il si vos développeurs ne sont pas experts en sécurité ? Que se passe-t-il si les projets présentent déjà des problèmes de sécurité et de qualité formant une dette technique non gérée ? 

Pour répondre simplement, Copilot peut suggérer du code reprenant des vulnérabilités de sécurité des fichiers voisins. Il en résulte alors des pratiques de codage non sécurisées qui ouvrent la voie à diverses failles.

Voyons concrètement ce qui se passe :

Dans la vidéo ci-dessus, nous demandons à Copilot de créer deux requêtes SQL pour faire correspondre la saisie d’un utilisateur avec le nom ou la description d’un produit figurant dans notre base de données. Nous savons les dégâts que les injections SQL peuvent faire dans une application et voulons donc éviter d’en introduire une dans notre code. La première fois que nous demandons à Copilot de créer une requête, il nous fait la proposition suivante :

1// create query to match input with the description or product name
2var query = em.createQuery("SELECT p FROM Product p WHERE LOWER(p.description) like  OR lower(p.productName) like :input", Product.class);

Le code paraît sain, car il utilise des paramètres nommés qui nous protègent contre les injections SQL. Malheureusement, nous introduisons ensuite un extrait de code vulnérable dans un onglet voisin, qui crée une requête SQL ailleurs dans notre projet. Lorsque nous renouvelons notre demande à l’identique, Copilot se sert du nouveau contexte vulnérable et le répète, aggravant l’insécurité du code :

1// create query to match input with the description or product name
2String query = "Select * from Product where lower(description) like '%" + lowerInput + "%' OR lower(product_name) like '%" + lowerInput + "%'";

Nous venons de passer d’une injection SQL à deux, tout simplement car Copilot s’est appuyé sur notre contexte vulnérable.

Aggravation des problèmes de sécurité

Ce comportement peut aggraver les problèmes des bases de code vulnérables sur différents points :

• Renforcement des mauvaises habitudes : les suggestions de Copilot peuvent encourager les mauvaises habitudes de codage des développeurs débutants ou ne maîtrisant pas la sécurité. En voyant que l’IA répète des patterns de code non sûrs, ils peuvent se dire que ces pratiques sont acceptables et les conserver.

• Absence de revue : le code généré par Copilot peut être déployé sans revue sérieuse. Cette absence d’intervention humaine risque de permettre à des vulnérabilités de sécurité de passer inaperçues, car le contexte de génération du code peut ne pas les mettre en évidence.

• Patterns obsolètes et incorrects : Copilot peut suggérer du code reposant sur des patterns de codage obsolètes ou incorrects. Auparavant considérés comme acceptables, ils sont aujourd’hui vus comme des risques pour la sécurité.

• Désintérêt pour la sécurité : Copilot se concentre sur la génération du code et non l’évaluation de la sécurité. Les développeurs peuvent quant à eux être davantage intéressés par les fonctionnalités que la sécurité, et négliger les vulnérabilités.

Comment résoudre ce problème ?

Pour éviter que les assistants de codage par IA ne répliquent les problèmes de sécurité de vos projets, plusieurs mesures sont possibles :

• Les développeurs doivent toujours effectuer un passage en revue manuel du code généré par l’IA. Cette revue doit inclure une évaluation complète de la sécurité permettant d’identifier et de corriger les vulnérabilités.

• Les équipes de sécurité doivent mettre en place des garde-fous SAST, et notamment des politiques de référence sur lesquelles leurs équipes de développement peuvent s’appuyer. Snyk peut vous aider à identifier et corriger rapidement les problèmes de sécurité à la fois dans code rédigé manuellement et le code généré par IA pour vous éviter d’ajouter de nouveaux problèmes à votre base de code.

• Les développeurs peuvent respecter des directives de code sécurisé établies par les équipes de développement (ambassadeurs de la sécurité) et les équipes de sécurité.

• Les équipes de sécurité peuvent fournir la formation et la sensibilisationnécessaires aux équipes de développement, pour les aider à comprendre les vulnérabilités et meilleures pratiques de sécurité courantes et à prendre des décisions éclairées lorsqu’ils passent en revue du code généré par l’IA.

• Les équipes de sécurité peuvent aider l’équipe de développement à prioriser et trier les problèmes du backlog. En éliminant les problèmes les plus dangereux du projet, vous réduirez le risque que les assistants de codage par IA générative les reproduisent dans leurs suggestions de code.

• Les équipe de direction peuvent imposer des garde-fous de sécurité pour utiliser ces assistants, et ainsi améliorer la sensibilisation et la formation aux risques et aux mesures permettant de les limiter.

Conclusion : les assistants de codage par IA ont besoin de garde-fous de sécurité

Il est important de comprendre que ces assistants, Copilot notamment, ne comprennent pas réellement la signification du code et ne sont donc pas en mesure de le juger. En vérité, ces outils répliquent simplement ce qu’ils ont vu lors de leur entraînement. En leur fournissant de meilleurs modèles, vous pourrez donc améliorer leur comportement, sans toutefois jamais avoir la certitude qu’ils vous proposent du code sécurisé. Pour obtenir cette assurance, vous devez mettre en place un garde-fou.

Par conséquent, il est essentiel de combiner ces outils aux techniques AppSec traditionnelles pour limiter l’apparition de nouveaux problèmes. Ces techniques incluent la revue manuelle du code, les directives de code sécurisé, la formation et les tests d’analyse statique tout au long du cycle du développement logiciel, dès la génération du code, par exemple dans l’IDE. Ainsi, nous pourrons trouver un équilibre entre innovation et sécurité, et rendre les applications plus résilientes face aux menaces. 

De plus, le comportement des assistants de codage par IA générative rend d’autant plus importante la correction des vulnérabilités de sécurité déjà présente dans les bases de code, car moins ces vulnérabilités seront nombreuses, moins leurs suggestions intégreront de problèmes de sécurité.