Cómo presentar la gestión de cambios en GitHub como evidencia para ISO/IEC 27001 y SOC 2

Cuando un equipo de desarrollo se somete a una auditoría de ISO/IEC 27001 (conocida en Japón como ISMS) o de SOC 2, es casi seguro que le preguntarán por la gestión de cambios. Todo el código está en GitHub y las revisiones se hacen. Aun así, es un terreno donde muchos equipos se atascan al decidir qué mostrar y cómo.

En este artículo primero ordenamos lo que el auditor quiere comprobar en la gestión de cambios y, después, explicamos paso a paso la configuración que conviene tener en GitHub y cómo conservar la evidencia.

Lo que el auditor quiere comprobar en la gestión de cambios

Las referencias de cada marco son las siguientes.

Ninguno de los dos dice «configure GitHub de tal manera». Lo que se evalúa es si usted puede demostrar con registros que los cambios se hicieron siguiendo el procedimiento definido.

En la práctica, la verificación suele seguir este flujo:

1. Se pide la lista de cambios que llegaron a producción durante el periodo de observación
2. De esa lista se extraen algunos cambios como muestra
3. Para cada cambio extraído, se comprueba si lo aprobó una persona distinta de quien lo hizo antes de llegar a producción
4. Si hubo cambios de emergencia, se comprueba que exista la aprobación posterior y el registro correspondiente

Es decir, lo que se necesita es la lista de cambios de todo el periodo y el rastro de aprobación de cada cambio. Si falta cualquiera de los dos, la explicación se complica.

Configuración que conviene tener en GitHub

Antes de la evidencia, conviene imponer el propio procedimiento mediante la configuración de GitHub. Si además de escribir las reglas en un documento las hace imposibles de saltarse por diseño, la explicación en la auditoría será más breve.

En la rama que llega a producción (main, por ejemplo), configure lo siguiente con protección de ramas o con conjuntos de reglas (rulesets):

• Exigir un pull request antes de fusionar: cierra la vía de cambiar el código de producción con un push directo
• Exigir al menos una aprobación: no se puede fusionar sin la aprobación de alguien distinto del autor
• Descartar las aprobaciones cuando haya un push nuevo: impide añadir cambios a escondidas después de la aprobación
• No hacer excepciones con los administradores: si solo los administradores pueden saltarse la protección, ya no se puede afirmar que todos los cambios pasaron por aprobación
• Prohibir la reescritura forzada del historial (force push) y el borrado de la rama

Además, deje escrito en el procedimiento de gestión de cambios qué rama es la de producción y, en caso de emergencia, quién aprueba, cómo, y qué se deja registrado a posteriori. Que la configuración y el procedimiento coincidan también es algo que se revisa en la auditoría.

Por qué no bastan las capturas de pantalla

Una forma habitual de presentar evidencia es tomar capturas de pantalla de los pull requests o de la configuración de protección de ramas y pegarlas en un documento. Este método tiene debilidades estructurales.

• Solo muestra un instante. Una captura de la configuración solo demuestra que la configuración era esa en el momento de tomarla. Si a mitad del periodo de observación se desactivó la protección y luego se volvió a activar, ese hecho no aparece
• Es difícil comprobar la fecha y el origen. La fecha que aparece en una imagen forma parte de la propia imagen, y un tercero no tiene manera de comprobar cuándo ni de dónde se obtuvo
• Reunirla cuesta trabajo cada vez. Buscar y capturar la pantalla de cada cambio extraído es una tarea que se repite en cada auditoría

También del lado de los auditores crece la tendencia a pedir, en lugar de este tipo de evidencia manual, registros con fecha automática y que se puedan rastrear.

Cómo conservar un registro de todo el periodo

Hay dos puntos clave.

1. Registrar el cambio en el momento en que ocurre. En lugar de reunir la evidencia justo antes de la auditoría, registre cuándo, quién y qué se hizo en el momento en que se produce un push o la fusión de un pull request. Si se recopila después, no se recupera lo que desapareció o cambió entretanto.

2. Conservarlo en una forma que la organización evaluada no pueda reescribir después. El historial de eventos y el registro de auditoría de GitHub son útiles, pero los registros están dentro de un sistema que gestiona la propia organización evaluada. Además, el periodo de retención tiene un límite y, según el plan, puede no cubrir un periodo de observación de 6 a 12 meses. Conviene comprobar una vez el periodo de retención de su plan.

Para demostrar que los registros no se han reescrito después, se utiliza el método de encadenar la huella (valor hash) de cada registro con la del registro anterior. Si se reescribe un solo registro intermedio, todos los enlaces posteriores dejan de coincidir, de modo que cualquier manipulación se puede detectar.

Lo que SPHIOR puede y no puede hacer

La integración de SPHIOR con GitHub realiza automáticamente los dos puntos anteriores.

• Registra eventos como los push y la creación y fusión de pull requests en el momento en que se producen
• Cada registro incluye el tipo de evento, la persona que lo ejecutó, la hora en que ocurrió y la huella de todo el contenido recibido de GitHub. El contenido en sí no se guarda
• Los registros se sellan encadenando sus huellas, de modo que cualquier manipulación se puede detectar. También puede exportar un paquete de verificación y comprobarlo usted mismo

Por otro lado, SPHIOR no cubre lo siguiente.

• La acción de aprobación de la revisión en sí no se registra por ahora. Para la aprobación, imponga con la protección de ramas descrita arriba que no se pueda fusionar sin aprobación, y explíquelo con esa configuración y con su procedimiento
• No dictamina el resultado de la auditoría. Lo que proporciona SPHIOR es evidencia complementaria para mostrar al auditor

En el plan gratuito los registros se conservan durante 90 días. Cuando necesite los registros de todo el periodo de observación, puede pasar a un plan con un periodo de retención más largo (precios).

Resumen

• En la gestión de cambios se pide la lista de cambios del periodo y el rastro de aprobación de cada cambio
• En GitHub, imponga la aprobación con la protección de ramas, sin excepciones para los administradores
• Una captura de pantalla solo muestra un instante. Lo fiable es registrar cada evento cuando ocurre, en una forma que no se pueda reescribir

Para no tener que capturar pantallas a toda prisa justo antes de la auditoría, lo más práctico es empezar a registrar mucho antes de ella.