GitHub ajoute des outils de traitement aux alertes de Public Monitoring. Son annonce du 23 octobre 2026 décrit un suivi plus structuré des identifiants exposés : triage, vérification de validité, API et webhooks.
Fermer une alerte ne neutralise pas une clé
Les équipes peuvent fermer ou rouvrir une alerte, commenter leur décision, consulter son historique et filtrer les résultats. Pour les fournisseurs pris en charge, un contrôle continu distingue les identifiants actifs, inactifs ou de validité inconnue.
La limite à retenir est nette : fermer l’alerte ne révoque pas l’identifiant et ne retire pas le secret du dépôt public. Le suivi administratif d’un incident et sa résolution technique restent deux opérations différentes.
Une API REST permet aux administrateurs et responsables de sécurité de l’entreprise d’interroger les alertes. L’événement webhook secret_scanning_public_monitoring_alert peut signaler une nouvelle fuite attribuée à l’organisation. Le service demeure en aperçu public, avec une licence GitHub Advanced Security ou Secret Protection pour Enterprise Cloud.
Une surveillance au-delà de ses propres dépôts
La documentation de Public Monitoring explique que la détection s’étend aux dépôts publics n’appartenant pas à l’entreprise, y compris aux commentaires d’issues et de pull requests. L’attribution repose sur l’appartenance à l’entreprise ou un domaine de messagerie vérifié.
Un point de disponibilité appelle toutefois une vérification : le changelog inclut les environnements avec résidence des données, alors que la page de documentation consultée les exclut encore. Les deux pages ne permettent pas de présenter cette condition comme parfaitement harmonisée.
En pratique, ces nouveautés aident à organiser les alertes dans un processus interne. Elles ne constituent pas une preuve que tous les secrets exposés ont été supprimés ou que toutes les clés compromises ont été désactivées.
