Principio de Mínimo Privilegio: qué acceso le das al cliente en tu repo de GitHub durante su desarrollo

Hace tiempo que quería investigar sobre este tema. Como desarrollador, entiendo que es normal encontrarse en este tipo de nuevas situaciones y no saber cómo gestionarlas de primera mano. El contexto es el siguiente: estás llevando a cabo el desarrollo de un software (llamémoslo Ajile) para un cliente (llamémoslo Uartec) y durante la contratación nos comprometimos a realizar una transferencia tecnológica (del desarrollo de Ajiile, en este caso). Uartec nos pide acceso al repositorio privado en el que se lleva a cabo este desarrollo, lo que nos hace preguntarnos: ¿qué nivel de acceso le damos?

Digamos que Ajile está subido en un repositorio de GitHub privado dentro de mi organización, Devsoft. Se acordó desde el principio que así sería, por razones de comodidad y organizativas. Para que Uartec tenga acceso al código necesita permisos de lectura, como mínimo. Pero, ¿solo de lectura? ¿O algo más?

Antes de tomar ninguna decisión, conviene tener clara la tabla de permisos que ofrece GitHub para colaboradores en un repositorio privado dentro de una organización:

• Lectura: se recomienda para colaboradores que no trabajan en el código, pero que quieren ver el proyecto o hablar sobre él
• Evaluación de prioridades: se recomienda para colaboradores que necesitan administrar de forma proactiva problemas, discusiones y solicitudes de incorporación de cambios sin acceso de escritura
• Escritura: se recomienda para los colaboradores que insertan cambios activamente en el proyecto
• Mantenimiento: se recomienda para los jefes de proyecto que necesiten administrar el repositorio sin acceder a acciones confidenciales o destructivas
• Administración: se recomienda para usuarios que necesitan acceso total al proyecto, incluidas acciones confidenciales y destructivas, como administrar la seguridad o eliminar un repositorio

Como puede uno imaginar, el rol asignado a cada colaborador debe ser estrictamente el de menor responsabilidad necesaria. Esto se define en el Principio de Mínimo Privilegio. Este fue formulado por primera vez por Jerome Howard "Jerry" Saltzer en su publicación titulada "The protection of information in computer systems", en 1975.

Su cita "Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job." recoge muy bien la idea que quiero transmitir con esta entrada.

Uartec no va a participar de forma activa en el desarrollo de Ajile. No va a escribir código, no va a hacer commits, no va a revisar PRs técnicamente. Por lo tanto, no solo no es necesario darle permisos superiores a los de lectura: es una mala idea hacerlo.

Hay tres razones principales para no dar acceso de escritura a un cliente que no participa en el desarrollo.

La primera es el accidente técnico. El cliente, con toda la buena fe del mundo, puede tocar algo que no debía y hacer un push a main porque "le parecía que así iba". Son cosas que luego pasan, eh.

La segunda es la trazabilidad. Si el historial de commits empieza a tener actividad de alguien ajeno al equipo de desarrollo, la auditoría del trabajo se complica considerablemente. ¿Quién hizo qué? ¿Ese cambio era intencionado o fue un error del cliente?

La tercera es la más delicada: la responsabilidad contractual. Si el cliente tiene acceso de escritura y en algún momento modifica código, ¿quién responde por los bugs que vengan después? Es una pregunta que nadie quiere responder en una reunión tensa, y mucho menos ante un abogado.

Dicho esto creo que queda claro que nuestro cliente, Uartec, no va a meter sus manazas en nuestro preciado código. Pero no se puede ignorar el hecho de que tiene acceso de lectura... Lo va a ver todo je, je.

Que el cliente tenga acceso de lectura no es un problema, es una oportunidad. Si el repositorio está bien organizado, esa visibilidad se convierte en transparencia: el cliente ve el trabajo, ve el avance, ve que las cosas se hacen bien. Eso genera confianza, que es exactamente lo que busca cuando pide acceso.

Mi recomendación es: mantener el repositorio bien organizado, seguir un Git flow ordenado, documentar y generar versiones y notas de releases. Y no solo por el cliente, sino por el propio flujo de trabajo.

• Mantén una diferenciación clara entre las ramas main/master y dev/development.
• Realiza un versionado adecuado y bien documentado frecuentemente: lo que el cliente quiere es saber cuándo hay una versión nueva disponible y qué ha cambiado a alto nivel.
• Sube diagramas de arquitectura/componentes.
• Mantén actualizada la documentación del repositorio.
• Actualiza el README.
• Documenta los errores y las limitaciones conocidas del software (tanto en documentación como en el apartado Issues).
• Respeta el git flow creando pull requests para incorporar nuevas funcionalidades o resoluciones de problemas a la rama principal.

El acceso de escritura solo tiene sentido si hay una razón técnica muy concreta y documentada, y en ese caso siempre debería ir acompañado de ramas protegidas y una política clara de qué puede y qué no puede tocar el colaborador externo.