Skip to main content

À propos de la correction automatique de l’analyse du code CodeQL

Découvrez comment GitHub utilise l’IA afin de suggérer des correctifs potentiels pour les alertes code scanning trouvées par CodeQL dans votre demande de tirage.

Qui peut utiliser cette fonctionnalité ?

La correction automatique pour code scanning est disponible uniquement pour les utilisateurs de GitHub Enterprise Cloud qui disposent de GitHub Advanced Security. Pour plus d’informations, consultez « À propos de GitHub Advanced Security ».

À propos de la correction automatique pour CodeQL code scanning

La correction automatique est une extension basée sur l’intelligence artificielle de code scanning qui fournit aux utilisateurs des recommandations ciblées pour les aider à corriger les alertes code scanning dans les demandes de tirage, afin qu’ils puissent éviter d’introduire de nouvelles failles de sécurité. Les correctifs potentiels sont générés automatiquement par de grands modèles de langage (LLM) sur la base de données provenant du codebase, de la demande de tirage et de l’analyse CodeQL.

La correction automatique Code scanning génère des correctifs potentiels pertinents pour le code source existant, et traduit la description et l’emplacement d’une alerte en modifications de code susceptibles de corriger l’alerte. Le système de correction automatique utilise le grand modèle de langage OpenAI GPT-4, qui dispose de capacités de génération suffisantes afin de produire des correctifs suggérés dans le code et dans le texte explicatif de ces correctifs.

Expérience développeur

Les utilisateurs GitHub Advanced Security peuvent déjà voir toutes les alertes de sécurité détectées par code scanning à l’aide de CodeQL afin d’analyser leurs demandes de tirage. Toutefois, les développeurs bénéficient souvent de peu de formation sur la sécurité du code. Par conséquent, la résolution de ces alertes nécessite un effort considérable. D’abord, ils doivent lire et comprendre l’emplacement et la description de l’alerte, puis modifier le code source pour corriger la vulnérabilité.

La correction automatique Code scanning crée une solution à faible barrière d’entrée pour les développeurs en combinant des informations sur les meilleures pratiques avec des détails du codebase et une alerte visant à suggérer un correctif potentiel au développeur. Au lieu de commencer par une recherche d’informations sur la vulnérabilité, le développeur commence par une suggestion de code illustrant une solution potentielle pour son codebase. Le développeur évalue le correctif potentiel afin de déterminer s’il s’agit de la meilleure solution pour son codebase et de s’assurer qu’il conserve le comportement attendu.

Après avoir validé un correctif suggéré ou modifié, le développeur doit toujours vérifier que les tests d’intégration continue (CI) pour le codebase continuent de réussir et que l’alerte est affichée comme résolue avant de fusionner sa demande de tirage.

Processus de génération de correction automatique

Lorsque la correction automatique est activée pour un référentiel, les alertes code scanning identifiées dans une demande de tirage par des requêtes CodeQL prises en charge envoient une entrée au LLM. Si le LLM est apte à générer un correctif potentiel, le correctif s’affiche dans la demande de tirage en tant que commentaire de suggestion.

GitHub envoie au LLM diverses données de la demande de tirage et de l’analyse CodeQL.

  • Données d’alerte CodeQL au format SARIF. Pour plus d’informations, consultez « Prise en charge de SARIF pour l’analyse du code ».
  • Code de la version actuelle de la branche de demande de tirage.
    • Extraits de code courts autour de chaque emplacement source, emplacement de récepteur et emplacement référencé dans le message d’alerte ou inclus dans le chemin d’accès de flux.
    • Environ les 10 premières lignes de chaque fichier impliqué dans l’un de ces emplacements.
  • Texte d’aide pour la requête CodeQL qui a identifié le problème. Pour bénéficier d’exemples, consultez « Aide sur les requêtes CodeQL ».

Toutes les suggestions de correction automatique sont générées et stockées dans le back-end code scanning. Elles sont affichées sous forme de commentaires de suggestion dans la demande de tirage. Aucune interaction d’utilisateur n’est nécessaire au-delà de l’activation de code scanning sur le codebase et de la création de la demande de tirage.

Qualité des suggestions de correction automatique

GitHub utilise un atelier de test automatisé afin de surveiller en continu la qualité des suggestions de correction automatique. Ainsi, nous pouvons comprendre comment les suggestions de correction automatique générées par le LLM changent au fur et à mesure du développement du modèle.

L’atelier de test comprend un ensemble de plus de 700 alertes JavaScript/TypeScript à partir d’un ensemble diversifié de référentiels publics où le code mis en surbrillance présente une couverture de test. Les suggestions de correction automatique de ces alertes sont testées afin d’en déterminer l’exactitude, soit la quantité de modifications nécessaires par un développeur avant qu’il puisse les commiter dans le codebase. Pour la plupart des alertes de test, les corrections automatiques générées par le LLM peuvent être validées en l’état pour corriger l’alerte tout en continuant à réussir l’ensemble des tests CI existants.

En outre, le système est soumis à un test de contrainte afin de détecter tout préjudice potentiel (souvent appelé Red Teaming), et un système de filtrage sur le LLM permet d’empêcher l’affichage des suggestions potentiellement dangereuses pour les utilisateurs.

Comment GitHub teste les suggestions de correction automatique

Nous testons l’efficacité des suggestions de correction automatique en fusionnant toutes les modifications suggérées, non modifiées, avant d’exécuter code scanning et les tests unitaires du référentiel sur le code résultat.

  1. L’alerte code scanning a-t-elle été corrigée par la suggestion ?
  2. Le correctif a-t-il introduit de nouvelles alertes code scanning ?
  3. Le correctif a-t-il introduit des erreurs de syntaxe que CodeQL peut détecter ?
  4. Le correctif a-t-il modifié la sortie de l’un des tests de référentiel ?

En outre, nous vérifions ponctuellement de nombreuses suggestions réussies et nous assurons qu’elles corrigent l’alerte sans introduire de nouveaux problèmes. Lorsqu’une ou plusieurs de ces vérifications ont échoué, notre triage manuel a montré que, dans de nombreux cas, le correctif proposé était presque correct, mais avait besoin de modifications mineures qu’un utilisateur pouvait identifier et effectuer manuellement.

Efficacité sur d’autres projets JavaScript/TypeScript

L’ensemble de tests contient un large éventail de types de projets et alertes différents. Selon nos prévisions, les correctifs automatiques pour d’autres projets JavaScript/TypeScript doivent suivre un modèle semblable.

  • La correction automatique est susceptible d’ajouter une suggestion de code à la majorité des alertes pour les projets JavaScript/TypeScript.
  • Lorsque les développeurs évaluent les suggestions de correction automatique, nous nous attendons à ce que la majorité des correctifs puisse être validée sans modification ou avec des mises à jour mineures afin de refléter le contexte plus large du code.
  • Un petit pourcentage de correctifs suggérés reflète une incompréhension de taille du codebase ou de la vulnérabilité.

Toutefois, chaque projet et codebase étant unique, les développeurs peuvent avoir besoin de modifier un pourcentage plus important de correctifs suggérés avant de les valider. La correction automatique fournit des informations précieuses pour vous aider à résoudre les alertes code scanning. Mais en fin de compte, il est de votre responsabilité d’évaluer la modification proposée et de garantir la sécurité et la précision de votre code.

Remarque : le système ne suggère pas de correctifs pour tous les types d’alertes code scanning identifiés par CodeQL. La correction automatique est prise en charge pour un sous-ensemble des requêtes JavaScript/TypeScript CodeQL par défaut, et le LLM est limité dans sa capacité opérationnelle. En outre, chaque correctif suggéré est testé avant d’être ajouté à une demande de tirage. Si aucune suggestion n’est disponible ou si le correctif suggéré échoue lors de tests internes, aucune suggestion de correction automatique n’est affichée.

Limites des suggestions de correction automatique

Lorsque vous passez en revue une suggestion de correction automatique, vous devez toujours prendre en compte les limites de l’IA et modifier les modifications si nécessaire avant de les accepter. Vous devez également envisager de mettre à jour le test CI et la gestion des dépendances pour un référentiel avant d’activer la correction automatique pour code scanning. Pour plus d’informations, consultez « Atténuation des limites des suggestions de correction automatique ».

Limites des suggestions de codes de correction automatique

  • Langages de programmation : un sous-ensemble de langages de programmation est pris en charge, initialement JavaScript et TypeScript uniquement. La prise en charge de langues supplémentaires est ajoutée, mais il n’existe aucune intention de prendre en charge toutes les langues CodeQL.
  • Langues humaines : le système utilise principalement des données en anglais, notamment les invites envoyées au système, le code vu par les LLM dans leurs jeux de données et les cas de test utilisés à des fins d’évaluation interne. Les suggestions générées par le LLM peuvent présenter un taux de réussite inférieur pour le code source et les commentaires écrits dans d’autres langues et à l’aide d’autres jeux de caractères.
  • Erreurs de syntaxe : le système peut suggérer des correctifs qui ne sont pas des modifications de code correctes sur le plan syntaxique. Il importe donc d’exécuter des vérifications syntaxiques sur les demandes de tirage.
  • Erreurs d’emplacement : le système peut suggérer des correctifs qui équivalent à du code correct sur le plan syntaxique, mais qui sont suggérés au mauvais emplacement. Ainsi, si un utilisateur accepte un correctif sans modifier l’emplacement, il introduit une erreur de syntaxe.
  • Erreurs sémantiques : le système peut suggérer des correctifs qui sont valides sur le plan syntaxique, mais qui modifient la sémantique du programme. Le système ne comprend pas l’intention du programmeur ou du codebase concernant le comportement du code. L’utilisation d’une bonne couverture de test permet aux développeurs de vérifier qu’un correctif ne modifie pas le comportement du codebase.
  • Failles de sécurité et correctifs trompeurs : le système peut suggérer des correctifs qui ne parviennent pas à corriger la faille de sécurité sous-jacente et/ou introduisent de nouvelles failles de sécurité.
  • Correctifs partiels : le système peut suggérer des correctifs qui ne traitent que partiellement la faille de sécurité, ou ne conservent que partiellement la fonctionnalité de code prévue. Le système ne voit qu’un petit sous-ensemble du code dans le codebase et ne produit pas toujours des solutions globalement optimales ou correctes.

Limites des suggestions de dépendances de correction automatique

Parfois, un correctif suggéré inclut une modification des dépendances du codebase. Si vous utilisez un système de gestion des dépendances, toutes les modifications sont mises en surbrillance automatiquement pour que le développeur puisse les passer en revue. Avant de fusionner une demande de tirage, vérifiez toujours que toutes les modifications de dépendance sont sécurisées et conservent le comportement attendu du codebase.

  • Dépendances nouvelles ou mises à jour : le système peut suggérer l’ajout ou la mise à jour de dépendances logicielles dans le cadre d’un correctif suggéré. Par exemple, en suggérant de modifier le fichier package.json pour les projets JavaScript afin d’ajouter des dépendances à partir de npm.
  • Dépendances non prises en charge ou non sécurisées : le système ne connaît pas les versions prises en charge ou sécurisées d’une dépendance existante.
  • Dépendances fabriquées : le système a une connaissance incomplète des dépendances publiées dans l’écosystème plus large. Cela peut entraîner l’ajout, par des suggestions, d’une nouvelle dépendance à des logiciels malveillants publiés par des attaquants sous un nom de dépendance statistiquement probable.

Atténuation des limites des suggestions de correction automatique

Pour atténuer les limites des suggestions de correction automatique de la meilleure manière qui soit, il convient de suivre les meilleures pratiques. Il s’agit, par exemple, de l’utilisation de tests CI des demandes de tirage pour vérifier que les exigences fonctionnelles ne sont pas affectées, et de l’utilisation de solutions de gestion des dépendances, telles que l’API et l’action de révision des dépendances. Pour plus d’informations, consultez « À propos de la vérification des dépendances ».

Il est important de se rappeler que l’auteur d’une demande de tirage est tenu responsable de la manière dont il répond aux commentaires de révision et aux modifications de code suggérées, qu’ils soient proposés par des collègues ou des outils automatisés. Les développeurs doivent toujours examiner de manière critique les suggestions de modifications de code. Si nécessaire, ils se doivent de modifier les modifications suggérées pour s’assurer que le code et l’application résultants sont corrects, sécurisés, répondent aux critères de performances et satisfont toutes les autres exigences fonctionnelles et non fonctionnelles pour l’application.

Étapes suivantes