En el ecosistema del desarrollo de software moderno, la gestión de repositorios puede convertirse en un desafío monumental cuando se carece de un sistema claro de propiedad. GitHub, una de las plataformas más utilizadas del mundo, se enfrentó a una situación crítica: más de 14.000 repositorios en su organización interna, de los cuales 11.000 estaban activos y una gran parte no tenía un propietario definido. Este problema, lejos de ser un mero detalle administrativo, se convirtió en un obstáculo recurrente para tareas como la rotación de secretos, la respuesta a incidentes y la gestión de vulnerabilidades. La historia de cómo resolvieron este problema ofrece lecciones valiosas para cualquier empresa que maneje un volumen significativo de código.
El problema de fondo era estructural. Aunque existía un registro de servicios (Service Catalog) que asociaba repositorios a equipos responsables, esa relación era unidireccional: un servicio podía tener varios repositorios, pero no era fácil descubrir quién era el dueño de un repositorio que no estuviera vinculado a un servicio productivo. Esto dejaba fuera a repositorios de documentación, herramientas internas, experimentos personales y proyectos de hackathons. Cada vez que se necesitaba contactar al responsable, había que recurrir a métodos manuales: revisar el historial de commits, leer el README, preguntar en Slack o simplemente adivinar. Para tareas puntuales era molesto, pero para procesos de seguridad que se expandían por toda la organización resultaba un riesgo real. En Q2BSTUDIO, como empresa especializada en desarrollo de aplicaciones a medida, sabemos que la trazabilidad de la propiedad es un pilar fundamental para garantizar la calidad y la seguridad del software.
La solución pasó por convertir la propiedad del repositorio en una propiedad de primer nivel, utilizando las 'custom properties' de GitHub. Se definieron dos propiedades: ownership-type (tipo de propietario) y ownership-name (nombre del propietario). Los tipos aceptados fueron 'Service Catalog', 'Hubber Handle' (empleado individual) y 'Team' (equipo). Cada valor era validado automáticamente por una aplicación GitHub App: los handles debían pertenecer a miembros activos de la organización, los equipos debían tener al menos dos integrantes y las entradas del catálogo debían corresponder a servicios activos. Se optó por ser permisivos en el formato para reducir la fricción; por ejemplo, se aceptaba '@mi-equipo' como entrada válida, pero luego la validación rechazaba equipos inexistentes o empleados que ya no estaban en la empresa. Esta flexibilidad inicial aceleró la adopción mientras se mantenía la integridad de los datos.
El despliegue comenzó con una sincronización automática desde el Service Catalog, que cubrió unos 1.500 repositorios respaldados por servicios. Los repositorios restantes —equipos, documentación, proyectos personales— debían completar la información manualmente. Para ello, se construyó una aplicación con un CronJob en Kubernetes que abría issues recordatorios en cada repositorio sin propietario, dando un plazo de 30 días. El primer día de ejecución fue un sábado por la mañana, pensando que nadie lo notaría. Error: en una empresa global siempre hay alguien trabajando, y los issues comenzaron a aparecer con preguntas en Slack. Tras el período de gracia, los repositorios sin dueño fueron archivados. El archivo es reversible y no destructivo: el repositorio pasa a ser solo lectura y se detienen las Actions, pero nada se elimina. Esto permitió aplicar el archivado de forma masiva sin debates por casos particulares. Al final, se archivaron unos 8.000 repositorios, reduciendo la superficie activa a unos 3.000, todos con un propietario validado.
Sin embargo, no todo fue perfecto. Se produjeron dos incidentes menores que obligaron a ajustar el sistema. El primero ocurrió cuando un repositorio archivado impedía que Datadog creara issues automáticos, lo que generó una alerta inesperada. La lección fue que los issues de propiedad no estaban notificando directamente a los administradores del repositorio. La solución fue mencionar (@) a los administradores y asignar automáticamente a todos los usuarios con permisos de escritura, asegurando que las notificaciones no pasaran desapercibidas. El segundo incidente tuvo que ver con la fiabilidad de los datos: si el Service Catalog devolvía datos corruptos o desactualizados, la aplicación podía archivar repositorios legítimos. Para evitarlo, se implementó un 'low water mark': antes de archivar, el sistema contaba cuántos repositorios iba a tocar; si superaba un umbral conservador, abortaba la ejecución y disparaba una alerta en Datadog. Este enfoque de guardarraíles es algo que en Q2BSTUDIO aplicamos constantemente en nuestros proyectos de cloud AWS y Azure, donde la automatización debe ser robusta ante fuentes de datos imperfectas.
Los resultados numéricos hablan por sí solos: en 45 días se pasó de tener unos 3.000 repositorios archivados a más de 11.000, mientras que los activos se redujeron a 3.000, todos con propietario conocido. Muchos de esos repositorios archivados llevaban años sin commits: proyectos de hackathons abandonados, experimentos personales e incluso prototipos de 2008. Archivar no solo redujo la superficie de ataque, sino que también hizo que el inventario reflejara la realidad operativa. Para mantener el 100% de cobertura, se integró la propiedad como requisito obligatorio en todos los flujos de creación de repositorios, y se redujo el plazo de gracia a solo una hora para repositorios nuevos que perdieran la propiedad.
La durabilidad de la propiedad depende del tipo. Los servicios siguen su ciclo de vida: al descomisionar un servicio, sus repositorios suelen archivarse. Los equipos son estables mientras tengan al menos un miembro. Y los empleados individuales solo dejan de ser válidos cuando alguien se va de la empresa, momento en el que sus repositorios personales también deberían archivarse. Para repositorios críticos que deben sobrevivir a una persona, la propiedad debe ser un equipo o un servicio, nunca un individuo. Esta filosofía es aplicable a cualquier organización que desee fortalecer su postura de seguridad. En un contexto donde la ciberseguridad y la inteligencia artificial están transformando el desarrollo, contar con un control de propiedad sólido es indispensable. Por ejemplo, la implementación de agentes de IA para automatizar la detección de vulnerabilidades en repositorios requiere saber a quién notificar. Del mismo modo, un panel de BI/Power BI que monitorice la salud de los repositorios solo es útil si los datos de propiedad son fiables.
Para las empresas que quieran replicar este modelo, GitHub ofrece las custom properties como herramienta nativa. El proceso recomendado incluye definir una taxonomía de propietarios (servicio, equipo, individuo), crear las propiedades a nivel de organización, sincronizar desde un catálogo de servicios si existe, hacer obligatoria la propiedad en la creación, y establecer un flujo de gracia con archivado como acción final. Las lecciones aprendidas son claras: no ejecutar el primer barrido un sábado, diseñar guardarraíles para la automatización y notificar directamente a los responsables. El resultado final es un ecosistema de repositorios ordenado, seguro y con dueños claros, lo que permite a los equipos centrarse en lo que realmente importa: desarrollar software de calidad. En Q2BSTUDIO, ayudamos a empresas a implementar estas prácticas combinando desarrollo de aplicaciones a medida, cloud, IA, ciberseguridad y BI, asegurando que la propiedad del código no sea un quebradero de cabeza más.
