On connaît tous la scène : un développeur pressé colle un jeton d'API dans un commit, et quelques minutes plus tard, la clé se retrouve en pleine lumière dans un dépôt public. GitHub ajoute aujourd'hui un verrou de plus : depuis ce 9 septembre, tu peux bloquer la fusion d'une pull request dès qu'elle introduit un secret détecté par le secret scanning.
La règle arrive en préversion publique pour les clients des offres GitHub Secret Protection et GitHub Advanced Security. Elle vise l'accident le plus banal de la sécurité du code, celui qui a déjà exposé des milliers de clés sur des dépôts ouverts.
Ce que GitHub vérifie avant le merge
Concrètement, une pull request (une proposition de modifications qu'on demande d'intégrer au projet) passe désormais devant un filtre automatique avant que le bouton de fusion ne se déverrouille. Le secret scanning, c'est le scan qui repère dans le code les clés d'API, les jetons d'accès et autres mots de passe oubliés. La nouvelle règle exige deux choses : qu'un scan ait bien été effectué sur le dernier commit de la branche, et qu'aucune alerte ne reste ouverte pour les secrets introduits par les commits de la pull request.
Si une alerte traîne, le merge reste bloqué. Un développeur qui n'a pas les droits de contournement doit résoudre chaque alerte, une par une, pour débloquer la situation. Pas de raccourci, pas de bouton « fusionner quand même ».
Par défaut, la règle surveille les secrets reconnus par les modèles des grands fournisseurs, AWS, Google Cloud ou OpenAI par exemple. Tu peux l'élargir aux modèles personnalisés ou génériques si ton équipe en utilise.
La différence avec la push protection
GitHub avait déjà un filet : la push protection, qui arrête un secret au moment du push, avant même qu'il ne touche le dépôt. Alors pourquoi une deuxième couche ? Parce que la première n'attrape pas tout. Certaines équipes désactivent la push protection pour les modèles génériques, trop bavards en fausses alertes. Et des secrets peuvent entrer par des chemins qu'elle ne voit pas.
La nouvelle règle agit une étape plus loin, au moment précis où le code entre officiellement dans le projet. GitHub le présente comme un complément, pas un remplacement : tu peux garder la push protection éteinte pour les types de secrets génériques tout en bloquant les pull requests pour ces mêmes types. Chaque couche attrape ce que l'autre laisse passer.
Comment l'activer
Bonne nouvelle : rien de nouveau à apprendre. La règle s'installe dans la mécanique existante des rulesets, ces ensembles de règles qu'on applique automatiquement à des dépôts et des branches choisis. Dans les réglages du dépôt, de l'organisation ou de toute l'entreprise, direction l'onglet Rulesets. Tu crées ou édites un ruleset visant les branches à protéger, puis tu coches « Require secret scanning alerts are resolved ».
✉️ Un moment, avant de continuer la lecture…
La newsletter condense l'actu tech chaque dimanche : les 4-5 infos qui comptent + un outil open source à installer, en français. Inscription gratuite, désinscription en un clic.
Les équipes qui automatisent tout passent par l'API : côté REST, la règle s'appelle require_secret_scanning_alert_resolution, avec un paramètre secret_types pour choisir les types de secrets visés. Côté GraphQL, c'est REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION. De quoi la déployer sur cent dépôts d'un coup, ce qui est plutôt le but.
Les limites à connaître
Premier point : c'est une préversion publique, le comportement peut donc évoluer avant la version générale. Deuxième point : il faut l'un des deux plans payants, GitHub Secret Protection ou GitHub Advanced Security. Sur un dépôt personnel gratuit, la règle n'est pas disponible et la push protection classique reste le filet automatique au moment du push.
Troisième point, le plus important : la règle ne bloque que ce que les modèles de détection reconnaissent. Une clé exotique qu'aucun modèle ne connaît passe à travers. Le scan réduit énormément le risque d'accident, il ne remplace pas la bonne habitude de ne jamais coller un secret dans un commit.
Reste à savoir si les équipes l'activeront vraiment : une règle qui bloque la fusion peut agacer en plein sprint. Mais entre deux minutes de gêne et une clé d'API exposée pendant six mois, le choix est vite fait.
Sources
L'annonce officielle est parue sur le GitHub Changelog, avec le détail de la règle et de sa configuration. La documentation GitHub du secret scanning et de la push protection explique les deux mécanismes en détail.
Image de couverture : la bannière officielle de l'annonce, publiée par GitHub sur son blog.
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet