Overview: PCI DSS v4.0 Requirement 6
Requirement 6 of PCI DSS v4.0 — Develop and Maintain Secure Systems and Software — is the most directly relevant requirement for organizations using CI/CD pipelines to deliver software that processes, stores, or transmits cardholder data. This requirement establishes expectations for secure development practices, vulnerability management, change control, and application security testing.
For compliance officers and auditors, understanding how each sub-requirement maps to CI/CD controls is essential for both implementing compliant pipelines and verifying compliance during assessments.
Sub-Requirement 6.1: Establish and Maintain Secure Development Processes
Requirement 6.1 mandates that organizations establish, document, and maintain processes for identifying security vulnerabilities and developing secure systems and software.
CI/CD Relevance
- Documented secure development lifecycle (SDLC): The SDLC must explicitly address how CI/CD pipelines enforce secure development practices
- Annual review of development processes: Pipeline security controls and configurations must be reviewed at least annually and updated when the environment changes
- Training for development personnel: Teams must be trained on secure coding practices and on how to use pipeline security tools effectively
Evidence for Assessment
- Documented SDLC policy that references CI/CD security controls
- Annual review records with identified changes and approvals
- Training completion records for development personnel
Sub-Requirement 6.2: Develop Software Securely
Requirement 6.2 addresses the practices that must be followed during software development, including secure coding, code review, and security testing.
CI/CD Relevance
- Secure coding standards: Pipeline enforcement of coding standards through automated linting and static analysis
- Code review before release: Mandatory peer review enforced through branch protection and merge request requirements
- Security testing integration: SAST, SCA, and secrets detection integrated into the pipeline with defined pass/fail criteria
- Separation of development, test, and production environments: Pipeline architecture must enforce environment segregation
Evidence for Assessment
- Pipeline configuration showing security scanning stages
- Branch protection rules requiring code review
- Security scan results and gate enforcement logs
- Environment architecture documentation demonstrating segregation
Sub-Requirement 6.3: Identify and Manage Security Vulnerabilities
Requirement 6.3 focuses on vulnerability identification, risk ranking, and timely remediation across all system components.
CI/CD Relevance
- Vulnerability scanning of custom code: Automated vulnerability scanning must be part of the build process
- Third-party component vulnerability management: Dependency scanning must identify known vulnerabilities in libraries and frameworks consumed through the pipeline
- Risk-ranked remediation: Pipeline gates should enforce remediation timelines based on vulnerability severity (critical/high vulnerabilities block deployment)
- Patch management: Pipeline infrastructure itself (build tools, runners, container images) must be patched and updated
v4.0 Specific Changes
PCI DSS v4.0 introduces more prescriptive requirements around vulnerability management timelines. Critical and high-severity vulnerabilities must be addressed promptly, and organizations must define and follow their own remediation timelines based on risk ranking.
Sub-Requirement 6.4: Protect Public-Facing Web Applications
Requirement 6.4 requires protection of public-facing web applications against known attacks, either through manual/automated vulnerability assessments or through web application firewalls.
CI/CD Relevance
- DAST integration: Dynamic application security testing can be integrated into deployment pipelines for staging or pre-production environments
- WAF deployment automation: Pipeline-managed WAF rule deployment and configuration
- Vulnerability assessment scheduling: Automated vulnerability assessments triggered by deployments or on defined schedules
v4.0 Specific Changes
PCI DSS v4.0 (specifically 6.4.2) requires automated technical solutions for public-facing web applications that continuously detect and prevent web-based attacks. This is a future-dated requirement becoming mandatory after March 31, 2025.
Sub-Requirement 6.5: Manage Changes to System Components
Requirement 6.5 establishes change management requirements that directly govern how CI/CD pipelines operate.
CI/CD Relevance
- Documented change control procedures: The pipeline itself must be governed by a documented change control procedure
- Impact analysis: Changes must include documentation of impact, including security impact
- Authorized approval: All changes to production systems must be formally approved by authorized personnel
- Testing requirements: Changes must be tested before production deployment, with testing verified through pipeline gates
- Rollback procedures: Documented procedures for reversing changes that cause problems
- Segregation of development, test, and production: Pipeline architecture must prevent test data or development configurations from reaching production
Comprehensive Mapping: Sub-Requirement to CI/CD Control
| PCI DSS Sub-Requirement | CI/CD Control | Evidence | QSA Verification Method |
|---|---|---|---|
| 6.1.1 — Security roles defined | RBAC roles for pipeline access and operations | Role definitions, RBAC configuration | Review role documentation; verify configuration matches |
| 6.1.2 — Annual process review | Annual pipeline security review process | Review records, change log, approval records | Examine review documentation; confirm scope includes CI/CD |
| 6.2.1 — Secure coding training | Developer training on pipeline security tools and secure coding | Training records, completion certificates | Sample training records; interview developers |
| 6.2.2 — Code review before production | Mandatory peer review via branch protection | Branch protection configuration, merge request logs | Verify configuration; sample merge requests for reviewer attestation |
| 6.2.3 — Security testing in SDLC | SAST, SCA integrated in pipeline with blocking gates | Pipeline configuration, scan results, gate logs | Review pipeline definition; sample build logs showing scan execution |
| 6.2.4 — Secure coding techniques | Automated coding standard enforcement via linters and SAST rules | Tool configuration, rule sets, enforcement logs | Review rule configuration; verify enforcement on sample builds |
| 6.3.1 — Vulnerability identification | Automated vulnerability scanning in build pipeline | Scan configuration, vulnerability reports | Verify scanning runs on every build; review sample reports |
| 6.3.2 — Software inventory maintained | SBOM generation through pipeline | SBOM artifacts, dependency inventories | Verify SBOM generation; compare against deployed components |
| 6.3.3 — Patches and updates applied timely | Automated dependency update detection, remediation SLA tracking | Vulnerability aging reports, remediation timelines | Sample vulnerabilities; verify remediation within defined SLAs |
| 6.4.1 — Web application vulnerability detection | DAST integration in deployment pipeline | DAST configuration, scan results, remediation records | Verify DAST execution; review findings and remediation |
| 6.5.1 — Change control procedures followed | Pipeline-enforced change management with mandatory approval | Deployment logs with approval records | Sample deployments; verify approval before execution |
| 6.5.2 — Change documentation complete | Linked work items, impact descriptions, test evidence in deployment records | Change records with complete documentation | Sample changes; verify documentation completeness |
| 6.5.3 — Production environment segregated | Pipeline environment isolation, separate credentials, network segmentation | Architecture diagrams, configuration evidence | Review architecture; verify isolation controls |
| 6.5.4 — Separation of duties | Pipeline enforcement preventing self-approval and self-deployment | SoD configuration, validation reports | Verify configuration; sample deployments for SoD compliance |
| 6.5.5 — Live PANs not used in test | Pipeline data masking, environment data controls | Data handling procedures, test data management | Review test data procedures; verify no live data in lower environments |
| 6.5.6 — Test data removed before production | Pipeline cleanup stages, production deployment verification | Deployment procedures, cleanup verification logs | Review deployment process; verify cleanup stages |
New v4.0 Requirements Affecting CI/CD
Customized Approach
PCI DSS v4.0 introduces the “customized approach” as an alternative to the traditional “defined approach.” Organizations can meet the security objective of a requirement through alternative controls, provided they can demonstrate the control meets the stated objective. For CI/CD environments, this provides flexibility to implement pipeline-native controls rather than retrofitting traditional controls.
What this means for compliance officers: If your pipeline implements controls differently from the prescriptive requirement but achieves the same security objective, the customized approach may be appropriate. However, this requires a Targeted Risk Analysis for each customized control and more rigorous evidence of effectiveness.
Targeted Risk Analysis
v4.0 requires documented targeted risk analyses for specific requirements where the organization determines the frequency or scope of a control activity. For CI/CD pipelines, this includes:
- Frequency of vulnerability scans and penetration tests
- Scope of code review (which changes require review, what level of review)
- Remediation timelines for different vulnerability severity levels
- Access review frequency for pipeline systems
Connection to Other Requirements
| Related Requirement | Connection to CI/CD | Key Consideration |
|---|---|---|
| Requirement 7 (Access Control) | Pipeline access must follow need-to-know and least-privilege principles | RBAC across all pipeline components; restrict access to production deployment |
| Requirement 8 (Authentication) | Strong authentication for all pipeline system access | MFA, password complexity, service account credential management |
| Requirement 10 (Logging and Monitoring) | All pipeline activities must be logged and monitored | Audit trails for deployments, access events, configuration changes; log integrity |
| Requirement 11 (Security Testing) | Regular testing of pipeline security controls | Penetration testing scope includes CI/CD infrastructure; vulnerability scanning of pipeline components |
Common Assessment Findings in CI/CD Environments
- Incomplete environment segregation: Development pipelines can reach production network segments or use production credentials
- Missing code review for pipeline configuration changes: Application code is reviewed but pipeline definition files (Jenkinsfiles, YAML configurations) are not subject to the same rigor
- Vulnerability remediation SLA breaches: Known vulnerabilities in dependencies remain unpatched beyond defined timelines
- Insufficient logging of pipeline activities: Deployment events are logged but approval decisions, gate overrides, and configuration changes lack audit trails
- Service accounts with excessive scope: Pipeline service accounts have broader access than required for their specific function
- Test data management gaps: Pipelines do not enforce data masking or prevent use of live cardholder data in test environments
- Missing SBOM generation: No systematic tracking of third-party components deployed to the cardholder data environment
Related Resources
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- Core CI/CD Security Controls
- Continuous Compliance via CI/CD
- Dual-Compliance Architecture
New to CI/CD auditing? Start with our Auditor’s Guide.
