Descripción General: Requisito 6 de PCI DSS v4.0
El Requisito 6 de PCI DSS v4.0 — Desarrollar y Mantener Sistemas y Software Seguros — es el requisito más directamente relevante para las organizaciones que utilizan pipelines CI/CD para entregar software que procesa, almacena o transmite datos de titulares de tarjetas. Este requisito establece expectativas para las prácticas de desarrollo seguro, la gestión de vulnerabilidades, el control de cambios y las pruebas de seguridad de aplicaciones.
Para los responsables de cumplimiento y auditores, es esencial comprender cómo cada subrequisito se mapea con los controles CI/CD, tanto para implementar pipelines conformes como para verificar el cumplimiento durante las evaluaciones.
Subrequisito 6.1: Establecer y Mantener Procesos de Desarrollo Seguro
El Requisito 6.1 exige que las organizaciones establezcan, documenten y mantengan procesos para identificar vulnerabilidades de seguridad y desarrollar sistemas y software seguros.
Relevancia para CI/CD
- Ciclo de vida de desarrollo seguro (SDLC) documentado: El SDLC debe abordar explícitamente cómo los pipelines CI/CD aplican las prácticas de desarrollo seguro
- Revisión anual de los procesos de desarrollo: Los controles de seguridad y las configuraciones del pipeline deben revisarse al menos anualmente y actualizarse cuando cambie el entorno
- Formación para el personal de desarrollo: Los equipos deben recibir formación sobre prácticas de codificación segura y sobre cómo utilizar eficazmente las herramientas de seguridad del pipeline
Evidencia para la Evaluación
- Política SDLC documentada que hace referencia a los controles de seguridad CI/CD
- Registros de revisión anual con cambios identificados y aprobaciones
- Registros de finalización de formación para el personal de desarrollo
Subrequisito 6.2: Desarrollar Software de Forma Segura
El Requisito 6.2 aborda las prácticas que deben seguirse durante el desarrollo de software, incluyendo la codificación segura, la revisión de código y las pruebas de seguridad.
Relevancia para CI/CD
- Estándares de codificación segura: Aplicación de estándares de codificación a través del pipeline mediante análisis estático y linters automatizados
- Revisión de código antes del lanzamiento: Revisión por pares obligatoria aplicada mediante protección de ramas y requisitos de solicitudes de fusión
- Integración de pruebas de seguridad: SAST, SCA y detección de secretos integrados en el pipeline con criterios de aprobación/rechazo definidos
- Separación de entornos de desarrollo, pruebas y producción: La arquitectura del pipeline debe aplicar la segregación de entornos
Evidencia para la Evaluación
- Configuración del pipeline que muestre las etapas de escaneo de seguridad
- Reglas de protección de ramas que requieran revisión de código
- Resultados de escaneos de seguridad y registros de aplicación de puertas
- Documentación de arquitectura de entornos que demuestre la segregación
Subrequisito 6.3: Identificar y Gestionar Vulnerabilidades de Seguridad
El Requisito 6.3 se centra en la identificación de vulnerabilidades, la clasificación por riesgo y la remediación oportuna en todos los componentes del sistema.
Relevancia para CI/CD
- Escaneo de vulnerabilidades del código personalizado: El escaneo automatizado de vulnerabilidades debe ser parte del proceso de compilación
- Gestión de vulnerabilidades en componentes de terceros: El escaneo de dependencias debe identificar las vulnerabilidades conocidas en las librerías y frameworks consumidos a través del pipeline
- Remediación clasificada por riesgo: Las puertas del pipeline deben aplicar plazos de remediación basados en la severidad de las vulnerabilidades (las vulnerabilidades críticas/altas bloquean el despliegue)
- Gestión de parches: La propia infraestructura del pipeline (herramientas de compilación, runners, imágenes de contenedores) debe ser parcheada y actualizada
Cambios Específicos de v4.0
PCI DSS v4.0 introduce requisitos más prescriptivos en torno a los plazos de gestión de vulnerabilidades. Las vulnerabilidades de severidad crítica y alta deben atenderse con prontitud, y las organizaciones deben definir y cumplir sus propios plazos de remediación basados en la clasificación de riesgos.
Subrequisito 6.4: Proteger las Aplicaciones Web de Cara al Público
El Requisito 6.4 exige la protección de las aplicaciones web de cara al público contra ataques conocidos, ya sea mediante evaluaciones de vulnerabilidades manuales/automatizadas o mediante firewalls de aplicaciones web.
Relevancia para CI/CD
- Integración de DAST: Las pruebas de seguridad de aplicaciones dinámicas pueden integrarse en los pipelines de despliegue para entornos de preproducción o staging
- Automatización del despliegue de WAF: Despliegue y configuración de reglas WAF gestionadas por el pipeline
- Programación de evaluaciones de vulnerabilidades: Evaluaciones de vulnerabilidades automatizadas activadas por despliegues o según programas definidos
Cambios Específicos de v4.0
PCI DSS v4.0 (específicamente 6.4.2) requiere soluciones técnicas automatizadas para aplicaciones web de cara al público que detecten y prevengan continuamente los ataques basados en web. Este es un requisito con fecha futura que se convierte en obligatorio después del 31 de marzo de 2025.
Subrequisito 6.5: Gestionar los Cambios en los Componentes del Sistema
El Requisito 6.5 establece los requisitos de gestión de cambios que gobiernan directamente cómo operan los pipelines CI/CD.
Relevancia para CI/CD
- Procedimientos de control de cambios documentados: El propio pipeline debe estar regido por un procedimiento de control de cambios documentado
- Análisis de impacto: Los cambios deben incluir documentación del impacto, incluido el impacto en la seguridad
- Aprobación autorizada: Todos los cambios en los sistemas de producción deben ser formalmente aprobados por el personal autorizado
- Requisitos de pruebas: Los cambios deben probarse antes del despliegue en producción, con las pruebas verificadas a través de las puertas del pipeline
- Procedimientos de reversión: Procedimientos documentados para revertir los cambios que causen problemas
- Segregación de desarrollo, pruebas y producción: La arquitectura del pipeline debe impedir que los datos de prueba o las configuraciones de desarrollo lleguen a producción
Mapeo Completo: Subrequisito a Control CI/CD
| Subrequisito PCI DSS | Control CI/CD | Evidencia | Método de Verificación del QSA |
|---|---|---|---|
| 6.1.1 — Roles de seguridad definidos | Roles RBAC para el acceso y las operaciones del pipeline | Definiciones de roles, configuración RBAC | Revisar la documentación de roles; verificar que la configuración coincida |
| 6.1.2 — Revisión anual del proceso | Proceso anual de revisión de seguridad del pipeline | Registros de revisión, registro de cambios, registros de aprobación | Examinar la documentación de revisión; confirmar que el alcance incluye CI/CD |
| 6.2.1 — Formación en codificación segura | Formación de desarrolladores sobre herramientas de seguridad del pipeline y codificación segura | Registros de formación, certificados de finalización | Muestrear registros de formación; entrevistar a desarrolladores |
| 6.2.2 — Revisión de código antes de producción | Revisión por pares obligatoria mediante protección de ramas | Configuración de protección de ramas, registros de solicitudes de fusión | Verificar la configuración; muestrear solicitudes de fusión para comprobar la atestación del revisor |
| 6.2.3 — Pruebas de seguridad en el SDLC | SAST, SCA integrados en el pipeline con puertas de bloqueo | Configuración del pipeline, resultados de escaneo, registros de puertas | Revisar la definición del pipeline; muestrear registros de compilación que muestren la ejecución del escaneo |
| 6.2.4 — Técnicas de codificación segura | Aplicación automatizada de estándares de codificación mediante linters y reglas SAST | Configuración de herramientas, conjuntos de reglas, registros de aplicación | Revisar la configuración de reglas; verificar la aplicación en compilaciones de muestra |
| 6.3.1 — Identificación de vulnerabilidades | Escaneo automatizado de vulnerabilidades en el pipeline de compilación | Configuración del escaneo, informes de vulnerabilidades | Verificar que el escaneo se ejecuta en cada compilación; revisar informes de muestra |
| 6.3.2 — Inventario de software mantenido | Generación de SBOM a través del pipeline | Artefactos SBOM, inventarios de dependencias | Verificar la generación del SBOM; comparar con los componentes desplegados |
| 6.3.3 — Parches y actualizaciones aplicados a tiempo | Detección automatizada de actualizaciones de dependencias, seguimiento de SLA de remediación | Informes de antigüedad de vulnerabilidades, plazos de remediación | Muestrear vulnerabilidades; verificar la remediación dentro de los SLAs definidos |
| 6.4.1 — Detección de vulnerabilidades en aplicaciones web | Integración de DAST en el pipeline de despliegue | Configuración de DAST, resultados de escaneo, registros de remediación | Verificar la ejecución de DAST; revisar los hallazgos y la remediación |
| 6.5.1 — Procedimientos de control de cambios seguidos | Gestión de cambios aplicada por el pipeline con aprobación obligatoria | Registros de despliegue con registros de aprobación | Muestrear despliegues; verificar la aprobación antes de la ejecución |
| 6.5.2 — Documentación de cambios completa | Elementos de trabajo vinculados, descripciones de impacto, evidencia de pruebas en los registros de despliegue | Registros de cambios con documentación completa | Muestrear cambios; verificar la completitud de la documentación |
| 6.5.3 — Entorno de producción segregado | Aislamiento de entornos del pipeline, credenciales separadas, segmentación de red | Diagramas de arquitectura, evidencia de configuración | Revisar la arquitectura; verificar los controles de aislamiento |
| 6.5.4 — Separación de funciones | Aplicación por el pipeline que impide la autoaprobación y el autodespliegue | Configuración SoD, informes de validación | Verificar la configuración; muestrear despliegues para el cumplimiento de SoD |
| 6.5.5 — PANs reales no usados en pruebas | Enmascaramiento de datos en el pipeline, controles de datos de entornos | Procedimientos de manejo de datos, gestión de datos de prueba | Revisar los procedimientos de datos de prueba; verificar que no haya datos reales en entornos inferiores |
| 6.5.6 — Datos de prueba eliminados antes de producción | Etapas de limpieza del pipeline, verificación de despliegue en producción | Procedimientos de despliegue, registros de verificación de limpieza | Revisar el proceso de despliegue; verificar las etapas de limpieza |
Nuevos Requisitos de v4.0 que Afectan al CI/CD
Enfoque Personalizado
PCI DSS v4.0 introduce el «enfoque personalizado» como alternativa al tradicional «enfoque definido». Las organizaciones pueden cumplir el objetivo de seguridad de un requisito mediante controles alternativos, siempre que puedan demostrar que el control cumple el objetivo declarado. Para los entornos CI/CD, esto proporciona flexibilidad para implementar controles nativos del pipeline en lugar de adaptar controles tradicionales.
Lo que esto significa para los responsables de cumplimiento: Si su pipeline implementa controles de forma diferente al requisito prescriptivo pero logra el mismo objetivo de seguridad, el enfoque personalizado puede ser apropiado. Sin embargo, esto requiere un Análisis de Riesgo Específico para cada control personalizado y una evidencia más rigurosa de efectividad.
Análisis de Riesgo Específico
v4.0 requiere análisis de riesgo específicos documentados para ciertos requisitos donde la organización determina la frecuencia o el alcance de una actividad de control. Para los pipelines CI/CD, esto incluye:
- Frecuencia de los escaneos de vulnerabilidades y las pruebas de penetración
- Alcance de la revisión de código (qué cambios requieren revisión, qué nivel de revisión)
- Plazos de remediación para los diferentes niveles de severidad de vulnerabilidades
- Frecuencia de revisión de accesos para los sistemas del pipeline
Conexión con Otros Requisitos
| Requisito Relacionado | Conexión con CI/CD | Consideración Clave |
|---|---|---|
| Requisito 7 (Control de Acceso) | El acceso al pipeline debe seguir los principios de necesidad de conocer y mínimo privilegio | RBAC en todos los componentes del pipeline; restringir el acceso al despliegue en producción |
| Requisito 8 (Autenticación) | Autenticación fuerte para todo acceso a los sistemas del pipeline | MFA, complejidad de contraseñas, gestión de credenciales de cuentas de servicio |
| Requisito 10 (Registro y Monitoreo) | Todas las actividades del pipeline deben registrarse y monitorearse | Trazas de auditoría para despliegues, eventos de acceso, cambios de configuración; integridad de los registros |
| Requisito 11 (Pruebas de Seguridad) | Pruebas periódicas de los controles de seguridad del pipeline | El alcance de las pruebas de penetración incluye la infraestructura CI/CD; escaneo de vulnerabilidades de los componentes del pipeline |
Hallazgos Comunes en las Evaluaciones de Entornos CI/CD
- Segregación de entornos incompleta: Los pipelines de desarrollo pueden alcanzar segmentos de red de producción o utilizar credenciales de producción
- Revisión de código ausente para los cambios de configuración del pipeline: El código de la aplicación se revisa pero los archivos de definición del pipeline (Jenkinsfiles, configuraciones YAML) no están sujetos al mismo rigor
- Incumplimientos del SLA de remediación de vulnerabilidades: Las vulnerabilidades conocidas en las dependencias permanecen sin parchear más allá de los plazos definidos
- Registro insuficiente de las actividades del pipeline: Los eventos de despliegue se registran pero las decisiones de aprobación, las anulaciones de puertas y los cambios de configuración carecen de trazas de auditoría
- Cuentas de servicio con alcance excesivo: Las cuentas de servicio del pipeline tienen un acceso más amplio del requerido para su función específica
- Brechas en la gestión de datos de prueba: Los pipelines no aplican el enmascaramiento de datos ni impiden el uso de datos reales de titulares de tarjetas en entornos de prueba
- Generación de SBOM ausente: Sin seguimiento sistemático de los componentes de terceros desplegados en el entorno de datos de titulares de tarjetas
Recursos Relacionados
Relacionado para Auditores
- Glosario — Definiciones en lenguaje sencillo de términos técnicos
- Controles de Seguridad Principales para CI/CD
- Cumplimiento Continuo a través de CI/CD
- Arquitectura de Cumplimiento Dual
¿Nuevo en la auditoría de CI/CD? Comience con nuestra Guía para Auditores.
