Gestión de cambios, en el pipeline.
CC8.1 es el criterio de SOC 2 sobre la gestión de cambios: los cambios en la infraestructura, los datos y el software deben estar autorizados, diseñados, desarrollados, probados y aprobados antes de implementarse. Gran parte de esto reside en tu pipeline y en la protección de ramas, lo que significa que una pull request puede eliminar silenciosamente los controles que gobiernan cómo se envían los cambios.
The shapes the same control failure takes.
CC8.1 se debilita cuando un cambio afloja el proceso que debería gobernar los cambios. Las formas recurrentes:
Se elimina una aprobación obligatoria
Se suprime una revisión o puerta de aprobación obligatoria antes de un despliegue en producción del archivo de CI o la protección de ramas, de modo que los cambios pueden implementarse sin autorización.
Una migración omite la revisión
Una migración de base de datos o cambio de datos se configura para ejecutarse al desplegar sin una revisión o aprobación separada de un cambio que modifica los datos de producción.
Las pruebas dejan de bloquear la fusión
Una verificación de estado obligatoria (la suite de pruebas, un escaneo de seguridad) se convierte en no bloqueante o se elimina, permitiendo que cambios no verificados se fusionen.
Se añade una ruta de omisión
Se agrega una ruta de emergencia o de administrador que permite que un cambio llegue a producción fuera del pipeline normal, sin controles equivalentes.
Se elimina el rollback
Se suprime una ruta de rollback segura o de reversión de migración, de modo que un cambio puede implementarse sin poder revertirse de forma limpia si algo sale mal.
Una aprobación de despliegue obligatoria, eliminada.
Una aprobación manual obligatoria antes de los despliegues en producción ha ralentizado las versiones, por lo que un cambio elimina la regla de protección. Los despliegues se aceleran, y ahora cualquier fusión en main llega a producción sin que nadie autorice el cambio.
jobs: deploy:- environment:- name: production # requires a reviewer approval steps:Eliminar la aprobación obligatoria del entorno de producción significa que los cambios ahora llegan a producción sin autorización. CC8.1 exige que los cambios estén autorizados y aprobados antes de implementarse. Si las aprobaciones son demasiado lentas, limita quién o qué las necesita, o automatiza las verificaciones, pero mantén un paso de aprobación en lugar de eliminarlo.
La gestión de cambios se verifica con muestras de cambios reales.
Un auditor examina muestras de cambios que llegaron a producción y busca evidencia de que cada uno fue revisado, probado y aprobado, generalmente la pull request, sus aprobaciones y las verificaciones superadas. Un cambio que eliminó una aprobación obligatoria o hizo que una prueba fuera no bloqueante es el vacío detrás de esa evidencia, y es visible en el diff de la configuración del pipeline o de protección de ramas.
Una revisión, no tu proceso de lanzamiento.
heygrc marca los cambios que afectan a CC8.1 y cita el criterio para que la corrección se realice en la pull request. No ejecuta tus despliegues ni gestiona tu protección de ramas. Detecta el momento en que un cambio afloja el proceso que gobierna los cambios, en el diff.