¿Cómo demuestro la gestión de cambios desde GitHub para SOC 2 o ISO 27001?
el equipo de heygrc
En gran medida, sí, si la configuración es correcta. Un flujo de trabajo con pull requests ya registra qué cambió (el diff), quién lo revisó y aprobó, qué se ejecutó antes del merge (las comprobaciones) y cuándo se fusionó (el commit de merge). SOC 2 CC8.1 e ISO 27001 A.8.32 exigen que los cambios estén autorizados, probados, aprobados y sean trazables, y un repositorio bien gestionado aporta la mayor parte de esa evidencia sin herramientas adicionales. Lo que no proporciona de forma gratuita es la historia de cumplimiento (prueba de que las aprobaciones no podían omitirse) y el mapeo de cada cambio con el control que afecta. Eso lo añades tú.
Deja que la protección de rama asuma la parte de autorización
La gestión de cambios responde a dos preguntas: ¿estuvo cada cambio autorizado? y ¿puedes demostrarlo? El pull request muestra la instancia; la protección de rama muestra la regla. Exige pull requests con al menos una aprobación (dos donde la segregación de funciones sea relevante), exige las comprobaciones en las que confías y exige revisión de los code owners en las rutas que importan. Un auditor que muestree CC8.1 o A.8.32 preguntará cómo sabes que un cambio no revisado no puede llegar a main: los ajustes de protección muestran la regla tal como está hoy, cada aprobación es una instancia de su cumplimiento, y si la regla cambió dentro del período de auditoría, el registro de auditoría del repositorio (cambios en el conjunto de reglas y en la protección) es donde demuestras cuándo.
Haz que cada pull request funcione como un registro de cambio
El cuerpo del PR explica el porqué, el diff muestra el qué, las ejecuciones de comprobaciones demuestran que se probó, la aprobación indica que una segunda persona lo aceptó, y el commit de merge muestra cuándo se fusionó el cambio. Cuándo se implementó realmente es un registro de despliegue (una versión, un entorno, una ejecución de despliegue), que la gestión de cambios trata como un paso propio, no algo que el merge demuestre. Mantén los pull requests lo suficientemente pequeños para que una revisión sea una revisión real, vincula el ticket o el issue con la justificación comercial y no hagas push directamente a la rama protegida, incluso si puedes, ya que es la forma de eludir la revisión que exiges a los demás. Un historial ordenado no es vanidad: es la población que un auditor muestreará.
Sabe qué no demuestra GitHub
Tres vacíos. Un force-push puede reescribir el historial en referencias no protegidas y los administradores pueden omitir algunas protecciones, por lo que la historia de cumplimiento tiene límites; reconócelos con honestidad en lugar de exagerar. La retención también tiene límites: si eliminas el repositorio, los registros de pull request desaparecen con él, y los propios registros de GitHub (el registro de auditoría de la organización, los registros de Actions) caducan en una ventana limitada y dependiente del plan, así que exporta lo que necesite tu período de auditoría antes de que lo hagan. Y nada en el registro del pull request mapea un cambio con el marco normativo: CC8.1 no etiqueta un diff y A.8.32 no comenta en un pull request. Ese mapeo es lo que añade una revisión de cumplimiento por PR (heygrc publica hallazgos que nombran la cláusula), construyendo la trazabilidad control-cambio en el mismo lugar donde ya reside el cambio.
# Revisores predeterminados para todo el repositorio* @acme/devs+ /security/ @acme/securityCon protección de rama que exige revisión de los code owners, los cambios en /security/ se dirigen al equipo de seguridad para su aprobación. Protege el archivo CODEOWNERS de la misma manera, o la regla podría debilitarse en un pull request ordinario. Autorización para las rutas de riesgo, escrita en un archivo que un auditor puede leer.
Relacionado