10 min de lecture - GitHub AI Scan : élargir la revue sans baisser le niveau

Le 16 septembre 2026, GitHub a étendu le périmètre dans lequel AI Scan peut fonctionner. L’analyseur de pull requests ne dépend plus de la configuration par défaut de CodeQL. Une équipe peut donc l’appliquer à des dépôts éligibles dont le langage ou le framework n’est pas couvert par CodeQL. La suppression de cette dépendance ne transforme pas un résultat d’IA en preuve de vulnérabilité ni en autorisation de fusionner.

La documentation de GitHub fixe une limite nette. AI Scan reste en préversion publique, ses résultats sont consultatifs et un ruleset ne peut pas les rendre obligatoires. L’outil analyse les changements admissibles d’une pull request, et non tout le dépôt. Il exclut les pull requests issues de forks et celles créées par Dependabot. Des faux positifs restent possibles. La bonne question La question utile porte sur le manque de couverture à tester, la personne qui validera les résultats et le contrôle existant qui conservera son autorité.

Partez du manque de couverture

L’annonce GitHub du 16 septembre indique qu’AI Scan peut désormais s’exécuter sans configuration CodeQL par défaut. L’analyse du code et AI Scan doivent toujours être activés au niveau adapté du dépôt, de l’organisation ou de l’entreprise. La publication vise les dépôts éligibles d’organisations et de comptes personnels sur GitHub.com pour les clients GitHub Advanced Security. GitHub Enterprise Server n’entre pas dans le périmètre annoncé.

La documentation détaillée d’AI Scan ajoute des conditions importantes. Pendant la préversion, le service exige des licences GitHub Advanced Security et GitHub Copilot. Son utilisation consomme des crédits IA. Il cible des lacunes de CodeQL, notamment pour PHP, Shell ou Bash, la configuration Terraform, les Dockerfiles, JSP et Blazor. La liste prise en charge peut évoluer.

Classez les dépôts par langage, framework, exposition et contrôles déjà en place. Repérez ensuite le code des pull requests qui reçoit peu ou pas d’analyse statique. Une application réunissant Terraform, des scripts de déploiement et un service PHP peut présenter un manque évident. Un dépôt déjà couvert par CodeQL, un autre outil SAST et une revue spécialisée demande une autre justification.

Ne comptez pas uniquement les dépôts. Notez les fichiers et les changements réellement accessibles à l’analyseur. AI Scan ne traite ni l’ensemble d’un dépôt, ni les pull requests provenant d’un fork, ni celles de Dependabot. Une contribution importante ou une mise à jour de dépendance peut donc rester hors de son champ même lorsque la fonction est active.

Séparez la détection de l’application d’une règle

GitHub indique qu’AI Scan se lance à la création d’une pull request, puis après chaque nouveau commit, si le dépôt et le réglage effectif sont éligibles. L’outil travaille directement sur le code de la pull request, peut rechercher du contexte dans le dépôt et n’utilise pas les fichiers d’instructions personnalisés. Ses résultats apparaissent dans la pull request avec un indicateur IA et peuvent inclure une correction proposée.

Ce parcours aide à chercher des failles. Il ne constitue pas une politique de fusion. Les résultats restent consultatifs, ne peuvent pas devenir obligatoires dans les rulesets et ne figurent pas comme alertes de fond dans la vue de sécurité du dépôt.

Le Secure Software Development Framework du NIST préconise une sélection des pratiques fondée sur le risque. Il invite les équipes à tenir compte des besoins métier, du coût et des dépendances entre pratiques. Le guide distinct du NIST sur la vérification par les développeurs place l’analyse statique à côté de la modélisation des menaces, des tests automatisés, de la recherche de secrets et du fuzzing. Ces recommandations ne couvrent pas toute la vérification logicielle.

Organisez le travail sur cette base. AI Scan peut fournir un signal sur un Dockerfile ou un module Terraform modifié. Il ne confirme pas la conception des autorisations de l’application, ne teste pas un service déployé et n’examine pas chaque mise à jour de dépendance. Conservez les contrôles chargés de ces tâches.

Menez un pilote délimité

Choisissez peu de dépôts, avec un manque connu et des relecteurs qui comprennent le code. Avant d’étendre l’outil, mesurez les déclenchements, le travail de qualification et les crédits consommés.

Une fiche de pilote par dépôt peut tenir sur une page :

• dépôt, langage et framework ;
• chemins sensibles et responsable actuel de la revue ;
• analyseurs existants et périmètre de chacun ;
• niveau d’activation d’AI Scan et date ;
• parcours de PR exclus, notamment forks et Dependabot ;
• usage mesuré, effort de qualification et décision pour chaque résultat.

Prenez des pull requests représentatives sur des dépôts sans incident en cours. Maintenez les mêmes tests et règles de revue, puis observez AI Scan pendant un nombre fixé de PR éligibles ou une durée convenue. Décidez de cette limite avant l’activation.

Pour chaque résultat, consignez le commit, le fichier et la ligne concernés, la faiblesse annoncée, les éléments utilisés pour la vérifier, la personne chargée de la revue, la décision finale et l’éventuelle correction. Les décisions utiles comprennent « confirmé », « plausible mais non prouvé », « faux positif », « doublon » et « hors périmètre ». Ne rejetez pas un résultat parce que le correctif proposé échoue. Ne l’acceptez pas non plus parce que l’explication paraît précise.

La fiche OWASP sur la revue sécurisée du code présente la revue manuelle comme un complément aux tests automatisés. Elle réserve le jugement humain à la logique métier, aux contrôles complexes, aux défauts liés au contexte et à la validation des faux positifs.

Vérifiez l’affirmation, puis le correctif

Le résultat d’un analyseur formule une hypothèse. Reconstituez le chemin avant de modifier le code : entrée, frontière de confiance, validation, opération sensible et conditions d’accès. Pour une faille d’autorisation, vérifiez aussi le middleware, le framework et les services en aval.

Écrivez ensuite le plus petit test qui échouerait si la faiblesse était réelle : test unitaire d’un parseur, test d’intégration d’un contrôle d’accès ou test de politique Terraform. Exécutez aussi les analyseurs déterministes. Un désaccord entre outils demande d’examiner leurs hypothèses.

Traitez toute correction suggérée comme un code non fiable. Vérifiez si elle ferme le chemin, casse une compatibilité ou déplace le risque, puis relancez le test ciblé et la suite habituelle.

Un résultat sensible peut demander une décision d’incident. Pour un identifiant exposé, le responsable décide d’une révocation ou d’un renouvellement selon l’exposition. Une faille potentiellement exploitable dans du code déployé rejoint le processus de gestion des vulnérabilités.

Mesurez le signal et le coût d’exploitation

Le premier pilote doit établir si AI Scan apporte une couverture utile et qualifiable. Comptez les pull requests éligibles, les analyses observées, les résultats, ceux qui sont confirmés, les faux positifs, les doublons et les problèmes déjà repérés par les contrôles existants. Relevez le temps de revue et les crédits IA à partir des informations de facturation disponibles.

Évitez l’objectif « zéro résultat ». Un analyseur silencieux peut ne pas s’être exécuté ou ignorer le code modifié. De nombreux résultats peuvent aussi indiquer une détection utile ou des règles bruyantes. Le registre des décisions distingue ces situations.

Cherchez les types de failles qui se répètent. Si plusieurs résultats confirmés concernent la même construction Shell dangereuse, corrigez l’utilitaire partagé ou la règle de développement. Ajoutez un contrôle déterministe lorsque c’est possible. Le gain durable vient de la prévention, pas de la redécouverte du même motif dans chaque pull request.

Étendez le pilote si les PR visées déclenchent bien les analyses, si les relecteurs traitent les résultats dans leur flux normal, si les découvertes justifient le coût et si un autre contrôle couvre les exclusions. Réduisez-le si la file s’allonge ou si l’absence de résultat devient une approbation.

Gardez une décision réversible

Documentez les réglages de l’entreprise, de l’organisation et du dépôt qui produisent l’état effectif. La hiérarchie des permissions GitHub reste applicable et la fonction n’est pas autorisée par défaut au niveau de l’entreprise. Nommez les personnes capables de l’activer, les dépôts qui peuvent s’en retirer et le responsable du suivi de l’usage. Joignez la documentation en vigueur à la décision, car les conditions de la préversion et les langages pris en charge peuvent changer.

Fixez une date de réexamen et une condition d’arrêt. Un dépôt peut quitter le pilote si le bruit devient excessif, si le langage obtient une meilleure couverture déterministe, si le coût dépasse la valeur observée ou si le traitement des données du produit ne correspond plus aux exigences de l’organisation. Avant d’activer un service d’analyse cloud sur du code source sensible, le responsable doit aussi examiner les conditions du produit, sa documentation de confidentialité et les autorisations contractuelles. Cet article ne vaut pas approbation.

Les équipes qui souhaitent replacer ce pilote dans un cadre plus large peuvent le relier aux garde-fous du développement assisté par IA et à la revue des frontières de confiance dans GitHub Actions. Les questions de produit, de livraison ou de gouvernance qui dépassent le dépôt relèvent d’une discussion distincte sur les services.

Sources et limites

Nous avons ouvert et vérifié chaque source ci-dessous le 17 septembre 2026.

• L’annonce GitHub du 16 septembre établit la suppression de la dépendance à la configuration CodeQL par défaut, le périmètre de la préversion publique et l’exclusion de GitHub Enterprise Server.
• La documentation GitHub d’AI Scan définit l’éligibilité, le fonctionnement, les licences, la facturation, les exemples pris en charge, les résultats et les limites actuelles.
• Le Secure Software Development Framework du NIST apporte une recommandation indépendante pour choisir et combiner les pratiques de développement sécurisé selon les risques et les besoins métier.
• Le rapport NIST IR 8397 présente l’analyse statique comme l’une des techniques de vérification à la disposition des développeurs.
• La fiche OWASP sur la revue sécurisée du code explique comment la revue manuelle et la validation des faux positifs complètent les outils automatisés.

GitHub constitue la source primaire sur son service en préversion. Le NIST et OWASP ne certifient ni GitHub AI Scan ni ce pilote. Nous n’avons pas activé la fonction, mesuré sa qualité de détection, audité ses modèles ou évalué les licences, la confidentialité et la situation contractuelle d’un client. Vérifiez la documentation actuelle et le comportement observé du dépôt avant de modifier un processus de sécurité.