Lo que pide un auditor, o el motor de evidencias de Sekit.
Seguridad de la cadena de construcción y despliegue (CI/CD)
Los controles de seguridad en el proceso automatizado de construir y desplegar software, incluidos contenedores e infraestructura como código.
Gestión de cambios y de versiones
El proceso para revisar y aprobar los cambios en los sistemas de producción antes de aplicarlos, y cómo se publican las nuevas versiones de forma controlada.
Del catálogo de evidencias de Sekit
En la práctica
La gestión de cambios funciona cuando la aprobación se aplica técnicamente, no solo en un procedimiento que ingenieros ocupados sortean bajo presión de plazos. Los auditores quieren ver los registros de cambios y lanzamientos que muestran revisión y aprobación antes de los cambios de producción, contrastados con el repositorio de activos para confirmar que se actualizó en el mismo cambio y no meses después durante un inventario físico. Los despliegues deben pasar por un pipeline con lanzamientos repetibles y una vía rápida de reversión, porque un cambio que no puede revertirse rápido convierte un error menor en una interrupción prolongada. La brecha que se repite es un cambio de emergencia usado rutinariamente porque la aprobación estándar se percibe demasiado lenta.
Brechas habituales
El proceso de cambio de emergencia, pensado para incidentes reales, se usa de forma rutinaria para cambios que podrían haber pasado por revisión y aprobación estándar.
Los controles técnicos del pipeline de despliegue bloquean cambios no autorizados, pero un puñado de administradores conserva acceso directo a producción que evade el pipeline por completo.
El repositorio de activos se actualiza de forma inconsistente después de los cambios, así que varios sistemas de producción ya no coinciden con su configuración registrada.
Preguntas que hará tu auditor
¿Todo cambio a producción pasa primero por revisión y aprobación?
Sí, ningún cambio llega a los sistemas de producción sin revisión y aprobación previas, y quién puede aprobar qué está definido por escrito.
¿Qué pasa si un cambio lanzado causa un problema?
Los despliegues pasan por un pipeline que produce lanzamientos repetibles y puede revertir rápido a la versión anterior funcional cuando un lanzamiento sale mal.
¿Cómo mantienen precisos sus registros de activos a medida que ocurren cambios?
El repositorio de activos se actualiza como parte rutinaria de cada cambio, así que los registros de activos, configuraciones y sus relaciones se mantienen al día.
¿Un cambio no aprobado puede llegar a producción, o solo se detecta a posteriori?
El flujo de cambios se aplica técnicamente para que los cambios no aprobados a producción se bloqueen en vez de solo desalentarse por política.
Dónde lo exige la regulación
NIS2 art. 6.4 exige un proceso controlado para la gestión de cambios, reparaciones y mantenimiento, y ENS op.exp.1 exige un inventario de activos preciso mantenido al día mediante ese mismo proceso.
Controles relacionados
Vía el tema compartido del Sekit CSF, no el índice del propio marco.