GitHub anunció el 7 de octubre un modelo de IA creado específicamente para detectar secretos filtrados. Su objetivo es ayudar a encontrar no solo tokens con un formato reconocible, sino también contraseñas y otros posibles datos de acceso cuya estructura no sea típica. El modelo analiza el código cercano para estimar si una línea parece contener credenciales reales.
Esto importa a cualquiera que cree webs, automatizaciones o herramientas de IA. Una clave secreta que entra en el historial de Git deja de ser solo un error local: puede permanecer en versiones antiguas, aparecer en registros, copiarse en otros clones o utilizarse hasta que se revoque.
¿Qué cambia?
GitHub afirma que el nuevo modelo se utilizará en alertas de detección de secretos, push protection y revisiones de seguridad de Copilot. Lee el código circundante para distinguir mejor una posible credencial de una cadena de texto casual, pero no genera código ni texto.
Las alertas de detección de secretos con IA para clientes de GitHub Secret Protection y GitHub Advanced Security se trasladan automáticamente al nuevo modelo sin coste adicional. La comprobación de IA durante el push y la función `/security-review` de Copilot tienen condiciones distintas de disponibilidad y créditos de IA.
Algunas funciones todavía no están disponibles para todos
GitHub indica que la detección de IA en push protection está en vista previa privada. Está dirigida a usuarios de GitHub Enterprise Cloud o GitHub Teams con GHSP o GHAS, y el administrador debe activarla según las reglas de la organización.
La revisión de seguridad de Copilot con el nuevo clasificador también se prepara como vista previa privada. Además, push protection y la revisión de seguridad pueden utilizar créditos de IA. Antes de activarlas conviene revisar el plan, los permisos y el control de costes de la organización.
Por tanto, el anuncio no significa que cada repositorio gratuito reciba automáticamente todas las funciones. Hay que distinguir las alertas de secret scanning que ya están disponibles de las comprobaciones experimentales o asociadas a planes concretos.
¿Sustituye la IA a las prácticas básicas?
No. Incluso un buen clasificador puede equivocarse: pasar por alto una clave inusual, marcar un valor de prueba o no analizar un archivo fuera de su alcance. Las reglas básicas no cambian.
Las claves API y las contraseñas no deben guardarse en archivos de código, ejemplos ni incidencias públicas. Utiliza variables de entorno y un almacén de secretos. Activa push protection antes del primer lanzamiento del equipo, no después de que la clave ya haya entrado en el historial. Si una clave se filtra, borrarla del archivo no basta: hay que revocarla o sustituirla inmediatamente.
También conviene revisar registros de CI/CD, artefactos de build, capturas y documentación. Un secreto puede aparecer en un mensaje de error o en un ejemplo JSON, no solo en un archivo `.env`.
¿Qué puede hacer un proyecto pequeño?
Primero, inventaría los secretos utilizados: claves API, accesos de base de datos, claves de deploy y webhooks. Después define quién puede verlos, cuánto tiempo son válidos y cómo se sustituirían rápidamente. Por último, añade una comprobación al flujo de pull request o push y documenta qué hacer cuando aparece una alerta.
La detección con IA puede reducir el riesgo de pasar por alto una credencial poco habitual, pero no es permiso para guardar secretos en el código. El proceso más seguro sigue empezando por impedir que la clave llegue al repositorio.
Fuentes
- GitHub Changelog – Purpose-built model for leaked secret detection
- GitHub Docs – Enabling push protection for your repository
*Nota editorial: la disponibilidad de las funciones depende del plan, la organización y la fase de vista previa.*
Fuentes
- GitHub Changelog – Purpose-built model for leaked secret detectionDescripción oficial del modelo, disponibilidad y créditos de IA.
- GitHub Docs – Enabling push protection for your repositoryPrincipios oficiales para activar push protection.