seguridad
GitHub convierte la higiene de repositorios en un proceso auditable y reversible
El proyecto Evergreen combina GitHub Apps, Actions, issues y archivos versionados para revisar accesos externos y archivar repositorios obsoletos sin perder trazabilidad.
La higiene de una organización de código rara vez falla por falta de herramientas. Falla porque revisar colaboradores externos, detectar repositorios abandonados y retirar permisos exige atención periódica, y esa atención compite con el trabajo de producto. GitHub describe Evergreen, una aplicación interna que convierte esas tareas rutinarias en un flujo programado, visible y reversible.
El sistema cubre dos procesos. Cada trimestre revisa los colaboradores externos de cada repositorio y conserva únicamente los accesos confirmados. También detecta repositorios sin actividad humana durante un periodo definido, avisa a sus responsables y los archiva si siguen sin respuesta. Archivar no equivale a borrar: el contenido permanece recuperable y cada cambio queda documentado.
La arquitectura resulta interesante porque evita construir una plataforma paralela. Un pequeño servidor Go recibe eventos de webhooks; GitHub Actions funciona como reloj mediante cuatro flujos programados; los repositorios reciben issues con listas de comprobación; las propiedades personalizadas identifican excepciones y responsables; y un archivo JSON por repositorio conserva el estado. El historial de Git se convierte así en parte del registro de auditoría: quién tenía acceso, cuándo comenzó la revisión, quién decidió y qué acción se ejecutó.
El diseño aplica dos reglas de seguridad importantes. La primera es fallar de forma segura: si nadie responde a una revisión, el acceso externo se revoca en lugar de mantenerse indefinidamente. La segunda es fallar cerrado durante la ejecución. Si una llamada a la API falla mientras se retiran varios permisos, la revisión continúa pendiente y el siguiente ciclo reintenta los elementos restantes. El sistema solo marca la operación como completada cuando todas las revocaciones han terminado correctamente.
La experiencia de usuario también forma parte del control. La petición aparece como un issue en el repositorio donde trabajan sus responsables, incluye una fecha límite explícita y ofrece recordatorios antes de actuar. Solo usuarios autorizados pueden cerrar la revisión; una acción inválida vuelve a abrir el issue. Cada resultado se escribe en el propio issue, de modo que un error no obliga a reconstruir la historia desde logs dispersos.
GitHub señala además dos límites operativos que condicionan el diseño. Evergreen se prueba primero en modo DRY_RUN, emite logs estructurados y respeta los límites secundarios de la API para crear contenido: 80 solicitudes por minuto y 500 por hora. Para no depender de reintentos agresivos, procesa repositorios por lotes y espacia las llamadas.
La lección técnica no es que toda organización necesite copiar Evergreen literalmente. Es que la automatización de seguridad gana fiabilidad cuando usa estados explícitos, plazos, permisos verificables, reversibilidad y una interfaz que los equipos ya consultan. La mantenibilidad aparece al tratar la política operativa como código versionado, con observabilidad y una ruta clara de recuperación.