GitHub ha dado un paso clave en la gobernanza interna de sus más de 14.000 repositorios: en menos de 45 días validó la propiedad de todos los repositorios activos, archivó alrededor de 8.000 que ya no se usaban e hizo obligatoria la asignación de un propietario desde el momento de la creación. La iniciativa surgió de un problema operativo recurrente: durante la remediación de alertas de escaneo de secretos resultaba arriesgado rotar credenciales sin saber a quién принадлежал cada repositorio, y el trabajo se paralizaba buscando al responsable.
El nuevo modelo utiliza las custom properties de GitHub para almacenar dos campos: ownership-type (Service Catalog, Hubber Handle o Team) y ownership-name, cuyo valor valida una GitHub App frente al catálogo de servicios, el directorio de empleados y la lista de equipos de la organización. Antes de pedir nada al personal, un proceso periódico trasladó la propiedad de los aproximadamente 1.500 repositorios respaldados por servicios; el resto se cubrió mediante una GitHub App ejecutada como Kubernetes CronJob, que abría un issue de aviso, concedía 30 días de gracia y, pasado ese plazo, archivaba el repositorio de forma reversible.
El despliegue dejó dos lecciones operativas: el aviso debe mencionar directamente a administradores y personas con acceso de escritura para evitar que los issues queden enterrados, y la sincronización con el Service Catalog necesita una marca de mínimo histórico para no archivar repositorios válidos si la fuente devuelve datos obsoletos. Con la fase inicial cerrada, el plazo de gracia se redujo a una hora, de modo que cualquier repositorio nuevo sin propietario queda marcado casi de inmediato. La propiedad queda así convertida en la base sobre la que se apoyan flujos posteriores como respuesta a incidentes, gestión de vulnerabilidades y cumplimiento normativo.