GitHub ajoute une commande /security-review à l'application Copilot. Depuis une session de travail contenant des changements en cours, le développeur peut demander une analyse ciblée des vulnérabilités avant même d'ouvrir une pull request. Le résultat classe les constats par gravité et niveau de confiance, puis propose des corrections à appliquer et vérifier dans la même session.
La fonction est disponible en préversion publique pour les utilisateurs Copilot Free, Pro, Business et Enterprise. Elle vise notamment les injections, le cross-site scripting, la manipulation dangereuse de données, la traversée de chemins et la cryptographie faible. Ce nouveau contrôle réduit la distance entre l'écriture et la détection, mais il ne doit pas devenir un feu vert automatique pour fusionner.
La réponse rapide
| Question | Réponse opérationnelle |
|---|---|
| Que scanne la commande ? | Les changements du workstream actif dans l'application Copilot. |
| Remplace-t-elle CodeQL ? | Non. Elle complète l'analyse déterministe et le suivi centralisé de code scanning. |
| Peut-elle bloquer une fusion ? | Pas seule. Un blocage fiable doit passer par les règles de dépôt et les contrôles CI. |
| Les corrections sont-elles sûres ? | Non par défaut. Chaque suggestion doit être relue et testée. |
| Faut-il l'utiliser sur chaque changement ? | Elle est surtout utile avant publication sur du code exposé, sensible ou manipulant des données. |
| Est-elle stable ? | Non, /security-review est encore en préversion publique. |
Le meilleur positionnement est celui d'une revue précoce à la demande. Elle peut trouver un problème pendant que le contexte est encore frais et avant que le diff ne soit noyé dans une grande pull request. Elle ne possède toutefois ni l'exhaustivité, ni la reproductibilité, ni la gouvernance d'une chaîne de sécurité complète.
Une revue dans le flux de travail local
La commande s'exécute dans une session active de l'application Copilot. GitHub parle du « workstream » courant : l'agent dispose des changements réalisés dans cette session et peut les comparer au contexte du dépôt. Le développeur saisit /security-review, attend l'analyse puis examine une liste priorisée de constats.
Cette proximité apporte un avantage concret. Une injection SQL signalée quelques minutes après la modification est moins coûteuse à corriger qu'une alerte reçue après une longue CI ou durant la revue finale. L'auteur sait encore pourquoi le code existe, quelles contraintes ont guidé l'implémentation et quels tests sont disponibles.
Elle crée aussi une limite. Ce qui n'est pas visible dans le workstream peut manquer : configuration déployée ailleurs, infrastructure, dépendance dynamique, règle de pare-feu, schéma réel de la base ou comportement d'un service tiers. Une analyse convaincante d'un diff incomplet reste une analyse incomplète.
Les vulnérabilités ciblées
GitHub annonce un réglage orienté vers des constats à fort impact et à forte confiance. Les catégories mentionnées couvrent :
- les injections dans les requêtes, commandes ou interpréteurs ;
- le cross-site scripting lorsque des données non fiables atteignent une sortie HTML ;
- la gestion non sûre de données sensibles ;
- la traversée de chemins et les accès de fichiers mal bornés ;
- l'emploi de primitives cryptographiques faibles ou incorrectes.
Cette sélection vise à limiter le bruit. Un outil qui commente chaque détail de style finit par être ignoré. Mais « forte confiance » ne signifie pas absence de faux positifs, et la liste annoncée ne constitue pas une garantie de couverture. Les défauts d'autorisation métier, les courses concurrentes, les erreurs de logique ou les interactions entre services demandent souvent davantage de contexte qu'un motif vulnérable classique.
Une équipe doit mesurer l'outil sur ses propres incidents et vulnérabilités historiques. Si les dix derniers problèmes graves concernaient surtout l'isolation entre clients ou des permissions cloud, un bon score sur les injections ne suffit pas à prouver l'adéquation.
Trois produits à ne pas confondre
GitHub propose désormais plusieurs mécanismes dont les noms peuvent sembler proches :
| Mécanisme | Moment | Rôle principal |
|---|---|---|
/security-review | Pendant une session Copilot | Retour rapide sur les changements en cours. |
| Copilot code review | Sur une pull request ou dans un IDE | Revue plus générale : bugs, conception, qualité et sécurité. |
| Code scanning / CodeQL | Dans le dépôt et la CI | Analyse suivie, alertes persistantes, chemins de données et règles de fusion. |
Dependabot couvre encore un autre angle : les versions et vulnérabilités connues des dépendances. Secret scanning cherche les identifiants exposés. Aucun de ces contrôles n'est un doublon parfait des autres.
/security-review est rapide et conversationnel. CodeQL produit une analyse reproductible, conserve les alertes, suit leur apparition et peut participer à une règle empêchant la fusion. La revue Copilot peut raisonner plus largement sur une pull request, mais GitHub rappelle qu'elle peut manquer des problèmes et qu'une validation humaine reste nécessaire.
La bonne architecture superpose des contrôles aux propriétés différentes. Remplacer tous les scanners par une conversation avec un modèle réduirait la traçabilité au moment où l'organisation en a le plus besoin.
Le risque du correctif plausible
Une suggestion générée peut sembler précise, compiler et pourtant déplacer la vulnérabilité. Échapper une chaîne à un endroit peut laisser un second chemin non protégé. Ajouter une validation côté interface ne protège pas l'API. Remplacer un algorithme cryptographique sans gérer les données existantes peut bloquer les comptes ou créer une migration incomplète.
Il faut donc traiter le correctif comme une contribution externe :
- comprendre le scénario d'attaque décrit ;
- confirmer que la donnée contrôlée par l'attaquant atteint réellement l'opération sensible ;
- écrire un test qui échoue avant le correctif ;
- appliquer une modification minimale ;
- relancer tests fonctionnels, analyse statique et tests de sécurité ;
- vérifier les chemins voisins et les appels similaires ;
- faire relire le diff par une personne responsable du composant.
Le score de confiance aide à ordonner les investigations ; il ne constitue pas une preuve. Une alerte « élevée » peut être neutralisée par une validation en amont invisible. Une alerte absente ne prouve pas qu'une autorisation est correcte.
Ne pas envoyer plus de contexte que nécessaire
Une analyse de sécurité pousse naturellement à montrer configuration, journaux et extraits de code sensibles. Avant de lancer la commande, une organisation doit connaître ses paramètres Copilot, sa politique de conservation et les données autorisées dans le service. Un secret réel ne doit jamais être collé dans la conversation pour aider l'agent à comprendre une authentification.
Le workstream peut également contenir des fichiers temporaires, des migrations avec données d'exemple ou des configurations locales. Les règles du dépôt doivent exclure les secrets et rappeler quelles ressources sont confidentielles. Un scanner de secrets local et une protection au push restent nécessaires, car la revue de sécurité n'est pas annoncée comme un coffre-fort ni comme un détecteur exhaustif d'identifiants.
Dans une entreprise, le pilote doit commencer sur un dépôt non critique ou un service représentatif avec données factices. L'objectif est d'observer ce qui est analysé, ce qui apparaît dans les résultats et comment les développeurs réagissent, avant d'étendre la fonction aux composants réglementés.
Une préversion ne doit pas devenir une dépendance bloquante
GitHub précise que la commande est en préversion publique et susceptible d'évoluer. Son interface, sa disponibilité ou la forme des résultats peuvent changer. Elle ne doit donc pas être l'unique étape exigée par une procédure de livraison que personne ne sait contourner en cas d'indisponibilité.
Les contrôles obligatoires doivent rester automatisés et observables dans la CI. La commande peut être recommandée pour les fichiers sensibles, intégrée à une checklist ou utilisée avant une revue humaine. Si elle devient indispensable, l'équipe doit documenter un mode dégradé : analyse statique locale, revue par un référent sécurité ou pipeline CodeQL.
Cette distinction évite aussi les captures d'écran utilisées comme preuve. Une conversation ponctuelle ne fournit pas forcément un artefact signé, comparable et conservé comme un résultat SARIF. Pour un audit, les alertes du dépôt et les journaux de CI sont plus solides.
Comment conduire un pilote utile
Un pilote de deux à quatre semaines peut suivre un protocole simple :
- choisir deux dépôts représentant les langages et risques principaux ;
- définir les changements qui déclenchent une revue : authentification, requêtes, fichiers, rendu HTML, chiffrement et permissions ;
- conserver la CI et la revue humaine existantes ;
- classer chaque constat comme vrai positif, faux positif ou non vérifiable ;
- noter les vulnérabilités trouvées plus tard mais manquées par la commande ;
- mesurer le temps de triage et de correction ;
- contrôler les correctifs suggérés avec des tests de régression ;
- recueillir les retours sans demander aux développeurs de déclarer eux-mêmes le produit « efficace » ;
- comparer les résultats à CodeQL, aux scanners de dépendances et aux revues humaines ;
- décider d'un usage recommandé, obligatoire sur certains chemins ou abandonné.
Les métriques importantes sont le taux de vrais positifs, la gravité des défauts détectés, le délai gagné et le nombre de problèmes introduits par les corrections. Le volume brut de commentaires est une mauvaise mesure : cinq alertes précises valent mieux que cinquante remarques ignorées.
Où placer la commande dans le pipeline humain
Le moment idéal se situe après les premiers tests locaux et avant la pull request. Le code est assez complet pour être compris, mais l'auteur peut encore restructurer sans perturber une revue déjà engagée. Une seconde exécution est pertinente après un correctif important suggéré par l'outil.
La séquence peut devenir : tests locaux, /security-review, correction et tests de régression, ouverture de la pull request, scanners CI, revue humaine, puis règles de fusion. Chaque étape apporte une propriété différente : rapidité, reproductibilité, expertise et gouvernance.
Sur un changement banal de documentation, la commande apporte peu. Sur une nouvelle route d'authentification, un import de fichier ou une requête construite dynamiquement, elle mérite sa place. Le déclenchement fondé sur le risque maintient l'attention des équipes.
La checklist d'adoption
- documenter précisément les dépôts et données autorisés dans Copilot ;
- conserver CodeQL, Dependabot, secret scanning et les tests existants ;
- ne jamais fusionner sur la seule absence de constat ;
- exiger un test reproduisant chaque vulnérabilité confirmée ;
- relire toutes les corrections générées ;
- surveiller les faux positifs et surtout les faux négatifs connus ;
- prévoir un mode dégradé lorsque la préversion est indisponible ;
- garder les règles de blocage dans la plateforme CI ;
- former les développeurs à distinguer gravité, confiance et exploitabilité ;
- réévaluer le dispositif lorsque la fonction sortira de préversion.
/security-review rapproche utilement la sécurité du moment où le code est écrit. C'est sa force : une boucle courte, contextualisée et directement actionnable. Sa faiblesse serait de transformer cette commodité en certification. Employée comme premier regard avant les scanners et les humains, la commande peut réduire le coût des erreurs. Employée comme verdict final, elle ajoute surtout un nouveau faux sentiment de sécurité.
La discussion
Commentaires
Chargement des commentaires…