AI Scan GitHub : analyser un dépôt entier sans attendre une pull request

AI Scan GitHub peut désormais explorer un dépôt entier, et non plus seulement les changements d’une pull request. Cette préversion publique ouvre une voie complémentaire à CodeQL pour rechercher des vulnérabilités dans des langages ou des frameworks moins bien couverts. Pour une équipe produit, la valeur ne vient pas d’un nouveau bouton d’analyse : elle vient d’un périmètre assumé, d’un budget maîtrisé et d’une vraie boucle de traitement des alertes.

Ce que couvre AI Scan GitHub à l’échelle du dépôt

Après activation de la politique au niveau de l’entreprise, les responsables d’organisation ou de sécurité peuvent activer AI Scan GitHub par dépôt. Les personnes disposant du droit d’écriture sur le code scanning démarrent ensuite une analyse depuis l’interface dédiée. Chaque passage cible le dernier commit de la branche par défaut : ce n’est donc pas un contrôle continu déclenché à chaque commit, ni un remplacement automatique de la revue de code.

GitHub indique que le scanner agentique se concentre sur les zones les plus susceptibles de contenir une vulnérabilité et travaille dans un budget de temps fixe. Lorsque CodeQL est aussi activé, AI Scan évite de remonter les problèmes déjà signalés par CodeQL. Les résultats arrivent dans la même liste d’alertes de code scanning : cela facilite le tri, mais ne supprime ni le besoin de qualification ni celui de priorisation.

Démarrer par un pilote, pas par tous les dépôts

La préversion mérite un pilote délibéré. Choisissez un dépôt actif, avec une branche par défaut saine, un responsable technique identifié et un flux de correction réaliste. Un ancien monolithe très exposé peut être un bon candidat si l’équipe sait absorber des investigations ; un dépôt abandonné produira surtout une liste sans propriétaire.

Trois décisions à écrire avant le premier scan

1. Le résultat attendu : repérer des zones à auditer, préparer une campagne de sécurité ou accélérer le traitement d’un risque connu. Sans objectif, les alertes deviennent vite du bruit.
2. Le responsable de la file : nommez la personne ou l’équipe qui qualifie les alertes et décide si elles sont corrigées, acceptées temporairement ou fermées avec justification.
3. Le plafond de consommation : AI Scan consomme des crédits Code Security AI. Définissez un budget et observez le coût d’un cycle complet avant d’élargir le périmètre.

Prévoir la remédiation avant de lancer une analyse

Une alerte AI Scan peut être affectée, reliée à une pull request ou ajoutée à une campagne de sécurité. En revanche, elle ne se ferme pas d’elle-même lorsqu’un correctif est fusionné : il faut relancer une analyse pour vérifier le correctif et fermer l’alerte. Cette étape doit figurer dans votre définition de terminé, au même titre qu’un test de non-régression.

Conservez aussi les protections que vous avez déjà construites. AI Scan sur les pull requests aide à examiner les changements entrants ; l’analyse du dépôt entier apporte une vue de rattrapage sur l’existant. Elles répondent à deux moments différents du cycle de vie. De même, CodeQL reste un socle d’analyse par règles, avec lequel GitHub prévoit explicitement une déduplication.

Une capacité de sécurité à piloter comme un produit

Mesurez surtout les décisions utiles : alertes confirmées, délai de qualification, corrections effectivement vérifiées et enseignements réinjectés dans les pratiques de développement. Évitez de compter les alertes comme un indicateur de maturité. Une analyse plus riche peut temporairement révéler une dette déjà présente ; ce qui compte est votre capacité à la comprendre et à la réduire sans interrompre inutilement la livraison.