Comment utiliser /security-review dans GitHub Copilot App avant un Pull Request

On entend souvent dire qu’une revue de sécurité arrive trop tard pour être utile si elle n’est pas exécutée dans une chaîne CI complète. C’est une idée compréhensible, mais incomplète : une vérification très tôt, sur les quelques fichiers que vous venez de modifier, peut éviter qu’une faille évidente ne se retrouve dans un commit ou un Pull Request.

La difficulté consiste toutefois à savoir ce que cette vérification couvre réellement. Comment utiliser /security-review dans GitHub Copilot App sans le confondre avec CodeQL, un analyseur de dépendances ou un contrôle des secrets ? Dans ce guide, vous allez suivre le parcours complet : préparer la session Agent, analyser les changements locaux, lire la gravité et le niveau de confiance, corriger le code, puis relancer l’examen avec une méthode adaptée aux projets audio, vidéo, applicatifs et web.

GitHub Copilot App /security-review : quel problème cette commande résout-elle ?

La commande /security-review est une fonction d’examen à la demande intégrée aux sessions Agent de GitHub Copilot App. Elle porte principalement sur les modifications en cours dans votre espace de travail, plutôt que sur l’ensemble du dépôt comme le ferait une campagne d’analyse plus systématique.

GitHub a annoncé sa disponibilité dans l’application le 14 juillet 2026, en aperçu public. La commande renvoie des résultats hiérarchisés selon la gravité et la confiance, puis propose des pistes de correction pouvant être appliquées et vérifiées dans la même session. Elle vise notamment des problèmes comme les injections, les scripts intersites, la traversée de répertoires, la mauvaise gestion des données et certaines utilisations faibles de la cryptographie. (github.blog)

Dans la pratique, la revue de sécurité dans GitHub Copilot App s’insère entre deux étapes souvent négligées :

• après une modification fonctionnelle importante ;
• avant le commit final ou l’ouverture d’un Pull Request ;
• avant qu’un autre développeur ne doive découvrir le problème au milieu d’une revue générale.

Cette approche est particulièrement utile lorsque vous modifiez rapidement une route d’API, un import de fichier audio, un module de traitement vidéo ou une interface de gestion de médias. Une petite modification peut introduire une validation insuffisante, un chemin de fichier contrôlé par l’utilisateur ou une donnée sensible affichée dans les journaux.

Cependant, /security-review ne constitue pas une certification de sécurité. Il s’agit d’un filtre intelligent et ciblé, pas d’un remplacement de tous vos contrôles.

Les limites à connaître avant de lancer une analyse

Trois contraintes expliquent pourquoi les résultats doivent être interprétés avec prudence.

Première limite : le périmètre dépend du changement visible. Si vous lancez la commande dans une session qui ne contient pas les bons fichiers modifiés, l’analyse peut être pertinente tout en restant incomplète. Un problème situé dans une ancienne fonction non touchée par votre branche peut ne pas ressortir.

Deuxième limite : le contexte applicatif peut manquer. Une validation qui semble dangereuse dans un fichier isolé peut être compensée par une règle d’accès située dans un middleware, un proxy ou une configuration externe. À l’inverse, une fonction apparemment anodine peut devenir critique lorsqu’elle reçoit une donnée provenant d’un formulaire ou d’un service tiers.

Troisième limite : le coût d’une correction automatique mal comprise. Appliquer une suggestion sans relire le flux d’entrée, les tests et les contrats d’API peut supprimer l’alerte tout en cassant une fonction. Dans un logiciel de montage, de design ou de production audio, cela peut se traduire par des fichiers illisibles, des permissions trop restrictives ou des traitements interrompus.

Ajoutez à cela le statut d’aperçu public : l’interface, le comportement et la couverture peuvent évoluer. La documentation officielle précise que /security-review est actuellement en public preview et susceptible de changer. (docs.github.com)

Avant de commencer : le bon environnement et le bon périmètre

Vous devez disposer d’un projet ouvert dans GitHub Copilot App, d’une session Agent active et de modifications en cours. La commande est conçue pour examiner le « workstream » actuel, c’est-à-dire le travail local associé à cette session.

GitHub indique que la commande est proposée aux utilisateurs Copilot Free, Pro, Business et Enterprise pendant l’aperçu public. Dans une organisation, les politiques administratives peuvent néanmoins modifier les fonctions disponibles. (github.blog)

Avant toute analyse, préparez donc une branche réversible. Pour un test d’équipe, créez un commit de référence, ajoutez une modification contrôlée, puis notez les fichiers que vous vous attendez à voir examinés. Cette discipline est plus importante que le simple fait de lancer la commande.

Pour comprendre les conditions générales d’utilisation de votre environnement, vous pouvez également consulter les conditions d’utilisation de Kvmzen, notamment si plusieurs personnes utilisent une même infrastructure de test.

Première étape : ouvrir une session Agent avec des changements réels

Ouvrez le projet dans GitHub Copilot App, puis démarrez ou reprenez une session Agent dédiée. Évitez d’utiliser une conversation rapide pour cette opération : la documentation distingue les conversations générales des sessions isolées associées à un espace de travail et à des modifications. (docs.github.com)

Votre session doit idéalement correspondre à une seule tâche :

• ajout d’une route d’import ;
• modification d’un contrôle d’autorisation ;
• changement du traitement d’un fichier ;
• mise à jour d’une dépendance utilisée par un module sensible ;
• refonte d’un formulaire ou d’un service exposé sur le réseau.

Vérifiez ensuite que les fichiers sont réellement modifiés dans la branche de la session. Si vous avez plusieurs sujets mélangés, réduisez le périmètre avant l’examen. Une commande de sécurité appliquée à vingt changements fonctionnels sans rapport produira plus difficilement des résultats actionnables.

Deuxième étape : lancer /security-review

Dans la zone de saisie de la session Agent, tapez :

/security-review

Puis validez. GitHub documente cette séquence en trois temps : ouvrir une session active contenant des modifications, saisir la commande et examiner les résultats avant de mettre à jour le code. (docs.github.com)

Vous pouvez aussi préciser le périmètre dans votre demande, par exemple :

/security-review Concentrez-vous sur les changements de l’authentification et de l’import de fichiers.

Cette précision ne transforme pas la commande en analyse exhaustive. Elle aide cependant à orienter la lecture vers un risque métier particulier. Pour une application vidéo, vous pouvez demander une attention spéciale aux chemins de fichiers, aux téléchargements et aux appels vers des services externes. Pour un outil audio, mentionnez les métadonnées importées, les fichiers temporaires et les extensions natives.

Le succès de cette étape ne se mesure pas au nombre d’alertes. Le bon signe est l’apparition d’une liste de constats reliés à des fichiers, à une logique identifiable et à une suggestion de correction compréhensible.

Troisième étape : lire la gravité et la confiance sans les confondre

La gravité et la confiance répondent à deux questions différentes :

• La gravité : quel pourrait être l’impact si le problème est exploitable ?
• La confiance : avec quelle certitude l’analyse estime-t-elle avoir identifié un problème réel ?

Une alerte de gravité élevée avec une confiance faible mérite une vérification immédiate, mais pas nécessairement une modification automatique. Une alerte de gravité moyenne avec une confiance élevée peut être plus facile à corriger et plus pertinente pour votre branche actuelle.

Ne vous contentez pas du résumé. Pour chaque découverte, recherchez :

1. la source de la donnée ;
2. le point où elle devient dangereuse ;
3. la fonction ou le composant qui devrait la valider ;
4. le chemin d’exécution jusqu’à la sortie ;
5. la preuve permettant de confirmer ou de réfuter l’alerte.

C’est ici que la notion d’analyse locale des vulnérabilités par Copilot doit être comprise correctement : l’analyse porte sur vos modifications locales, mais elle raisonne avec le contexte que la session peut effectivement consulter. Elle ne connaît pas automatiquement toutes les contraintes opérationnelles de votre organisation.

Rappel important : une confiance élevée n’est pas une preuve formelle et une absence de résultat n’est pas une preuve d’absence de faille. Traitez toujours la sortie comme une piste de revue à confirmer.

Quatrième étape : appliquer une correction sans supprimer le symptôme

Lorsqu’une suggestion est proposée, demandez d’abord à GitHub Copilot App d’expliquer le mécanisme de la vulnérabilité. Cette étape est utile pour éviter les réparations superficielles.

Par exemple, si l’alerte concerne une traversée de répertoires dans un import de fichiers, vérifiez :

• si le nom de fichier provient directement de l’utilisateur ;
• si le chemin final est normalisé ;
• si le fichier reste dans le répertoire autorisé ;
• si les liens symboliques sont traités ;
• si les permissions du processus limitent les conséquences.

Ensuite, appliquez la correction dans une modification séparée lorsque cela est possible. Vous pourrez ainsi comparer le diff avant et après. Pour un problème d’injection, la correction peut nécessiter une requête paramétrée, une validation par liste autorisée ou une séparation claire entre données et instructions. Pour une fuite de secret, il faut retirer la valeur, invalider le secret existant et contrôler les journaux déjà produits.

Ne validez jamais une suggestion uniquement parce qu’elle fait disparaître le texte de l’alerte. Exécutez vos tests unitaires, vos tests d’intégration et, si nécessaire, un scénario négatif reproduisant l’entrée hostile.

Cinquième étape : relancer la revue et vérifier le diff

Après correction, relancez /security-review dans la même session Agent. La documentation officielle présente justement cette possibilité d’appliquer des recommandations puis de les vérifier sans quitter la session. (github.blog)

Utilisez cette séquence en cinq contrôles :

1. confirmer que le fichier corrigé fait toujours partie des changements ;
2. relire le diff complet, y compris les modifications indirectes ;
3. exécuter les tests correspondant au flux vulnérable ;
4. relancer /security-review ;
5. comparer les anciennes et nouvelles alertes.

Si l’alerte disparaît, vérifiez que le comportement fonctionnel attendu est toujours conservé. Si elle persiste, demandez une explication ciblée plutôt qu’une nouvelle réécriture générale. Il peut s’agir d’un autre chemin d’exécution, d’un contrôle placé trop tard ou d’une correction qui ne couvre qu’un seul format d’entrée.

GitHub Copilot App et les outils GitHub : quelle combinaison choisir ?

La question « Copilot et CodeQL : quelle différence ? » appelle une réponse fonctionnelle, pas seulement technique. Ces outils se recouvrent partiellement, mais ils ne sont pas déclenchés au même moment et ne travaillent pas sur le même périmètre.

CodeQL travaille comme une analyse structurée du code, tandis que /security-review fournit une vérification interactive et ciblée des modifications en cours. Dependabot s’intéresse aux composants externes et secret scanning aux informations sensibles exposées ; aucun de ces deux outils ne répond exactement à la question « cette nouvelle logique introduit-elle une faille ? ».

Le bon modèle est donc cumulatif :

• /security-review pendant le développement ;
• tests automatisés après la correction ;
• CodeQL dans la chaîne d’intégration ;
• Dependabot pour les dépendances ;
• secret scanning pour les clés, jetons et identifiants ;
• revue humaine pour les décisions d’architecture.

GitHub présente officiellement /security-review comme un contrôle léger qui complète CodeQL, Dependabot et secret scanning. (github.blog)

Que faire en cas d’absence de résultat, d’erreur ou de faux positif ?

La recherche « que faire face à un faux positif avec /security-review » doit commencer par le périmètre, et non par une nouvelle tentative aveugle.

Si aucun résultat n’apparaît

Vérifiez successivement :

• la session est-elle bien une session Agent active ?
• existe-t-il des modifications locales dans cette session ?
• les fichiers attendus appartiennent-ils à la branche courante ?
• la commande a-t-elle été saisie dans la zone de session et non dans une conversation rapide ?
• le compte ou l’organisation autorise-t-il la fonction en aperçu public ?

Demandez ensuite une synthèse des fichiers examinés. Si la réponse ne permet pas de savoir ce qui a été couvert, complétez avec CodeQL et une revue manuelle.

Si vous identifiez un faux positif

Ne supprimez pas immédiatement le code ou la validation concernée. Documentez :

• la source de l’entrée ;
• la protection déjà appliquée ;
• le test qui démontre cette protection ;
• la raison pour laquelle le chemin signalé n’est pas exploitable.

Vous pouvez ensuite demander à l’Agent de réévaluer l’alerte avec ce contexte. Une bonne réponse doit expliquer pourquoi le risque est réduit, et non simplement changer le niveau de gravité.

Si vous soupçonnez un oubli

Un résultat incomplet peut venir d’un contexte absent, d’une modification trop petite ou d’une vulnérabilité qui exige une compréhension interservices. Inspectez les appels réseau, les permissions, les configurations et les dépendances. Les contrôles basés sur l’IA peuvent accélérer la détection, mais ils ne garantissent ni couverture exhaustive ni absence de fuite.

Cas pratique Kvmzen : construire un dépôt de test reproductible

Pour le cas pratique de Kvmzen, le protocole le plus fiable consiste à utiliser un dépôt de test isolé et une branche réversible. L’objectif n’est pas de fabriquer un résultat spectaculaire, mais de vérifier si la commande aide réellement un développeur à repérer, comprendre et corriger un problème.

Nous avons structuré le scénario autour d’un service qui accepte un chemin de fichier et d’un module qui journalise des paramètres reçus par une requête. Le test doit suivre cette séquence :

1. créer une branche de test à partir d’un état connu ;
2. introduire une faiblesse contrôlée, sans secret réel ni donnée client ;
3. noter précisément les fichiers et lignes modifiés ;
4. ouvrir le projet dans une session Agent de GitHub Copilot App ;
5. exécuter /security-review sans fournir de conclusion attendue ;
6. enregistrer les alertes, leur gravité, leur confiance et les fichiers cités ;
7. vérifier manuellement chaque chemin d’exploitation ;
8. appliquer une correction minimale ;
9. exécuter les tests positifs et négatifs ;
10. relancer la commande et comparer les résultats.

Cette méthode permet de mesurer des éléments utiles : le temps nécessaire pour obtenir une piste, la pertinence du fichier signalé, la qualité de la suggestion, le risque de régression et la capacité de la nouvelle revue à confirmer la correction.

Le résultat observé doit rester attaché à la version de GitHub Copilot App, au modèle disponible, au contenu du dépôt et à la configuration de la session. Il serait donc trompeur d’annoncer un nombre fixe d’alertes comme s’il s’agissait d’une performance permanente. Pour une équipe, consignez plutôt la date, le commit, le périmètre et les décisions humaines prises après l’analyse.

Comment intégrer cette commande avant un Pull Request

Pour répondre concrètement à la question « comment vérifier les vulnérabilités avant de soumettre le code ? », adoptez une règle simple : lancer la revue après chaque changement touchant une frontière de confiance.

Cela comprend notamment :

• authentification et autorisation ;
• téléversement ou téléchargement ;
• appels à une base de données ;
• exécution de commandes ;
• traitement de fichiers audio, vidéo ou graphiques ;
• appels vers des services externes ;
• génération de contenu par un modèle ;
• gestion des journaux et des données personnelles.

Ne bloquez pas toute l’équipe sur une commande interactive. Réservez-la aux changements à risque, puis faites respecter les contrôles systématiques dans la chaîne CI. Un développeur peut obtenir une première réponse en local, tandis que le Pull Request reste soumis à CodeQL, aux tests, aux règles de branche et à la revue humaine.

Si votre poste local est limité, instable ou partagé, un environnement macOS distant peut aussi faciliter la reproduction d’une session propre. Kvmzen propose des environnements Mac mini en location pour les équipes qui doivent conserver une machine de test disponible sans immobiliser leur poste principal. Pour comparer les destinations et les usages, consultez également la présentation des solutions Kvmzen.

Pourquoi un Mac distant peut être préférable à votre poste actuel

Un poste Windows ou Linux peut parfaitement exécuter une partie de ce flux, mais il devient moins pratique lorsque vous devez reproduire plusieurs environnements macOS, tester une application native, vérifier un projet Xcode ou maintenir une session disponible pour une équipe distante. Une machine personnelle présente aussi trois défauts concrets : elle est souvent occupée par d’autres tâches, son état local varie d’un test à l’autre et son accès distant demande une configuration supplémentaire.

La location d’un environnement Mac avec Kvmzen peut alors offrir une base plus cohérente pour les tests : système séparé du poste quotidien, accès distant planifié et possibilité de conserver un projet de reproduction dans un espace dédié. Cela ne rend pas /security-review plus exhaustif et ne remplace pas les contrôles GitHub ; cela réduit surtout les frictions autour de l’environnement de développement et de validation.

Le meilleur test consiste à créer une branche jetable contenant une faiblesse contrôlée, à exécuter /security-review, à effectuer la revue humaine et à relancer l’analyse après correction. Si vous devez répéter ce protocole sur plusieurs versions de macOS ou laisser une machine disponible pour une équipe audio, vidéo ou design, un Mac loué et maintenu à distance sera généralement plus pratique qu’un poste local constamment sollicité.