PCI DSS Requirement 6 is where security engineering meets compliance. It governs how you develop, maintain, and protect the software that handles cardholder data. For engineering teams, this is the requirement that touches your daily workflow: your development lifecycle, your code review process, your dependency management, and your web application defenses.
v4.0 significantly expanded Requirement 6, adding new sub-requirements for software inventory, payment page script management, and custom software security training. Here is what each sub-requirement means in practice and how to satisfy your QSA without rebuilding your entire development process.
Requirement 6.1: Security Vulnerability Management
Requirement 6.1 establishes the foundation: you must have a process for identifying and ranking security vulnerabilities in your systems. This applies to all system components in your CDE, including operating systems, databases, web servers, and custom application code.
What your QSA checks: A documented vulnerability management process, evidence of regular vulnerability identification (through scanning, vendor advisories, and threat intelligence feeds), a risk-ranking methodology, and evidence that vulnerabilities are addressed within defined timeframes based on their risk ranking.
Common gap: Organizations track vulnerabilities from automated scans but do not incorporate vendor security advisories, CVE databases, or threat intelligence into their identification process. Your QSA will ask how you learn about new vulnerabilities beyond your scanning tools.
Requirement 6.2: Secure Development Lifecycle
This is the heart of Requirement 6 for development teams. v4.0 Requirement 6.2 mandates a secure software development lifecycle (SDLC) for all bespoke and custom software that is part of, or interacts with, the CDE.
| Sub-Requirement | What It Requires | Evidence Your QSA Wants |
|---|---|---|
| 6.2.1 | Secure development processes defined and followed | Documented SDLC policy, evidence of adherence in recent development cycles |
| 6.2.2 | Software development personnel trained in secure coding at least annually | Training records, course completions, coverage of relevant vulnerability types |
| 6.2.3 | Custom software reviewed prior to release to production | Code review records, SAST/DAST scan results, sign-off documentation |
| 6.2.3.1 | Manual or automated code review covers common vulnerability types | Evidence that reviews cover OWASP Top 10, injection, XSS, auth flaws, etc. |
| 6.2.4 | Software engineering techniques prevent common vulnerabilities | Use of parameterized queries, output encoding, input validation frameworks |
Secure coding training (6.2.2)
Every developer who writes code for CDE systems must receive annual secure coding training. The training must cover the vulnerability types relevant to your technology stack and development language. A generic "security awareness" course does not satisfy this requirement. Your QSA will verify that the training content is relevant to the languages and frameworks your team uses and that it covers at minimum the vulnerability types listed in the standard.
Code review requirements (6.2.3 and 6.2.3.1)
All custom code must be reviewed for security vulnerabilities before release to production. v4.0 accepts manual code review, automated static analysis (SAST), dynamic analysis (DAST), or a combination. The review must cover common vulnerability types including injection flaws, authentication and access control vulnerabilities, cross-site scripting, and insecure cryptographic storage.
If you use automated tools, your QSA will verify that the tool is configured to detect the required vulnerability types and that findings are reviewed and addressed before code reaches production. If you use manual code review, the reviewer must be someone other than the developer who wrote the code and must have expertise in secure code review practices.
Practical approach: Most engineering teams satisfy 6.2.3 through a combination of automated SAST scanning in the CI/CD pipeline (catching known patterns) and manual code review for security-sensitive changes (catching logic flaws). This layered approach satisfies the requirement and actually catches vulnerabilities. See our top code review findings for the vulnerability patterns we see most frequently.
Requirement 6.3: Software Inventory and Vulnerability Identification
v4.0 added a new emphasis on knowing what software you are running and keeping it updated. Requirement 6.3 mandates a software inventory for all CDE components and a process for identifying vulnerabilities in those components.
Software inventory (6.3.1 and 6.3.2)
You must maintain an inventory of all bespoke and custom software, including third-party libraries and dependencies. For custom software (6.3.2, formerly future-dated), you must also identify known vulnerabilities in that software. This effectively mandates Software Bill of Materials (SBOM) capabilities or dependency scanning for your custom applications.
Tools like Snyk, Dependabot, Trivy, or OWASP Dependency-Check satisfy this requirement when properly configured. Your QSA will want to see the inventory, evidence of regular vulnerability identification, and a process for addressing identified vulnerabilities.
Patching timelines (6.3.3)
Critical and high-severity security patches must be installed within one month of release. For other patches, the timeline is determined by your targeted risk analysis. Your QSA will sample systems in the CDE and check patch levels against vendor release dates. If a critical patch was released 45 days ago and your systems are not patched, that is a finding.
Requirement 6.4: Public-Facing Web Application Protection
Requirement 6.4 is where most organizations spend the most effort. It governs how you protect web applications that interact with the CDE, particularly payment pages.
WAF requirements (6.4.1 and 6.4.2)
Public-facing web applications must be protected by a web application firewall (WAF) or equivalent technology that detects and prevents web-based attacks. The key word is "prevents." A WAF running in monitor-only or detection-only mode does not satisfy the requirement. It must be actively blocking attacks.
Alternatively, you can satisfy this requirement through a combination of automated vulnerability assessment tools and manual application security assessment at least annually. But for most organizations, deploying a WAF is the more practical and cost-effective approach.
Payment page script management (6.4.3)
This is the v4.0 requirement that has caused the most implementation headaches. For payment pages that are loaded in the consumer's browser, you must:
- Maintain an inventory of all scripts on the payment page
- Have a method to confirm each script is authorized
- Have a method to ensure the integrity of each script
- Justify the business or technical need for each script
This targets Magecart-style attacks where attackers inject malicious JavaScript into payment pages to skim card data. Implementation approaches include Content Security Policy (CSP) with strict source restrictions, Subresource Integrity (SRI) for third-party scripts, and commercial payment page monitoring solutions.
If you use an iframe-based payment form from a PCI-compliant provider (like Stripe Elements or Braintree Hosted Fields), the iframe contents are on the provider's domain and their responsibility. But you are still responsible for the page that contains the iframe. If an attacker injects a script that overlays a fake payment form on top of your legitimate iframe, that is your problem. Requirement 6.4.3 still applies to the parent page.
Requirement 6.5: Change Management
Requirement 6.5 governs change management for all CDE system components. Every change must follow a documented change control process that includes documentation of the change, management approval, functionality testing, and back-out procedures.
Production vs. development environments (6.5.1-6.5.4)
Development, testing, and production environments must be separated. Live PANs (primary account numbers) must not be used in development or testing environments. Access controls for production must be different from development. These requirements exist because we routinely find production credentials, test cardholder data, and developer access to production during penetration testing engagements.
| Change Management Element | v4.0 Requirement | What QSAs Check |
|---|---|---|
| Documentation | Impact analysis and description of change | Change tickets with business justification and technical description |
| Approval | Authorized management sign-off | Approval records in change management system |
| Testing | Verification that change works as intended | Test results and QA sign-off before production deployment |
| Rollback | Back-out procedures documented | Documented rollback plan for each change |
| Separation | Dev/test/prod environments isolated | Network segmentation, separate credentials, no live data in dev |
How Penetration Testing Validates Requirement 6
Penetration testing is the external validation that your Requirement 6 controls actually work. When we conduct a PCI DSS penetration test, we specifically test the controls that Requirement 6 is designed to enforce.
We test whether your WAF actually blocks attacks (not just logs them). We test whether your code review process caught common vulnerability types before they reached production. We test whether your change management process prevented development credentials from appearing in production. We test whether your dependency management process caught known vulnerable libraries.
The findings from a pentest provide direct evidence of Requirement 6 compliance or non-compliance. A finding of SQL injection in a production application means 6.2.4 (preventing common vulnerabilities) and 6.2.3 (pre-release code review) were not effective. A finding that the WAF can be bypassed means 6.4.2 is not satisfied. Your QSA will cross-reference pentest findings with Requirement 6 sub-requirements, so addressing pentest findings is directly tied to your compliance posture.
Practical Implementation for Engineering Teams
If your engineering team needs to satisfy Requirement 6, here is the practical implementation path that minimizes disruption to your development workflow while meeting every sub-requirement.
Integrate SAST into CI/CD. Deploy a static analysis tool (Semgrep, SonarQube, Checkmarx, or similar) as a pipeline gate. Configure it to fail builds on critical and high-severity findings. This satisfies 6.2.3 with evidence your QSA can verify through pipeline logs.
Add dependency scanning. Enable Dependabot, Snyk, or Trivy in your repository. Configure it to alert on known vulnerabilities in dependencies. This satisfies 6.3.1 and 6.3.2 and produces the software inventory your QSA needs.
Enforce code review. Require pull request reviews by someone other than the author before merging to main. Document that reviewers check for security issues. Git history provides the evidence trail your QSA needs for 6.2.3.
Deploy a WAF in blocking mode. AWS WAF, Cloudflare WAF, or Fastly WAF all satisfy 6.4.1 and 6.4.2 when configured to block the OWASP Top 10 attack categories. Document your ruleset and review it quarterly.
Implement CSP for payment pages. Deploy a Content Security Policy that restricts script sources on any page that handles or displays payment information. This satisfies 6.4.3. Use CSP reporting to detect violations, which also feeds into 11.6.1 (tamper detection).
Schedule annual developer training. Use a platform like SANS Secure Coding, HackEDU, Secure Code Warrior, or similar for annual secure coding training. Ensure the training covers the languages your team uses. Keep completion records for your QSA.
Need help validating your Requirement 6 controls?
Our PCI DSS penetration tests specifically evaluate secure development controls including WAF effectiveness, code-level vulnerabilities, and payment page security.
