{"id":2047,"date":"2026-03-25T17:02:21","date_gmt":"2026-03-25T16:02:21","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/pci-dss-v4-0-requisitos-de-entrega-de-software-analisis-en-profundidad-del-requisito-6\/"},"modified":"2026-03-26T09:35:01","modified_gmt":"2026-03-26T08:35:01","slug":"pci-dss-v4-0-software-delivery-requirements-requirement-6-deep-dive","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/es\/ci-cd-governance-es\/pci-dss-v4-0-software-delivery-requirements-requirement-6-deep-dive\/","title":{"rendered":"PCI DSS v4.0 \u2014 Requisitos de Entrega de Software (An\u00e1lisis en Profundidad del Requisito 6)"},"content":{"rendered":"

Descripci\u00f3n General: Requisito 6 de PCI DSS v4.0<\/h2>\n

El Requisito 6 de PCI DSS v4.0 \u2014 Desarrollar y Mantener Sistemas y Software Seguros<\/em> \u2014 es el requisito m\u00e1s 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\u00e1cticas de desarrollo seguro, la gesti\u00f3n de vulnerabilidades, el control de cambios y las pruebas de seguridad de aplicaciones.<\/p>\n

Para los responsables de cumplimiento y auditores, es esencial comprender c\u00f3mo cada subrequisito se mapea con los controles CI\/CD, tanto para implementar pipelines conformes como para verificar el cumplimiento durante las evaluaciones.<\/p>\n

Subrequisito 6.1: Establecer y Mantener Procesos de Desarrollo Seguro<\/h2>\n

El Requisito 6.1 exige que las organizaciones establezcan, documenten y mantengan procesos para identificar vulnerabilidades de seguridad y desarrollar sistemas y software seguros.<\/p>\n

Relevancia para CI\/CD<\/h3>\n
    \n
  • Ciclo de vida de desarrollo seguro (SDLC) documentado:<\/strong> El SDLC debe abordar expl\u00edcitamente c\u00f3mo los pipelines CI\/CD aplican las pr\u00e1cticas de desarrollo seguro<\/li>\n
  • Revisi\u00f3n anual de los procesos de desarrollo:<\/strong> Los controles de seguridad y las configuraciones del pipeline deben revisarse al menos anualmente y actualizarse cuando cambie el entorno<\/li>\n
  • Formaci\u00f3n para el personal de desarrollo:<\/strong> Los equipos deben recibir formaci\u00f3n sobre pr\u00e1cticas de codificaci\u00f3n segura y sobre c\u00f3mo utilizar eficazmente las herramientas de seguridad del pipeline<\/li>\n<\/ul>\n

    Evidencia para la Evaluaci\u00f3n<\/h3>\n
      \n
    • Pol\u00edtica SDLC documentada que hace referencia a los controles de seguridad CI\/CD<\/li>\n
    • Registros de revisi\u00f3n anual con cambios identificados y aprobaciones<\/li>\n
    • Registros de finalizaci\u00f3n de formaci\u00f3n para el personal de desarrollo<\/li>\n<\/ul>\n

      Subrequisito 6.2: Desarrollar Software de Forma Segura<\/h2>\n

      El Requisito 6.2 aborda las pr\u00e1cticas que deben seguirse durante el desarrollo de software, incluyendo la codificaci\u00f3n segura, la revisi\u00f3n de c\u00f3digo y las pruebas de seguridad.<\/p>\n

      Relevancia para CI\/CD<\/h3>\n
        \n
      • Est\u00e1ndares de codificaci\u00f3n segura:<\/strong> Aplicaci\u00f3n de est\u00e1ndares de codificaci\u00f3n a trav\u00e9s del pipeline mediante an\u00e1lisis est\u00e1tico y linters automatizados<\/li>\n
      • Revisi\u00f3n de c\u00f3digo antes del lanzamiento:<\/strong> Revisi\u00f3n por pares obligatoria aplicada mediante protecci\u00f3n de ramas y requisitos de solicitudes de fusi\u00f3n<\/li>\n
      • Integraci\u00f3n de pruebas de seguridad:<\/strong> SAST, SCA y detecci\u00f3n de secretos integrados en el pipeline con criterios de aprobaci\u00f3n\/rechazo definidos<\/li>\n
      • Separaci\u00f3n de entornos de desarrollo, pruebas y producci\u00f3n:<\/strong> La arquitectura del pipeline debe aplicar la segregaci\u00f3n de entornos<\/li>\n<\/ul>\n

        Evidencia para la Evaluaci\u00f3n<\/h3>\n
          \n
        • Configuraci\u00f3n del pipeline que muestre las etapas de escaneo de seguridad<\/li>\n
        • Reglas de protecci\u00f3n de ramas que requieran revisi\u00f3n de c\u00f3digo<\/li>\n
        • Resultados de escaneos de seguridad y registros de aplicaci\u00f3n de puertas<\/li>\n
        • Documentaci\u00f3n de arquitectura de entornos que demuestre la segregaci\u00f3n<\/li>\n<\/ul>\n

          Subrequisito 6.3: Identificar y Gestionar Vulnerabilidades de Seguridad<\/h2>\n

          El Requisito 6.3 se centra en la identificaci\u00f3n de vulnerabilidades, la clasificaci\u00f3n por riesgo y la remediaci\u00f3n oportuna en todos los componentes del sistema.<\/p>\n

          Relevancia para CI\/CD<\/h3>\n
            \n
          • Escaneo de vulnerabilidades del c\u00f3digo personalizado:<\/strong> El escaneo automatizado de vulnerabilidades debe ser parte del proceso de compilaci\u00f3n<\/li>\n
          • Gesti\u00f3n de vulnerabilidades en componentes de terceros:<\/strong> El escaneo de dependencias debe identificar las vulnerabilidades conocidas en las librer\u00edas y frameworks consumidos a trav\u00e9s del pipeline<\/li>\n
          • Remediaci\u00f3n clasificada por riesgo:<\/strong> Las puertas del pipeline deben aplicar plazos de remediaci\u00f3n basados en la severidad de las vulnerabilidades (las vulnerabilidades cr\u00edticas\/altas bloquean el despliegue)<\/li>\n
          • Gesti\u00f3n de parches:<\/strong> La propia infraestructura del pipeline (herramientas de compilaci\u00f3n, runners, im\u00e1genes de contenedores) debe ser parcheada y actualizada<\/li>\n<\/ul>\n

            Cambios Espec\u00edficos de v4.0<\/h3>\n

            PCI DSS v4.0 introduce requisitos m\u00e1s prescriptivos en torno a los plazos de gesti\u00f3n de vulnerabilidades. Las vulnerabilidades de severidad cr\u00edtica y alta deben atenderse con prontitud, y las organizaciones deben definir y cumplir sus propios plazos de remediaci\u00f3n basados en la clasificaci\u00f3n de riesgos.<\/p>\n

            Subrequisito 6.4: Proteger las Aplicaciones Web de Cara al P\u00fablico<\/h2>\n

            El Requisito 6.4 exige la protecci\u00f3n de las aplicaciones web de cara al p\u00fablico contra ataques conocidos, ya sea mediante evaluaciones de vulnerabilidades manuales\/automatizadas o mediante firewalls de aplicaciones web.<\/p>\n

            Relevancia para CI\/CD<\/h3>\n
              \n
            • Integraci\u00f3n de DAST:<\/strong> Las pruebas de seguridad de aplicaciones din\u00e1micas pueden integrarse en los pipelines de despliegue para entornos de preproducci\u00f3n o staging<\/li>\n
            • Automatizaci\u00f3n del despliegue de WAF:<\/strong> Despliegue y configuraci\u00f3n de reglas WAF gestionadas por el pipeline<\/li>\n
            • Programaci\u00f3n de evaluaciones de vulnerabilidades:<\/strong> Evaluaciones de vulnerabilidades automatizadas activadas por despliegues o seg\u00fan programas definidos<\/li>\n<\/ul>\n

              Cambios Espec\u00edficos de v4.0<\/h3>\n

              PCI DSS v4.0 (espec\u00edficamente 6.4.2) requiere soluciones t\u00e9cnicas automatizadas para aplicaciones web de cara al p\u00fablico que detecten y prevengan continuamente los ataques basados en web. Este es un requisito con fecha futura que se convierte en obligatorio despu\u00e9s del 31 de marzo de 2025.<\/p>\n

              Subrequisito 6.5: Gestionar los Cambios en los Componentes del Sistema<\/h2>\n

              El Requisito 6.5 establece los requisitos de gesti\u00f3n de cambios que gobiernan directamente c\u00f3mo operan los pipelines CI\/CD.<\/p>\n

              Relevancia para CI\/CD<\/h3>\n
                \n
              • Procedimientos de control de cambios documentados:<\/strong> El propio pipeline debe estar regido por un procedimiento de control de cambios documentado<\/li>\n
              • An\u00e1lisis de impacto:<\/strong> Los cambios deben incluir documentaci\u00f3n del impacto, incluido el impacto en la seguridad<\/li>\n
              • Aprobaci\u00f3n autorizada:<\/strong> Todos los cambios en los sistemas de producci\u00f3n deben ser formalmente aprobados por el personal autorizado<\/li>\n
              • Requisitos de pruebas:<\/strong> Los cambios deben probarse antes del despliegue en producci\u00f3n, con las pruebas verificadas a trav\u00e9s de las puertas del pipeline<\/li>\n
              • Procedimientos de reversi\u00f3n:<\/strong> Procedimientos documentados para revertir los cambios que causen problemas<\/li>\n
              • Segregaci\u00f3n de desarrollo, pruebas y producci\u00f3n:<\/strong> La arquitectura del pipeline debe impedir que los datos de prueba o las configuraciones de desarrollo lleguen a producci\u00f3n<\/li>\n<\/ul>\n

                Mapeo Completo: Subrequisito a Control CI\/CD<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
                Subrequisito PCI DSS<\/th>\nControl CI\/CD<\/th>\nEvidencia<\/th>\nM\u00e9todo de Verificaci\u00f3n del QSA<\/th>\n<\/tr>\n<\/thead>\n
                6.1.1 \u2014 Roles de seguridad definidos<\/td>\nRoles RBAC para el acceso y las operaciones del pipeline<\/td>\nDefiniciones de roles, configuraci\u00f3n RBAC<\/td>\nRevisar la documentaci\u00f3n de roles; verificar que la configuraci\u00f3n coincida<\/td>\n<\/tr>\n
                6.1.2 \u2014 Revisi\u00f3n anual del proceso<\/td>\nProceso anual de revisi\u00f3n de seguridad del pipeline<\/td>\nRegistros de revisi\u00f3n, registro de cambios, registros de aprobaci\u00f3n<\/td>\nExaminar la documentaci\u00f3n de revisi\u00f3n; confirmar que el alcance incluye CI\/CD<\/td>\n<\/tr>\n
                6.2.1 \u2014 Formaci\u00f3n en codificaci\u00f3n segura<\/td>\nFormaci\u00f3n de desarrolladores sobre herramientas de seguridad del pipeline y codificaci\u00f3n segura<\/td>\nRegistros de formaci\u00f3n, certificados de finalizaci\u00f3n<\/td>\nMuestrear registros de formaci\u00f3n; entrevistar a desarrolladores<\/td>\n<\/tr>\n
                6.2.2 \u2014 Revisi\u00f3n de c\u00f3digo antes de producci\u00f3n<\/td>\nRevisi\u00f3n por pares obligatoria mediante protecci\u00f3n de ramas<\/td>\nConfiguraci\u00f3n de protecci\u00f3n de ramas, registros de solicitudes de fusi\u00f3n<\/td>\nVerificar la configuraci\u00f3n; muestrear solicitudes de fusi\u00f3n para comprobar la atestaci\u00f3n del revisor<\/td>\n<\/tr>\n
                6.2.3 \u2014 Pruebas de seguridad en el SDLC<\/td>\nSAST, SCA integrados en el pipeline con puertas de bloqueo<\/td>\nConfiguraci\u00f3n del pipeline, resultados de escaneo, registros de puertas<\/td>\nRevisar la definici\u00f3n del pipeline; muestrear registros de compilaci\u00f3n que muestren la ejecuci\u00f3n del escaneo<\/td>\n<\/tr>\n
                6.2.4 \u2014 T\u00e9cnicas de codificaci\u00f3n segura<\/td>\nAplicaci\u00f3n automatizada de est\u00e1ndares de codificaci\u00f3n mediante linters y reglas SAST<\/td>\nConfiguraci\u00f3n de herramientas, conjuntos de reglas, registros de aplicaci\u00f3n<\/td>\nRevisar la configuraci\u00f3n de reglas; verificar la aplicaci\u00f3n en compilaciones de muestra<\/td>\n<\/tr>\n
                6.3.1 \u2014 Identificaci\u00f3n de vulnerabilidades<\/td>\nEscaneo automatizado de vulnerabilidades en el pipeline de compilaci\u00f3n<\/td>\nConfiguraci\u00f3n del escaneo, informes de vulnerabilidades<\/td>\nVerificar que el escaneo se ejecuta en cada compilaci\u00f3n; revisar informes de muestra<\/td>\n<\/tr>\n
                6.3.2 \u2014 Inventario de software mantenido<\/td>\nGeneraci\u00f3n de SBOM a trav\u00e9s del pipeline<\/td>\nArtefactos SBOM, inventarios de dependencias<\/td>\nVerificar la generaci\u00f3n del SBOM; comparar con los componentes desplegados<\/td>\n<\/tr>\n
                6.3.3 \u2014 Parches y actualizaciones aplicados a tiempo<\/td>\nDetecci\u00f3n automatizada de actualizaciones de dependencias, seguimiento de SLA de remediaci\u00f3n<\/td>\nInformes de antig\u00fcedad de vulnerabilidades, plazos de remediaci\u00f3n<\/td>\nMuestrear vulnerabilidades; verificar la remediaci\u00f3n dentro de los SLAs definidos<\/td>\n<\/tr>\n
                6.4.1 \u2014 Detecci\u00f3n de vulnerabilidades en aplicaciones web<\/td>\nIntegraci\u00f3n de DAST en el pipeline de despliegue<\/td>\nConfiguraci\u00f3n de DAST, resultados de escaneo, registros de remediaci\u00f3n<\/td>\nVerificar la ejecuci\u00f3n de DAST; revisar los hallazgos y la remediaci\u00f3n<\/td>\n<\/tr>\n
                6.5.1 \u2014 Procedimientos de control de cambios seguidos<\/td>\nGesti\u00f3n de cambios aplicada por el pipeline con aprobaci\u00f3n obligatoria<\/td>\nRegistros de despliegue con registros de aprobaci\u00f3n<\/td>\nMuestrear despliegues; verificar la aprobaci\u00f3n antes de la ejecuci\u00f3n<\/td>\n<\/tr>\n
                6.5.2 \u2014 Documentaci\u00f3n de cambios completa<\/td>\nElementos de trabajo vinculados, descripciones de impacto, evidencia de pruebas en los registros de despliegue<\/td>\nRegistros de cambios con documentaci\u00f3n completa<\/td>\nMuestrear cambios; verificar la completitud de la documentaci\u00f3n<\/td>\n<\/tr>\n
                6.5.3 \u2014 Entorno de producci\u00f3n segregado<\/td>\nAislamiento de entornos del pipeline, credenciales separadas, segmentaci\u00f3n de red<\/td>\nDiagramas de arquitectura, evidencia de configuraci\u00f3n<\/td>\nRevisar la arquitectura; verificar los controles de aislamiento<\/td>\n<\/tr>\n
                6.5.4 \u2014 Separaci\u00f3n de funciones<\/td>\nAplicaci\u00f3n por el pipeline que impide la autoaprobaci\u00f3n y el autodesp\u00adliegue<\/td>\nConfiguraci\u00f3n SoD, informes de validaci\u00f3n<\/td>\nVerificar la configuraci\u00f3n; muestrear despliegues para el cumplimiento de SoD<\/td>\n<\/tr>\n
                6.5.5 \u2014 PANs reales no usados en pruebas<\/td>\nEnmascaramiento de datos en el pipeline, controles de datos de entornos<\/td>\nProcedimientos de manejo de datos, gesti\u00f3n de datos de prueba<\/td>\nRevisar los procedimientos de datos de prueba; verificar que no haya datos reales en entornos inferiores<\/td>\n<\/tr>\n
                6.5.6 \u2014 Datos de prueba eliminados antes de producci\u00f3n<\/td>\nEtapas de limpieza del pipeline, verificaci\u00f3n de despliegue en producci\u00f3n<\/td>\nProcedimientos de despliegue, registros de verificaci\u00f3n de limpieza<\/td>\nRevisar el proceso de despliegue; verificar las etapas de limpieza<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                Nuevos Requisitos de v4.0 que Afectan al CI\/CD<\/h2>\n

                Enfoque Personalizado<\/h3>\n

                PCI DSS v4.0 introduce el \u00abenfoque personalizado\u00bb como alternativa al tradicional \u00abenfoque definido\u00bb. 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.<\/p>\n

                Lo que esto significa para los responsables de cumplimiento:<\/strong> 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\u00e1lisis de Riesgo Espec\u00edfico para cada control personalizado y una evidencia m\u00e1s rigurosa de efectividad.<\/p>\n

                An\u00e1lisis de Riesgo Espec\u00edfico<\/h3>\n

                v4.0 requiere an\u00e1lisis de riesgo espec\u00edficos documentados para ciertos requisitos donde la organizaci\u00f3n determina la frecuencia o el alcance de una actividad de control. Para los pipelines CI\/CD, esto incluye:<\/p>\n