GitHub bloque les secrets à la fusion, mais seulement avec une offre payante
GitHub a lancé le 9 septembre 2026, en préversion publique, une règle qui empêche de fusionner une pull request lorsque son analyse de secrets n’est pas terminée ou qu’une alerte concernée reste ouverte. L’annonce officielle de GitHub réserve cette fonction aux clients disposant de GitHub Secret Protection ou de GitHub Advanced Security.
La règle, nommée Require secret scanning alerts are resolved, s’ajoute à un ruleset visant les branches à protéger. Elle contrôle le commit de tête de la pull request et les secrets introduits par ses commits : tant que ces conditions ne sont pas remplies, la fusion reste bloquée, sauf pour les acteurs autorisés à contourner le ruleset.
Un verrou à la fusion, distinct de la protection au push
La nouvelle règle intervient après l’envoi des commits, au moment où la pull request tente de rejoindre une branche protégée. La protection au push agit plus tôt : elle cherche à arrêter un secret avant son inscription dans le dépôt. Les deux mécanismes ne sont donc ni interchangeables ni nécessairement configurés avec le même périmètre.
- Protection au push : le contrôle accompagne l’envoi des commits et peut empêcher le secret d’atteindre le dépôt.
- Blocage à la fusion : les changements se trouvent déjà dans une pull request, mais ne peuvent pas intégrer la branche ciblée tant que le scan ou une alerte sélectionnée bloque l’opération.
Cette séparation autorise une politique plus fine. Une organisation peut laisser la protection au push désactivée pour certains motifs génériques jugés trop bruyants, tout en exigeant leur traitement avant une fusion. La règle constitue ainsi une barrière supplémentaire plutôt qu’un remplacement du contrôle effectué au push.
L’analyse technique publiée par Compendia Labs le 10 septembre relève aussi que les développeurs sans droit de contournement doivent résoudre l’alerte : une simple confirmation ne suffit pas à lever le blocage. Elle qualifie par ailleurs GitHub Secret Protection et GitHub Advanced Security d’offres payantes, contrairement à certaines fonctions de protection au push accessibles aux utilisateurs de dépôts publics.
Ce que GitHub vérifie avant d’autoriser la fusion
Le premier contrôle concerne l’analyse du commit de tête, soit la version la plus récente de la pull request. Si cette analyse n’est pas achevée, la fusion demeure indisponible. L’ajout d’un commit remplace le commit de tête et impose donc que cette nouvelle version soit analysée avant la décision de fusion.
Le second contrôle porte sur les alertes encore ouvertes pour les secrets introduits par les commits de la pull request. Il ne s’agit pas de bloquer la fusion à cause de n’importe quelle alerte historique du dépôt : le mécanisme vise les changements proposés et les catégories de secrets retenues dans le ruleset. Les alertes correspondantes doivent être résolues pour que le verrou soit levé.
Par défaut, la règle couvre les provider patterns, c’est-à-dire les formats de secrets associés à des fournisseurs connus. Les motifs génériques et les motifs personnalisés sont disponibles, mais doivent être ajoutés explicitement. Une activation limitée aux paramètres par défaut ne bloquera donc pas un secret qui relève uniquement d’une catégorie générique ou personnalisée non sélectionnée.
Le ciblage des branches compte tout autant. Le ruleset ne s’applique qu’aux branches qui correspondent à ses critères d’inclusion et d’exclusion. Protéger la branche principale ne signifie pas que toutes les autres branches bénéficient automatiquement du même verrou.
Configuration et droits de contournement
La configuration passe par les paramètres du dépôt, de l’organisation ou de l’entreprise, dans la rubrique consacrée aux rulesets. Le parcours essentiel consiste à créer ou modifier un ruleset de branches, définir les dépôts et branches visés, sélectionner Require secret scanning alerts are resolved, choisir les catégories de secrets puis activer l’ensemble.
- Ouvrir les paramètres et accéder à la rubrique Rulesets.
- Créer ou modifier un ruleset ciblant des branches.
- Définir précisément les dépôts et les branches protégés.
- Activer la règle, sélectionner les types de secrets et placer le ruleset à l’état actif.
La configuration peut également être automatisée. Dans l’API REST, le type de règle est require_secret_scanning_alert_resolution et utilise le paramètre secret_types. L’équivalent GraphQL porte le nom REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION.
Le blocage n’est toutefois pas absolu. La documentation GitHub sur les permissions de contournement indique qu’elles peuvent être attribuées aux administrateurs de dépôt, aux propriétaires d’organisation ou d’entreprise, aux rôles Write ou Maintain, à certains rôles personnalisés, aux équipes, aux GitHub Apps et à Dependabot. L’autorisation peut être permanente ou limitée aux pull requests.
La liste de contournement détermine donc qui reste effectivement soumis au verrou. Sans cette permission, un contributeur doit attendre la fin du scan et résoudre les alertes couvertes. Avec elle, un acteur autorisé peut fusionner malgré les protections du ruleset, ce qui impose de distinguer l’existence de la règle de son application à tous les comptes et applications.
Une préversion liée aux offres de sécurité
L’accès à cette règle précise nécessite GitHub Secret Protection ou GitHub Advanced Security. Le fait que les rulesets ou certaines fonctions de détection soient disponibles dans d’autres formules ne suffit pas : le dépôt doit être couvert par l’une de ces offres de sécurité pour utiliser ce blocage à la fusion.
La portée réelle dépend alors de trois paramètres : l’offre active, les catégories de secrets sélectionnées et les autorisations de contournement. Une règle correctement activée peut rester incomplète si elle ignore des motifs génériques ou personnalisés pertinents ; elle peut aussi perdre une partie de son effet si la liste des acteurs exemptés est trop large.
GitHub présente encore la fonction comme une préversion publique, et non comme une disponibilité générale. Le mécanisme confirmé bloque les pull requests sur les branches visées jusqu’à la fin de l’analyse et à la résolution des alertes sélectionnées, sous réserve des droits de contournement. GitHub n’a pas indiqué, dans son annonce, de calendrier de passage à une version stable.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.