El 23 de octubre de 2026, GitHub añadió tres capacidades a la supervisión pública de secretos (public monitoring), una función reservada a clientes de Enterprise Cloud: triaje de alertas, comprobaciones automáticas de validez de los tokens expuestos, y una API REST con webhooks. El objetivo declarado es convertir un simple flujo de detección en una superficie operativa completa para los equipos de seguridad.
Una función lanzada en julio, ampliada en octubre
La supervisión pública de secretos existe desde el 1 de julio de 2026. Analiza de forma continua los repositorios públicos de GitHub.com, incluidos los comentarios de issues y pull requests, en busca de tokens pertenecientes a una empresa cliente. Se combinan dos métodos de atribución: la pertenencia de una cuenta a la empresa, y la coincidencia con un dominio de correo verificado por esa empresa, incluso para una cuenta que no es miembro. El 22 de octubre, la vista previa se amplió a los inquilinos de Enterprise Cloud con residencia de datos. Al día siguiente, GitHub añadió el triaje, las comprobaciones de validez, la API y los webhooks, todo sin coste adicional para las empresas con GitHub Advanced Security o GitHub Secret Protection.
Triaje de alertas sin confundir cierre con remediación
Desde el panel de seguridad de la empresa, una alerta puede marcarse ahora como «Dismissed» o «Fixed», con un comentario opcional, y reabrirse más tarde si hace falta. Un historial registra cada cambio de estado, y las alertas pueden filtrarse por repositorio, autor del commit, tipo de secreto, método de atribución o estado.
Cerrar una alerta en el panel de la empresa no revoca el secreto ni lo elimina del repositorio público: es una actualización administrativa, no una remediación.
Para los equipos que reciben decenas de alertas por semana, esta distinción evita una falsa sensación de seguridad: el triaje organiza el trabajo del equipo, no neutraliza la fuga en sí.
Comprobaciones de validez: separar el ruido de la urgencia
Para los proveedores compatibles, GitHub ahora consulta periódicamente al emisor del token para saber si sigue respondiendo. Cada alerta recibe uno de tres estados:
| Estado | Significado | Acción recomendada |
|---|---|---|
| Active | El token todavía responde en el proveedor | Revocación inmediata |
| Inactive | El token ya fue revocado o ha caducado | Cierre sin acción adicional |
| Unknown | El proveedor no está cubierto por la comprobación | Tratamiento manual, como si estuviera activo |
API REST y webhooks: conectar la alerta con las herramientas existentes
El endpoint GET /enterprises/{enterprise}/secret-scanning/public-monitoring-alerts devuelve los metadatos de cada alerta: tipo de secreto, método de atribución y ubicación de la exposición. Está disponible para administradores de empresa y gestores de seguridad de empresa.
curl -s -H "Authorization: Bearer $GH_TOKEN" \
-H "Accept: application/vnd.github+json" \
https://api.github.com/enterprises/ACME-CORP/secret-scanning/public-monitoring-alertsEn el lado de las notificaciones, el evento de webhook de empresa secret_scanning_public_monitoring_alert se dispara casi en tiempo real en cuanto se atribuye una nueva fuga a la organización, lo que permite enviarla a un SIEM o a un canal de guardia sin interrogar la API en bucle.
Quién puede usarla y a qué coste
La función sigue en vista previa pública, limitada a GitHub Enterprise Cloud, residencia de datos incluida. Se incluye sin coste adicional con GitHub Advanced Security o GitHub Secret Protection, y su activación, así como la gestión de las alertas, corresponde a los administradores de empresa y a los gestores de seguridad de empresa.
Lo que hay que recordar
La supervisión pública de secretos pasa de un simple flujo de detección a una superficie de trabajo completa: triaje, priorización por validez, API y webhooks. Sigue, no obstante, limitada a grandes organizaciones bajo Enterprise Cloud, en vista previa, y no sustituye los reflejos básicos ya cubiertos por ampliaciones anteriores del secret scanning, ya sea para las claves de Anthropic y Salesforce o para las claves de Lovable y Supabase: rotar los tokens con rapidez y purgar el historial de Git expuesto.
Lo que más me llama la atención es la lógica por etapas: GitHub trata primero la detección y solo meses después la capa operativa que la hace accionable. En mis encargos para clientes que no tienen ni Advanced Security ni el tamaño de una Enterprise, esta red de seguridad simplemente no existe, y sigo recomendando un gestor de secretos y hooks de pre-commit en lugar de esperar a que una plataforma resuelva el problema por mí. — Simon Janvier
Para saber más: el anuncio oficial en el changelog de GitHub.
