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

À propos de la correction automatique pour CodeQL code scanning

La correction automatique d’Code scanning est une extension basée sur GitHub Copilot de l’code scanning qui fournit aux utilisateurs des recommandations ciblées pour les aider à corriger les alertes d’code scanning, 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 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. Autofix utilise les API internes GitHub Copilot des API internes s'interfaçant avec le grand modèle de langage GPT-4o d'OpenAI, qui possède des capacités génératives suffisantes pour produire à la fois des suggestions de corrections dans le code et des textes explicatifs pour ces corrections.

Dans le tableau de bord de vue d’ensemble de la sécurité d’une organisation, vous pouvez afficher le nombre total de suggestions de code générées sur les demandes de tirage ouvertes et fermées dans l’organisation pendant une période donnée. Pour plus d'informations, consultez « Affichage des insights de sécurité » dans la documentation GitHub Enterprise Cloud.

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.

Langues prises en charge

Code scanning autofix prend en charge la génération de correctifs pour un sous-ensemble de requêtes incluses dans les suites de requêtes par défaut et étendues à la sécurité pour C#, C/C++, Go, Java/Kotlin, Swift, JavaScript/TypeScript, Python et Ruby. Pour plus d’informations sur ces suites de requêtes, consultez « Suites de requêtes CodeQL ».

Processus de génération de suggestions

Lorsque la correction automatique est activée pour un référentiel, les alertes code scanning identifiées par des requêtes CodeQL prises en charge envoient une entrée au LLM. Si le LLM peut générer une solution potentielle, celle-ci est présentée sous forme de suggestion.

GitHub envoie au LLM diverses données 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.
  • 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. Ils sont affichés sous forme de suggestions. Aucune interaction d’utilisateur n’est nécessaire au-delà de l’activation de code scanning sur le codebase et de la création d’une demande de tirage.

Le processus de génération de correctifs ne collecte ni n’utilise aucune donnée client au-delà de l’étendue décrite ci-dessus. Par conséquent, l’utilisation de cette fonctionnalité est régie par les conditions générales existantes associées aux données GitHub Advanced Security. De plus, les données gérées par la correction automatique code scanning n’est strictement pas employée à des fins d’entraînement LLM. Pour plus d’informations sur les conditions générales de GitHub Advanced Security, consultez « Conditions GitHub pour les produits et fonctionnalités supplémentaires ».

Qualité des suggestions

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

Le faisceau de tests comprend un ensemble de plus de 2 300 alertes provenant d’un ensemble diversifié de référentiels publics où le code mis en évidence a une couverture de test. Les suggestions 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 suggestions 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

Nous testons l’efficacité des suggestions 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

L’ensemble de tests contient un large éventail de types de projets et alertes différents. Nous prévoyons que les suggestions pour d’autres projets utilisant des langages pris en charge par la correction automatique doivent suivre un modèle similaire.

• La correction automatique est susceptible d’ajouter une suggestion de code à la majorité des alertes.
• Lorsque les développeurs évaluent les suggestions, 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.

Limites des suggestions

Lorsque vous examinez une suggestion d'autofix, vous devez toujours tenir compte des limites de l'IA et modifier les changements 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 ».

Limites des suggestions de codes

• 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

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

La meilleure façon d'atténuer les limites des suggestions d'autofixation est 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

• « À propos des alertes d’analyse du code »
• Triage des alertes d’analyse du code dans les demandes de tirage (pull request) dans la documentation GitHub Enterprise Cloud