GitHub a ajouté une règle capable de bloquer la fusion d’une pull request lorsqu’elle introduit un secret détecté dans le code. Disponible en aperçu public depuis le 9 septembre 2026, cette protection s’intègre aux rulesets appliqués aux dépôts et aux organisations.
Une nouvelle règle dans les rulesets
Les administrateurs peuvent activer l’obligation de résoudre les alertes de secret sur les pull requests. Un développeur qui ne possède pas d’autorisation de contournement doit alors traiter chaque alerte avant de pouvoir fusionner ses changements dans la branche protégée.
Cette barrière intervient à un moment important du processus. Elle évite qu’une clé d’API, un jeton ou un identifiant détecté pendant la revue soit intégré par erreur au code principal.
Deux vérifications avant la fusion
La règle vérifie d’abord qu’une analyse des secrets a bien été terminée sur le commit de tête. Elle contrôle ensuite qu’aucune alerte ouverte ne concerne les secrets introduits par les commits de la pull request.
Si l’analyse n’est pas terminée ou si une alerte reste active, la fusion est bloquée. Cette logique donne aux équipes un signal clair dans le même flux de travail que les tests automatisés et les revues de code.
Des motifs standards ou personnalisés
Par défaut, GitHub s’appuie sur les motifs fournis par les éditeurs de services pour reconnaître leurs clés et jetons. Les organisations peuvent aussi inclure des catégories supplémentaires, comme des motifs génériques ou personnalisés correspondant à leurs propres systèmes.
La fonction est proposée aux clients utilisant GitHub Secret Protection ou GitHub Advanced Security. Son activation et sa portée peuvent donc dépendre du type d’abonnement, des règles de l’organisation et des dépôts sélectionnés.
Une protection utile mais incomplète
Bloquer la fusion réduit le risque de diffuser un secret, mais ne suffit pas toujours. Une clé ajoutée dans un commit a déjà pu être copiée, enregistrée dans un journal ou exposée à un autre service. Lorsqu’un véritable secret est détecté, la mesure la plus sûre reste généralement de le révoquer et de le remplacer.
Les équipes doivent aussi limiter les permissions, stocker les secrets dans des gestionnaires adaptés et surveiller leur usage. La nouvelle règle renforce la prévention au moment de la revue, mais elle doit s’inscrire dans une stratégie plus large de sécurité du développement.
Source officielle et crédit image : GitHub — annonce officielle sur le blocage des secrets.