Los permisos de GitHub para contratistas deben caducar

Los equipos externos de remediación deben recibir el rol de GitHub más limitado que les permita terminar la tarea concreta, y ese rol debe tener fecha de caducidad. En la mayoría de los trabajos, esto significa Read durante el diagnóstico, Write durante la reparación, ninguna aprobación directa de producción y una ventana breve con Admin solo cuando haya que cambiar un ajuste específico del repositorio.

Una petición imprecisa de «acceso a GitHub» convierte con facilidad una reparación de dos días en autoridad indefinida sobre el código fuente, los secretos, los flujos de trabajo, las versiones y los ajustes del repositorio. He visto a propietarios conceder Admin porque no sabían qué rol menor bastaba y descubrir después que nadie había registrado los cambios ni recordaba retirar la cuenta. El enfoque más seguro es sencillo: divide el trabajo en fases, vincula cada permiso a un resultado, mantén ramas protegidas entre el equipo de reparación y producción, y programa la revocación antes de enviar la invitación.

Esto importa aún más con aplicaciones generadas por IA. Un equipo puede tener que rastrear una autenticación rota, secretos expuestos, inyección SQL, módulos enmarañados y un despliegue que solo funciona desde el portátil de una persona. Esos problemas justifican un acceso cercano al código. No justifican de forma automática controlar la facturación, los colaboradores, las reglas de ramas, los webhooks, los entornos ni las credenciales de producción.

Asigna permisos a tareas, no a cargos

Los roles de GitHub describen autoridad, no fiabilidad. Un ingeniero externo respetado puede cometer un error dañino con un rol demasiado amplio, mientras que un rol bien delimitado reduce el coste tanto de los errores honestos como de una cuenta comprometida.

La documentación de GitHub Repository roles for an organization ordena los roles estándar como Read, Triage, Write, Maintain y Admin. Sus descripciones resultan útiles: Read sirve para quien necesita ver o comentar un proyecto, Triage añade gestión de incidencias y solicitudes de cambio sin acceso de escritura, Write permite contribuir activamente al código, Maintain cubre la gestión del repositorio sin algunas acciones sensibles o destructivas, y Admin proporciona acceso total. El error consiste en tratar esa escala como un rango profesional. Es un mapa de capacidades.

Convierte el trabajo en entregables antes de asignar a nadie:

• Un informe de diagnóstico, un inventario de dependencias o un mapa de arquitectura suele necesitar Read.
• La clasificación de incidencias, el seguimiento de reproducciones y la coordinación de solicitudes de cambio pueden necesitar Triage.
• Los commits de reparación y las solicitudes de cambio necesitan Write, salvo que el equipo trabaje mediante un fork.
• Los cambios en reglas de ramas, colaboradores, entornos o ajustes de seguridad pueden necesitar Admin durante un intervalo corto.
• La aprobación de una versión para producción debe seguir en manos de un responsable interno aunque el equipo externo prepare la versión.

Déjalo por escrito. Un pequeño contrato de acceso sirve más que un párrafo de un acuerdo de trabajo porque un responsable puede compararlo con los ajustes de GitHub:

repository: acme/example-app
team: external-remediation
phase_1:
  role: read
  output: diagnosis-and-repair-plan
phase_2:
  role: write
  branches: repair/*
  output: reviewed-pull-requests
admin_window:
  allowed_changes:
    - branch-protection
    - deployment-environment
  approved_by: internal-repository-owner
  ends_at: 2026-08-15T18:00:00Z
revocation_owner: engineering-director

Ese archivo no impone nada por sí solo. Evita el fallo frecuente en el que el alcance cambia durante una conversación, pero el acceso no cambia con él. Si el equipo descubre que necesita una capacidad nueva, actualiza el registro, consigue la aprobación y después modifica el rol.

Si el repositorio pertenece a una organización, añade a personas concretas como colaboradores externos o usa una estructura de organización adecuada que controlen tus propios administradores. No compartas una sola cuenta de proveedor. Las identidades individuales hacen que las revisiones, los eventos de auditoría y la revocación tengan sentido. Exige la autenticación de dos factores en el nivel de organización cuando tu configuración la admita y comprueba que cada persona haya aceptado con su propia identidad.

Read basta para una auditoría

Una auditoría de código seria no necesita acceso para enviar cambios. El acceso Read a un repositorio privado permite al equipo inspeccionar y clonar el código, estudiar el historial de commits, revisar ramas y participar en conversaciones normales, suficiente para la primera pasada de la mayoría de los trabajos de remediación.

La auditoría debe generar pruebas antes de que nadie edite código: un mapa de puntos de entrada, una lista de rutas con fallos, una evaluación de exposición de secretos, una revisión de dependencias y compilación, y una secuencia de reparación propuesta. El equipo también puede necesitar acceso de lectura a repositorios relacionados que contengan paquetes compartidos o definiciones de infraestructura. Concede esos repositorios de forma explícita en lugar de dar una pertenencia amplia a la organización.

Read también tiene consecuencias. Un colaborador puede crear un clon local, y revocar el acceso a GitHub no recupera esa copia. La documentación de GitHub sobre la gestión del acceso individual a repositorios dice que la eliminación corta el acceso al repositorio y borra los forks privados en los casos cubiertos, pero los clones locales permanecen. El tratamiento contractual del código confidencial, la eliminación al salir y una lista de dispositivos aprobados quedan, por tanto, fuera de los controles de roles de GitHub. No finjas que un botón de revocación borra datos ya copiados.

La fase de auditoría también es el momento adecuado para controlar la exposición de secretos. Que alguien tenga Read en el repositorio no significa que necesite contraseñas de bases de datos, credenciales de la nube, claves de pago ni exportaciones de clientes. En primer lugar, los secretos no deben estar en el repositorio. Si la auditoría encuentra una credencial incluida en un commit, asume que pudo copiarse, rótala en el sistema que la emitió y retírala del uso activo. Reescribir el historial de Git sin rotar la credencial arregla la apariencia, no la exposición.

Read puede resultar insuficiente cuando el diagnóstico depende de registros de compilación privados, detalles de alertas de seguridad o sistemas externos. Trata cada elemento como una petición separada. La matriz de roles de GitHub indica que el acceso a algunas listas de alertas de seguridad empieza con Write, mientras que los resultados de análisis de código adjuntos a solicitudes de cambio tienen otra visibilidad. No amplíes todo el rol del repositorio sin identificar la vista exacta que falta. A menudo, un responsable interno puede exportar la alerta necesaria, reproducir el fallo o compartir la pantalla de un ajuste.

Una buena auditoría termina con un punto de control de permisos. El equipo de remediación debe indicar los archivos que espera cambiar, las ramas que creará, las comprobaciones que necesita ejecutar y cualquier ajuste del repositorio que bloquee el plan. Solo entonces Read debe pasar a Write. Si el informe no explica por qué hace falta modificar el código, más acceso no mejorará el informe.

Triage no autoriza reparaciones

Triage sirve para gestionar la cola de trabajo, pero no sustituye a Write. Permite a un coordinador externo gestionar incidencias, etiquetas, hitos, conversaciones y partes de las solicitudes de cambio sin permiso para enviar código.

Por eso Triage es un rol razonable para un jefe de proyecto que reproduce fallos, elimina duplicados, asigna trabajo, solicita pruebas que faltan y mantiene informado al propietario. También resulta útil cuando otro equipo de reparación contribuye mediante forks y un responsable externo necesita organizar las solicitudes de cambio entrantes. El rol separa la coordinación de la modificación del código fuente.

Los equipos suelen malinterpretar la palabra «triage» y asumir que incluye arreglos pequeños. No es así. Si una persona debe crear una rama en el repositorio privado, enviar un commit, actualizar un flujo de trabajo o fusionar una reparación aprobada, valora Write. Pedir una y otra vez a un ingeniero interno que copie los parches del proveedor en una rama crea una procedencia deficiente y desperdicia tiempo de revisión. Mantén a la persona en un papel real de coordinación o concede el rol que corresponda a la tarea de programación.

Triage no es automáticamente más seguro que Read para cada auditor. Añade la capacidad de cambiar cómo se presenta y prioriza el trabajo. Un coordinador malicioso o descuidado puede cerrar incidencias, modificar etiquetas o alterar la cola de revisión sin tocar el código fuente. Concédelo solo cuando gestionar incidencias forme parte del resultado, no porque parezca una opción intermedia.

No uses Triage para compensar la falta de proceso. Decide quién puede cerrar hallazgos de seguridad, quién acepta una corrección y quién comunica cambios de alcance. Un equipo externo puede marcar un elemento como listo para verificación interna sin permiso para declarar aceptado su propio trabajo. Esa diferencia conserva un registro honesto cuando el plazo aprieta.

Para un trabajo corto, Read junto con comentarios normales en las solicitudes de cambio puede bastar durante el diagnóstico. Añade Triage cuando el volumen de hallazgos exija gestionar activamente la cola. Retíralo junto con el resto del acceso del equipo al repositorio al terminar, porque una cuenta antigua de coordinador todavía expone conversaciones privadas y código.

Write debe limitarse a ramas de reparación

Write es el rol habitual para ingenieros que deben reparar código dentro de tu repositorio. Permite contribuir activamente, así que acompáñalo con ramas protegidas, revisión de solicitudes de cambio, comprobaciones automáticas y una prohibición expresa de credenciales compartidas de larga duración.

Write debe abrir una vía para proponer cambios, no una vía para redefinir su aceptación. Los ingenieros externos pueden crear ramas repair/*, enviar commits, abrir solicitudes de cambio, responder a la revisión y actualizar el arreglo propuesto. Los responsables internos deben aprobar los cambios que afecten a autenticación, autorización, migración de datos, pagos, flujos de compilación o infraestructura de producción.

La política de ramas funcional más sencilla tiene cuatro partes:

• Exige solicitudes de cambio antes de que los cambios lleguen a la rama predeterminada.
• Exige al menos una aprobación interna para rutas de gran impacto.
• Exige que pasen las comprobaciones de compilación, pruebas, lint y seguridad del repositorio.
• Bloquea los envíos forzados y el borrado de ramas de versión protegidas.

Añade propiedad del código en zonas donde un cambio en apariencia pequeño puede modificar la autoridad de producción. Un archivo compacto podría ser así:

/.github/workflows/ @acme/platform-owners
/auth/ @acme/security-owners
/db/migrations/ @acme/data-owners
/infra/ @acme/platform-owners

Un archivo CODEOWNERS identifica revisores, pero solo se convierte en una barrera cuando la protección de ramas o un conjunto de reglas exige revisión de los propietarios del código. Sin esa aplicación, el archivo solo orienta el trabajo. Esta es una de las diferencias que los equipos confunden habitualmente, y la consecuencia es una solicitud de cambio que parece controlada aunque GitHub permita fusionarla sin el propietario indicado.

Evita dar al equipo externo un token de acceso personal compartido. Cada ingeniero debe usar una cuenta individual, y la automatización debe usar una GitHub App de alcance limitado o un token propiedad de tu organización cuando de verdad haga falta automatizar. Eliminar usuarios resulta mucho más limpio cuando los commits, las aprobaciones y la actividad de API apuntan a actores distintos.

Write puede exponer algo más que la modificación del código. Los archivos de flujos de trabajo merecen especial atención porque una persona capaz de cambiar un flujo automático puede influir en lo que se ejecuta en un runner o en cómo se usan las credenciales disponibles. Mantén los cambios de flujos tras revisión interna, limita los permisos predeterminados de GITHUB_TOKEN a lo que necesite cada trabajo y nunca tomes un flujo aprobado como prueba de que editarlo es seguro.

No dejes que la comodidad de la reparación borre el historial. Prohíbe los envíos forzados en ramas de reparación compartidas, exige una autoría de commits clara y pide al equipo que explique los cambios sensibles para la seguridad en el cuerpo de la solicitud. Puede ser razonable agrupar commits al fusionar, pero la solicitud debe conservar la conversación y las comprobaciones que justificaron el resultado.

Admin es una excepción breve y controlada

Admin debe ser una excepción temporal para una tarea concreta de ajustes, no el rol inicial de un trabajo de remediación. Incluye acciones sensibles y destructivas, entre ellas la gestión del acceso y las reglas del repositorio, que una reparación normal de código no necesita.

Hay casos legítimos. Puede que no exista protección de ramas o esté mal configurada. Un entorno de despliegue puede necesitar un revisor o una restricción de ramas. Tal vez haya que activar ajustes de seguridad. Un webhook o una clave de despliegue puede formar parte del fallo. Algunos de esos cambios requieren Admin con los roles estándar de GitHub, según la función y el plan.

La respuesta equivocada es mantener Admin durante toda la reparación porque quizá haya que tocar varios ajustes. Usa una ventana de ampliación:

1. El responsable externo presenta el ajuste actual exacto, el ajuste propuesto, el motivo y la forma de deshacerlo.
2. Un propietario interno del repositorio aprueba el cambio y registra las horas de inicio y fin.
3. Un ingeniero externo concreto recibe Admin, mientras los demás miembros mantienen sus roles.
4. El responsable interno observa o revisa el cambio de ajuste y guarda pruebas.
5. El propietario devuelve al ingeniero a Write justo después de verificarlo.

Un administrador interno puede aplicar el cambio a partir de la recomendación escrita del equipo cuando el ajuste es sencillo. Suele ser más rápido que diseñar acceso Admin temporal. Admin externo tiene más sentido cuando el diagnóstico depende de una interacción compleja entre reglas, entornos, webhooks o controles de seguridad y el especialista necesita inspeccionar directamente la configuración.

A veces se propone Maintain como compromiso inocuo. Puede gestionar partes del repositorio sin todas las acciones de Admin, pero sigue siendo más amplio que contribuir código y quizá no incluya el ajuste sensible concreto que motivó la ampliación. Conceder Maintain sin revisar la matriz de capacidades combina dos fallos: autoridad excesiva sobre aspectos ajenos y ninguna garantía de que la tarea necesaria funcione. Elígelo solo cuando un conjunto documentado de acciones de mantenimiento coincida con el trabajo.

Nunca entregues el rol Owner de la organización por una reparación de repositorio. Admin de repositorio y Owner de organización operan en ámbitos distintos. Si el equipo necesita información para toda la organización, un propietario puede exportarla, realizar el cambio o crear un rol personalizado compatible en GitHub Enterprise Cloud. Una sola aplicación rota no justifica el control de todos los repositorios y miembros.

El acceso Admin también da más importancia al comportamiento de las excepciones. Algunas reglas de protección permiten que los administradores las omitan salvo que se configuren de otro modo. Si amplías temporalmente el rol de alguien, comprueba si la regla sigue aplicándose a los administradores. La etiqueta «protegida» no responde esa pregunta.

La protección de ramas debe sobrevivir al trabajo

Las ramas protegidas y los conjuntos de reglas deben limitar tanto al equipo externo como a tus propios administradores cuando el riesgo lo pida. Un proceso de reparación falla si la barrera de la rama desaparece cada vez que alguien tiene permiso suficiente y la considera incómoda.

La documentación Managing a branch protection rule de GitHub dice que las reglas de ramas protegidas pueden exigir aprobación de solicitudes de cambio y comprobaciones de estado correctas. También advierte que solo se aplica una regla de protección de rama cada vez, lo que puede dificultar el razonamiento sobre patrones superpuestos. GitHub señala los conjuntos de reglas como alternativa. Ese detalle importa durante la remediación: añadir una regla nueva con comodines quizá no se combine con la que esperabas, por lo que debes probar la política efectiva en las ramas predeterminadas y de versión reales.

Empieza por la rama predeterminada y por todas las ramas o etiquetas capaces de desplegar. Exige solicitudes de cambio, descarta aprobaciones antiguas cuando el código cambie de forma material, exige resolver conversaciones cuando tu práctica de revisión las use y nombra las comprobaciones de estado que de verdad bloquean una compilación defectuosa. Una comprobación obligatoria que nunca se ejecuta puede congelar las fusiones, mientras que una con nombre de trabajo variable puede dejar de coincidir en silencio con la barrera prevista. Comprueba el comportamiento con una solicitud de cambio desechable.

Mantén cortas las listas de excepción. El equipo de remediación normalmente no debe estar en ellas. Si una migración o reparación urgente no puede superar una comprobación existente, registra por qué la comprobación es incorrecta o por qué hace falta una excepción controlada. Arreglar una comprobación inestable forma parte de preparar el repositorio para producción; omitirla en cada solicitud solo oculta el defecto.

Las reglas del repositorio no reemplazan el criterio de revisión. Una compilación correcta puede confirmar sintaxis, pruebas y escáneres configurados. No puede decidir si un flujo nuevo de autenticación coincide con la política de recuperación de cuentas del producto ni si una migración de datos conserva el significado de negocio. Asigna revisores internos que entiendan esas consecuencias.

Revisa las reglas después de cualquier ventana con Admin. Compara la configuración final con el contrato de acceso aprobado, busca actores nuevos con excepción, confirma que los envíos forzados sigan bloqueados y verifica que la revisión de propietarios del código se aplique a las rutas previstas. Guarda capturas o una configuración exportada cuando corresponda, pero conserva un registro textual de la decisión para que futuros responsables puedan encontrarlo.

Cuando FixMyMess repara una aplicación generada por IA, el límite de permisos útil es el mismo que exigiría a cualquier equipo externo: acceso suficiente para diagnosticar y presentar cambios verificados, mientras el propietario del repositorio conserva los controles finales. El diagnóstico de código, la reparación de lógica, el refuerzo de seguridad, la refactorización y la preparación del despliegue que ofrece la plataforma no necesitan la propiedad permanente del repositorio del cliente.

El acceso al despliegue es una decisión aparte

Write en el repositorio no tiene por qué incluir autoridad para aprobar el despliegue en producción. Trata la contribución al código, la modificación de flujos, la aprobación de entornos, el acceso a la nube y la capacidad de leer secretos de producción como controles separados.

Los entornos de despliegue de GitHub pueden exigir revisores, restringir ramas o etiquetas de despliegue y retener secretos del entorno hasta que se superen las reglas de protección. La documentación Deployments and environments también permite impedir la autorrevisión, de modo que la persona que inició un despliegue no pueda aprobar el mismo trabajo protegido cuando esa opción está activada. Usa esa separación para reparaciones externas: el equipo prepara la versión y un revisor interno autoriza producción.

Un flujo seguro se parece a este:

1. El ingeniero externo abre una solicitud de cambio de reparación y se ejecutan todas las comprobaciones obligatorias.
2. Los responsables internos revisan rutas sensibles y fusionan el commit aprobado.
3. Un flujo de despliegue hace referencia al entorno de producción protegido.
4. Un revisor interno comprueba el commit, el plan de migración y la reversión, y luego aprueba el trabajo.
5. El flujo recibe secretos del entorno solo después de superar las reglas de protección.

El entorno debe aceptar despliegues solo desde la rama protegida o el patrón de etiquetas de versión previstos. No des por hecho que proteger main restringe automáticamente cada entorno. Configura las reglas de ramas o etiquetas de despliegue del entorno y pruébalas.

Ten cuidado con los cambios en flujos de trabajo. Un colaborador con Write puede proponer un cambio que altere activadores, comandos del runner, artefactos o uso de credenciales. Exige revisión del propietario del código para .github/workflows/, reduce los permisos del token del flujo, fija acciones de confianza según tu política y revisa cualquier uso de runners propios. GitHub señala que los runners propios no obtienen aislamiento de contenedor solo porque un trabajo use un entorno. Un flujo puede convertirse en la ruta que rodea una política de repositorio por lo demás cuidadosa.

Las consolas de nube, los proveedores de alojamiento, las bases de datos, los registradores de dominios y los sistemas de observabilidad tienen modelos de acceso propios. No pongas esas credenciales en una incidencia de GitHub ni entregues a un ingeniero externo una cuenta general de producción porque el rol del repositorio parezca controlado. Crea identidades separadas con límite temporal cuando sea posible, registra sus propietarios y revócalas en el mismo proceso de salida.

Si el equipo externo debe ejecutar una reparación en producción, exige un aprobador interno y una reversión escrita. La persona que escribió el cambio debe explicarlo, pero otra debe decidir si se ejecuta contra datos reales. A veces los equipos pequeños no consiguen una separación perfecta. Aun así pueden exigir un evento de aprobación explícito y conservar el motivo en lugar de dejar que el despliegue ocurra como efecto secundario de una fusión.

Las pruebas de auditoría necesitan responsable

Un registro de auditoría solo resulta útil cuando alguien sabe qué eventos revisar y qué decisión debe respaldar el registro. Reúne pruebas durante todo el trabajo, no después de un cambio sospechoso o de una revocación apresurada.

El registro de auditoría de la organización en GitHub anota quién actuó, qué acción ocurrió, cuándo sucedió y qué repositorio estuvo implicado. La documentación dice que los propietarios de la organización pueden buscar en él y que los eventos de auditoría permanecen disponibles durante un periodo limitado, así que asigna un responsable interno para exportar o conservar las pruebas que exija tu política. El equipo externo no debe ser el único custodio del registro usado para evaluar su propio acceso.

Usa una búsqueda guardada vinculada al repositorio, los actores y las fechas del trabajo. Por ejemplo:

repo:acme/example-app actor:vendor-engineer created:2026-08-01..2026-08-15

El registro de revisión debe incluir campos como la acción, el actor, el repositorio, el origen y la hora. Un evento normalizado y compacto puede verse así:

{"action":"protected_branch.update","actor":"vendor-engineer","repo":"acme/example-app","created_at":"2026-08-04T14:22:10Z"}

Los eventos exactos disponibles dependen de la acción y de la configuración de la cuenta, así que prueba la búsqueda antes de empezar. Haz un cambio inocuo y aprobado, confirma que aparezca el evento esperado y que la persona responsable de la revisión pueda acceder a él. Descubrir al final que nadie podía ver el registro de la organización no es una estrategia de auditoría.

Audita también los cambios de código mediante Git. Las solicitudes de cambio deben conectar un hallazgo con la reparación, enumerar el comportamiento afectado, identificar pruebas y conservar los comentarios de revisión. Las versiones o los despliegues deben apuntar al commit fusionado. Los cambios de ajustes del repositorio necesitan su propio registro de aprobación porque quizá no aparezcan en una diferencia de código.

Revisa los eventos de acceso en tres momentos: después de las invitaciones y asignaciones de roles, después de cualquier ampliación temporal y durante la revocación. Busca colaboradores adicionales, cambios de rol, claves de despliegue, aplicaciones nuevas, webhooks, actores con excepción, cambios de entorno, modificaciones de flujos y vías de acceso personal inesperadas. GitHub advierte que eliminar un usuario no neutraliza una clave de despliegue guardada en otro lugar, por lo que debes incluir claves y automatizaciones instaladas en la revisión de salida.

No ahogues al responsable en eventos sin procesar. El paquete final de pruebas debe responder cuatro preguntas: quién tuvo acceso, qué cambió, quién aprobó los cambios sensibles y si se eliminaron o transfirieron todas las vías de acceso. Conserva las exportaciones originales según tu política, pero redacta una lista corta de excepciones que un futuro responsable pueda entender.

La revocación empieza antes del primer commit

Fija la fecha de revocación al conceder el acceso, nombra a la persona que lo retirará y define qué significa terminar. Una fecha final escondida en un contrato no elimina a un colaborador, un token, una clave de despliegue, una cuenta de nube ni un secreto copiado.

Usa un evento de calendario o un ticket que se abra antes del final previsto. El responsable interno debe tener tiempo suficiente para inspeccionar ramas pendientes, transferir incidencias, confirmar la propiedad del despliegue y decidir si una ampliación limitada está justificada. Las ampliaciones deben ser expresas y tener fecha. «Puede que vuelvan a ayudar» no es un motivo para conservar acceso a un repositorio privado.

La lista de salida debe cubrir todas las vías creadas para el trabajo:

• Elimina colaboradores externos o la pertenencia a la organización concedida para el trabajo.
• Revoca acceso de equipos, tokens temporales, GitHub Apps, claves de despliegue y credenciales de máquinas que ya no hagan falta.
• Retira al equipo de listas de excepción, propiedad del código, grupos de revisores obligatorios y aprobaciones de entornos.
• Transfiere solicitudes de cambio, incidencias, manuales operativos y responsabilidades de versión abiertas a responsables internos concretos.
• Rota cualquier secreto que haya recibido el equipo cuando su posesión continuada cree un riesgo inaceptable.

GitHub dice que eliminar a un colaborador de un repositorio privado corta el acceso y elimina los forks privados en los casos aplicables, pero los clones locales permanecen. Obtén confirmación escrita de que el equipo trató el código y los datos retenidos según las condiciones de eliminación acordadas. Es un control legal y operativo, no una función de GitHub.

Después de eliminar el acceso, compruébalo con una vista nueva de los permisos del repositorio en vez de confiar en el estado del ticket. Busca eventos de eliminación en el registro de auditoría, inspecciona aplicaciones instaladas y claves de despliegue, confirma revisores de entornos y revisa los permisos base de la organización. Una persona retirada de una asignación directa puede seguir heredando acceso por otra vía.

Conserva el historial de reparación. No borres ramas ni conversaciones solo para que el repositorio parezca limpio antes de que los responsables internos hayan aceptado el trabajo. Fusiona o cierra solicitudes de forma deliberada, conserva las pruebas que exija tu política y después elimina ramas obsoletas mediante el proceso normal del repositorio.

Un equipo de remediación debe dejar menos ambigüedad operativa de la que encontró. Si al terminar nadie puede nombrar a los administradores actuales del repositorio, los aprobadores de producción, las credenciales activas y la próxima fecha de revocación, el código puede haber mejorado pero el problema de propiedad sigue ahí. Cierra ambos.