Le 23 octobre 2026, GitHub a ajouté trois capacités à la supervision publique des secrets (« public monitoring »), une fonctionnalité réservée aux clients Enterprise Cloud : un triage des alertes, des vérifications automatiques de validité des jetons exposés, ainsi qu’une API REST et des webhooks. Le but affiché est de transformer un simple flux de détection en une véritable surface opérationnelle pour les équipes sécurité.
Une fonctionnalité lancée en juillet, complétée en octobre
La supervision publique des secrets existe depuis le 1er juillet 2026. Elle scrute en continu les dépôts publics de GitHub.com, y compris les commentaires d’issues et de pull requests, à la recherche de jetons appartenant à une entreprise cliente. Deux méthodes d’attribution sont combinées : l’appartenance d’un compte à l’entreprise, et la correspondance avec un domaine de messagerie vérifié par cette entreprise, même pour un compte qui n’en est pas membre. Le 22 octobre, la préversion a été étendue aux locataires Enterprise Cloud avec résidence des données. Le lendemain, GitHub a ajouté le triage, les vérifications de validité, l’API et les webhooks, le tout sans coût supplémentaire pour les entreprises disposant de GitHub Advanced Security ou de GitHub Secret Protection.
Trier les alertes sans confondre fermeture et remédiation
Depuis le tableau de bord sécurité de l’entreprise, une alerte peut désormais être classée « Dismissed » ou « Fixed », avec un commentaire facultatif, puis rouverte au besoin. Une chronologie consigne chaque changement d’état, et les alertes se filtrent par dépôt, par auteur du commit, par type de secret, par méthode d’attribution ou par état.
Fermer une alerte dans le tableau de bord de l’entreprise ne révoque pas le secret et ne le supprime pas du dépôt public : c’est une mise à jour administrative, pas une remédiation.
Pour les équipes qui reçoivent plusieurs dizaines d’alertes par semaine, cette distinction évite un faux sentiment de sécurité : le classement sert à organiser le travail de l’équipe, pas à neutraliser la fuite elle-même.
Vérification de validité : trier le bruit des urgences
Pour les fournisseurs pris en charge, GitHub interroge désormais périodiquement l’émetteur du jeton pour savoir s’il répond toujours. Chaque alerte reçoit un état parmi trois :
| État | Signification | Action recommandée |
|---|---|---|
| Active | Le jeton répond encore chez le fournisseur | Révocation immédiate |
| Inactive | Le jeton a déjà été révoqué ou a expiré | Fermeture sans action corrective |
| Unknown | Le fournisseur n’est pas couvert par la vérification | Traitement manuel, comme si le jeton était actif |
API REST et webhooks : brancher l’alerte dans l’outillage existant
L’endpoint GET /enterprises/{enterprise}/secret-scanning/public-monitoring-alerts renvoie les métadonnées de chaque alerte : type de secret, méthode d’attribution et emplacement d’exposition. Il est accessible aux administrateurs d’entreprise et aux gestionnaires de sécurité d’entreprise.
curl -s -H "Authorization: Bearer $GH_TOKEN" \
-H "Accept: application/vnd.github+json" \
https://api.github.com/enterprises/ACME-CORP/secret-scanning/public-monitoring-alertsCôté notifications, l’événement de webhook d’entreprise secret_scanning_public_monitoring_alert se déclenche quasiment en temps réel dès qu’une nouvelle fuite est attribuée à l’organisation, ce qui permet de l’acheminer vers un SIEM ou un canal d’astreinte sans interroger l’API en boucle.
Qui peut en profiter, et à quel prix
La fonctionnalité reste en préversion publique, réservée à GitHub Enterprise Cloud, résidence des données incluse. Elle est incluse sans coût additionnel avec GitHub Advanced Security ou GitHub Secret Protection, et son activation ainsi que la gestion des alertes relèvent des administrateurs d’entreprise et des gestionnaires de sécurité d’entreprise.
Ce qu’il faut retenir
La supervision publique des secrets passe d’un simple flux de détection à une surface de travail complète : triage, priorisation par validité, API et webhooks. Elle reste cependant cantonnée aux grandes entreprises sous Enterprise Cloud, en préversion, et ne dispense pas des réflexes de base déjà couverts par les précédentes extensions du secret scanning côté clés Anthropic et Salesforce ou côté Lovable et Supabase : rotation rapide des jetons et suppression de l’historique Git concerné.
Ce que je retiens surtout, c’est la logique de palier : GitHub traite d’abord la détection, puis seulement des mois plus tard l’exploitation opérationnelle de cette détection. Pour mes missions chez des clients qui n’ont ni Advanced Security ni la taille Enterprise, ce filet n’existe tout simplement pas, et je continue de recommander un gestionnaire de secrets et des hooks pre-commit plutôt que d’attendre qu’une plateforme règle le problème à ma place. — Simon Janvier
Pour aller plus loin : l’annonce officielle sur le changelog GitHub.
