GitHub escaneará repos inactivos: por qué también importa para código escrito por agentes

GitHub anunció el 9 de junio de 2026 una mejora menos llamativa que un nuevo modelo, pero muy relevante para equipos que ya generan código con agentes: code scanning periódico para repositorios inactivos. Aplica a repos sin pushes ni pull requests durante seis meses o más, siempre que usen code scanning default setup.

La señal útil es esta: el riesgo no vive solo en el repo activo. También vive en demos, prototipos, integraciones internas, lambdas viejas, scripts de migración y experimentos que un agente escribió rápido y nadie volvió a tocar.

Por qué esto toca a los builders de agentes

Los agentes bajan el costo de crear repos. Eso es bueno. También baja el costo de dejar repos a medio camino. Un equipo puede terminar con diez prototipos de MCP, scripts de deploy, conectores de datos o herramientas internas que funcionaron una semana y luego quedaron congelados.

Ese código puede seguir teniendo secretos mal rotados, dependencias con CVEs, rutas inseguras o patrones que CodeQL aprende a detectar meses después. Si nadie toca el repo, un escaneo basado solo en pushes no vuelve a correr.

El nuevo modo periódico corrige parte de esa ceguera: permite mantener cobertura en código que ya no cambia, pero que todavía puede estar desplegado, importado o usado por algún workflow.

La demanda actual se infiere por:

• changelog oficial de GitHub del 9 de junio;
• documentación de default setup y CodeQL;
• discusiones recientes sobre validación de código generado por agentes;
• búsquedas como periodic code scanning inactive repositories, CodeQL inactive repos y agent generated code security.

El detalle que decide si te sirve

La condición clave es default setup. Si tus repos usan un workflow CodeQL avanzado, si el setup está roto o si nunca activaste code scanning, esta novedad no arregla mágicamente la cobertura.

Para un equipo pequeño, yo lo convertiría en una tarea de higiene:

1. listar repos creados por agentes, demos o automatizaciones;
2. marcar cuáles siguen desplegados o conectados a credenciales;
3. activar default setup donde sea suficiente;
4. reservar advanced setup solo para repos que realmente necesitan configuración fina;
5. revisar alertas con dueño claro, no como buzón infinito.

No todo repo inactivo merece el mismo trato

Hay repos viejos que deberían archivarse, no escanearse para siempre. El punto de esta función no es acumular dashboards. Es distinguir tres grupos:

• repos muertos que deben archivarse o eliminarse;
• repos inactivos que siguen en producción;
• prototipos que podrían volver a usarse y necesitan una línea base.

Ese triage importa más cuando hay agentes en el flujo, porque un agente puede reactivar un repo viejo sin entender su historia de seguridad. Si el repo ya tiene alertas conocidas, el builder ve el problema antes de pedirle al agente que “solo agregue una feature rápida”.

Cómo lo usaría esta semana

El primer paso no es técnico. Es inventario. Busca repos sin actividad reciente que tengan:

• claves de API o integraciones cloud;
• dependencias backend;
• endpoints públicos;
• GitHub Actions que todavía corren;
• documentación que otros equipos podrían copiar.

Después activa default setup en los repos elegibles y deja que el primer escaneo produzca una lista real. Si salen demasiadas alertas, prioriza lo que esté conectado a producción o a credenciales vivas.

Esto conecta bien con el curso gratis, porque una práctica madura con agentes no termina cuando el PR mergea. También exige decidir qué queda vivo, qué se archiva y qué se revisa periódicamente.

La lectura final: GitHub está cerrando una grieta de seguridad que los agentes tienden a agrandar: el código que se creó rápido, quedó quieto y nadie volvió a mirar.