Lo que pide un auditor, o el motor de evidencias de Sekit.
Política de desarrollo seguro
Las reglas que sigue el equipo de desarrollo para crear software de forma segura: requisitos de seguridad, revisión de código y modelado de amenazas.
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 separación de entornos es fácil de enunciar y erosionar sin ruido: un desarrollador con acceso residual de depuración a la base de datos de producción, o un entorno de pruebas con datos reales de clientes porque generar datos realistas toma más tiempo. Los auditores revisan los cambios y lanzamientos para confirmar revisión y aprobación, no un push directo desde una laptop, y verifican si la protección de datos salientes detecta datos sensibles que se muevan hacia un entorno inferior. Las pruebas de penetración necesitan la misma disciplina, a la inversa, aislando objetivos sin afectar la disponibilidad de producción. La brecha más frecuente es una base de datos de staging con registros de clientes sin enmascarar de hace meses.
Brechas habituales
El entorno de staging se siembra con una copia sin enmascarar de la base de datos de clientes de producción, que se refresca mensualmente sin ningún paso de enmascaramiento aplicado.
Un desarrollador conserva acceso permanente a la base de datos de producción, que quedó de un incidente de hace meses, sin ningún ticket que documente por qué nunca se revocó.
Una corrección urgente pasó directo a producción durante un incidente, saltándose el entorno de pruebas, y nadie registró el cambio de emergencia ni lo revisó después.
Preguntas que hará tu auditor
¿Los datos de prueba están enmascarados o son datos reales de clientes?
Los entornos de prueba operan con datos enmascarados o sintéticos en vez de una copia cruda de producción, y la tecnología de protección de datos salientes marca cualquier dato de cliente sin enmascarar que intente moverse hacia ahí, dando seguimiento a los intentos confirmados.
¿El código puede llegar a producción sin pasar antes por el entorno de pruebas?
No. Todo cambio pasa primero por el entorno de pruebas: la gestión de lanzamientos exige que supere las pruebas y la aprobación, y el pipeline bloquea cualquier compilación que no haya superado sus comprobaciones antes de llegar a producción.
¿Cómo evitan que las pruebas de penetración afecten la disponibilidad de producción?
Los evaluadores apuntan a una réplica aislada de staging en vez de a los sistemas en vivo, y cualquier prueba cercana a producción ocurre en una ventana de mantenimiento acordada, con un plan de reversión listo por si algo sale mal.
Dónde lo exige la regulación
NIS2 art. 6.2 exige un ciclo de vida de desarrollo seguro que mantenga la actividad de desarrollo separada de producción, y ENS mp.sw.2 exige aceptación formal antes de poner el software en servicio en producción.
Controles relacionados
Vía el tema compartido del Sekit CSF, no el índice del propio marco.