GitHub peut bloquer les PR contenant des secrets : ce que les développeurs doivent changer

Depuis le 9 septembre 2026, GitHub propose en préversion publique une nouvelle règle de ruleset : Require secret scanning alerts are resolved. Lorsqu’elle est activée, une pull request ne peut pas être fusionnée si le scan du commit de tête n’est pas terminé ou si les commits de la PR ont introduit une alerte de secret encore ouverte.

Ce qui change concrètement

Secret Scanning savait déjà détecter des clés, jetons et autres informations d’authentification dans les dépôts. Push protection pouvait aussi empêcher certains secrets d’être poussés. La nouvelle règle ajoute une barrière au moment de la fusion : même si un secret est arrivé dans une branche, il peut être empêché d’atteindre la branche protégée tant que l’alerte correspondante n’est pas résolue.

GitHub vérifie deux conditions avant d’autoriser la fusion : le secret scan doit avoir terminé sur le commit de tête de la PR et aucune alerte correspondante introduite par les commits de cette PR ne doit rester ouverte.

Pourquoi cette règle complète push protection

Push protection agit le plus tôt possible : il tente de bloquer un secret au moment où un développeur pousse ses commits ou crée des modifications dans l’interface GitHub. La protection de fusion agit plus tard, au niveau de la pull request.

Les deux mécanismes couvrent donc des moments différents du cycle de développement. Une équipe peut conserver push protection pour éviter l’introduction du secret et ajouter la nouvelle règle de merge pour empêcher qu’une alerte non traitée atteigne la branche principale.

Quels secrets peuvent bloquer une fusion ?

Par défaut, la règle peut bloquer les alertes issues des modèles de fournisseurs pris en charge par GitHub. Il est également possible de sélectionner des modèles personnalisés ou génériques. La documentation précise que les secrets détectés uniquement par les mécanismes de détection IA ne sont pas pris en charge par cette règle au moment de sa préversion publique.

Le choix des catégories est important : un ruleset trop permissif laisse passer des cas intéressants, tandis qu’une règle trop large peut augmenter le nombre d’alertes à traiter. Il faut donc l’adapter au type de dépôts et aux fournisseurs réellement utilisés par l’équipe.

Supprimer le secret du dernier fichier ne suffit pas toujours

Lorsqu’un vrai secret a été commité, le problème n’est pas uniquement sa présence dans la version actuelle du fichier. Il a pu être visible dans l’historique Git, dans une revue de code, dans des logs ou dans un clone effectué entre-temps.

Pour un secret réel, la réponse la plus sûre est généralement de le considérer comme compromis : le faire tourner ou le révoquer côté fournisseur, remplacer sa valeur dans l’application, puis corriger l’historique de la branche si nécessaire. La résolution de l’alerte GitHub ne remplace pas cette rotation.

Un workflow simple pour une équipe

1. activer Secret Scanning sur les dépôts concernés ;
2. activer push protection lorsque l’offre et le dépôt le permettent ;
3. ajouter un ruleset sur la branche principale avec Require secret scanning alerts are resolved ;
4. limiter les permissions de contournement aux personnes qui en ont réellement besoin ;
5. en cas d’alerte réelle, faire tourner ou révoquer le secret avant de résoudre l’alerte ;
6. conserver les secrets de CI dans les mécanismes dédiés de GitHub Actions ou du fournisseur, jamais directement dans le dépôt.

Et pour les petits projets ?

Même avec une petite équipe, la règle est intéressante lorsque le dépôt utilise des clés cloud, des tokens d’API, des credentials de déploiement ou des secrets liés à la CI. Un seul token exposé peut donner un accès bien plus large que le dépôt lui-même.

La bonne approche reste néanmoins proportionnée : commencer par inventorier les secrets, vérifier où ils sont stockés, réduire leur portée et leur durée de vie, puis ajouter des garde-fous automatisés. Le blocage de merge est une dernière barrière utile, pas une excuse pour laisser des credentials permanents circuler dans le développement local.

Checklist avant d’activer la règle

• Secret Scanning est activé sur les dépôts ciblés ;
• les branches critiques sont déjà couvertes par des rulesets cohérents ;
• les équipes savent comment traiter et résoudre une alerte ;
• les tokens importants peuvent être rapidement révoqués ou remplacés ;
• les bypass sont limités et traçables ;
• les secrets de CI/CD sont stockés hors du code source.

Sources

• GitHub Changelog — Block pull requests with exposed secrets from merging
• GitHub Docs — Blocking pull request merges that contain secrets
• GitHub Docs — Push protection

Publié le 9 septembre 2026. La protection de fusion décrite ici est en préversion publique et peut évoluer.