PCI DSS 4.0 Requirement 6: How to Develop and Maintain Secure Systems and Software

Table of Contents

1. Introduction to Requirement 6
2. Why Secure Development and Maintenance Matters
3. Key Elements of Requirement 6
   
   • 3.1 Secure SDLC (Software Development Lifecycle)
   • 3.2 Patch Management & Vulnerability Remediation
   • 3.3 New Emphasis on Payment Page Scripts (6.4.3)
4. EOL Software Considerations
5. Real-World Examples of Software-Related Breaches
6. Ongoing Monitoring and Validation
7. How HeroDevs Supports Secure Development
8. Key Takeaways and Next Steps
9. Frequently Asked Questions (FAQs)

1. Introduction to Requirement 6

Under PCI DSS 3.2.1, Requirement 6 was summarized as “Develop and maintain secure systems and applications.” In PCI DSS 4.0, the scope expands to “Develop and maintain secure systems and software,” with enhanced guidelines for:

• Patch Management
• Secure Coding
• Application Security Testing
• Script Integrity in E-commerce (a newly refined focus in 6.4.3)

Who Does Requirement 6 Affect?

• Merchants developing web apps, mobile apps, or embedded code that handle or influence payment flows.
• Service providers responsible for hosted solutions, APIs, or other software components processing cardholder data (CHD).
• Any organization that must patch, update, or maintain software in scope for PCI DSS compliance.

Goal of Requirement 6: Ensure vulnerabilities are promptly identified, remediated, and prevented throughout the lifecycle of systems and software that store, process, or transmit cardholder data.

‍

2. Why Secure Development and Maintenance Matters

A high percentage of breaches can be traced to unpatched vulnerabilities, insecure code, or third-party scripts. Attackers often exploit:

• Zero-day threats: Targeting unpatched OSes, frameworks, or open-source libraries.
• Injection flaws: Poor coding practices leading to SQL or script injection.
• Magecart-style attacks: Malicious scripts injected into e-commerce payment pages.
• Outdated software: EOL systems or frameworks with no vendor patches.

Robust secure SDLC and timely patching drastically reduce exploit opportunities.

‍

3. Key Elements of Requirement 6

PCI DSS 4.0 breaks Requirement 6 into several sub-requirements, but the major themes include:

3.1 Secure SDLC (Software Development Lifecycle)

• Developer Training: Teach secure coding principles (e.g., OWASP Top 10, SANS 25).
• Threat Modeling & Code Reviews: Identify potential vulnerabilities early and fix them before production.
• Automated Testing: Integrate Static (SAST) and Dynamic (DAST) analysis into build pipelines.

Pro Tip: Shift Left by incorporating security checks in development to catch issues before they reach QA or production.

3.2 Patch Management & Vulnerability Remediation

• Inventory All Components: Operating systems, frameworks, libraries, containers—everything must be tracked.
• Critical vs. Routine Patches: Apply critical patches within one month (as PCI DSS typically advises for high/critical vulnerabilities).
• Ongoing Vulnerability Assessments: Regular scanning (internal & external) to catch missed or newly discovered issues.

Reminder: This also ties closely to Requirement 11 (test security), ensuring you verify that patched systems no longer carry vulnerabilities.

3.3 New Emphasis on Payment Page Scripts (6.4.3)

PCI DSS 4.0 introduces Requirement 6.4.3, which focuses on managing scripts that execute in the consumer’s browser:

• Script Authorization: Every third-party or custom script running on the payment page must be approved and documented.
• Script Integrity Controls: Implement a method (like subresource integrity hashes, file integrity monitoring, or script management solutions) to ensure scripts haven’t been tampered with.
• Script Inventory: Maintain a list of all scripts, including the business or technical justification for each.
• Effective Date: These new controls become fully enforced by 31 March 2025.

Note: These requirements (6.4.3 and 11.6.1) were removed from the new SAQ A version for merchants who fully outsource payment pages and do not store/process/transmit card data electronically onsite. However, the core PCI DSS standard itself has not removed them—organizations in other SAQs or needing full compliance must address script integrity.

Why It Matters: Attackers frequently inject malicious code (e.g., Magecart) to skim card data in real time. Monitoring script usage and verifying their integrity can prevent these attacks.

‍

4. EOL Software Considerations

End-of-life (EOL) software or frameworks pose a direct threat to secure development because:

• No Vendor Patches: Leaves known code vulnerabilities open indefinitely.
• Incompatibility with Modern Libraries: Hard to integrate the latest security features if your platform no longer receives updates.
• Compliance Gaps: PCI DSS mandates actively supported systems under Requirements 5, 6, and more.

Mitigation Strategies

1. Inventory & Roadmap: Track all frameworks (e.g., .NET, Java, Python) and plan upgrades before EOL.
2. Temporary Controls: If upgrade can’t happen immediately, segment outdated systems to reduce scope.
3. HeroDevs Modernization: Partner with experts to refactor or migrate EOL codebases to actively supported versions that meet PCI DSS.

‍

5. Real-World Examples of Software-Related Breaches

Example 1: Unpatched Framework

A retailer’s e-commerce platform used an old version of Struts. Attackers exploited a known RCE (remote code execution) bug to steal cardholder data.
Lesson: Immediate patching of high-severity issues could have prevented lateral movement and data exfiltration.

Example 2: Magecart Injection

An online storefront loaded third-party analytics scripts without integrity checks. Attackers injected malicious JavaScript, skimming live payment data from the checkout page.
Lesson: Requirement 6.4.3 helps address this by authorizing scripts and verifying their integrity.

‍

6. Ongoing Monitoring and Validation

Maintaining a secure software environment means:

1. Continuous Scanning: Integrate vulnerability scans into CI/CD pipelines.
2. Code Change Reviews: Mandate peer reviews and/or automated checks for security impacts.
3. Penetration Testing: Go beyond standard checks—annual (or more frequent) tests targeting your custom apps and scripts.

Pro Tip: Monitor logs for suspicious script load events or network calls that deviate from normal usage.

‍

7. How HeroDevs Supports Secure Development

HeroDevs specializes in modernizing legacy applications and ensuring your DevSecOps practices align with PCI DSS 4.0:

1. Refactor EOL Frameworks: Migrate apps to actively supported versions (e.g., .NET 6, modern Node.js, or current Java LTS).
2. Automate Security Testing: Integrate SAST/DAST tools into your CI/CD, enforce secure coding standards, and set up compliance dashboards.
3. Script Integrity Solutions: Implement subresource integrity, script whitelisting, or tamper-detection for e-commerce pages.
4. Ongoing Compliance Coaching: Provide guidance on how to document processes, manage patch cycles, and keep script inventories current.

‍

8. Key Takeaways and Next Steps

1. Adopt a Secure SDLC: Incorporate code reviews, threat modeling, and automated scans early in development.
2. Patch Promptly: Many breaches result from slow patching. Classify and remediate vulnerabilities within set timelines.
3. Manage Scripts in the Browser: Requirement 6.4.3 demands authorization, integrity checks, and inventory for all payment-page scripts.
4. Replace EOL Software: Unsupported platforms block you from current security features and patch updates.
5. Monitor Continuously: Keep scanning, testing, and reviewing logs to detect new threats or code changes that might reintroduce vulnerabilities.

Looking Ahead: By proactively securing your software—including script management and patch workflows—Requirement 6 becomes less of a compliance checkbox and more a core business advantage, safeguarding you from data breaches and future-proofing your PCI posture.

‍

9. Frequently Asked Questions (FAQs)

Q1. What’s the big change in Requirement 6.4.3 for e-commerce scripts?

PCI DSS 4.0 adds a script management mandate: you must authorize each script that loads on the payment page, ensure script integrity, and maintain an inventory with justification. This addresses Magecart-like attacks.

Q2. Are these new script requirements removed from SAQ A forever?

Not exactly. The new SAQ A (published January 2025) removes 6.4.3 (and 11.6.1) only for merchants who fully outsource payments and meet specific criteria (no e-comm system susceptibility to scripts). The underlying PCI DSS requirements still stand if you’re not in that narrow SAQ A scenario.

Q3. Must we apply secure SDLC processes to every application in our company?

PCI focuses on systems in scope, i.e., those storing/transmitting CHD or affecting security. However, best practice is to adopt a secure SDLC for all software. Inadvertent data flows or cross-system dependencies can drag “non-financial” apps into scope.

Q4. How soon should patches be applied under PCI DSS?

The standard suggests 30 days for critical or high-severity issues, but your internal policy might be faster. Document any exceptions or compensating controls if you need more time.

Q5. Can an e-commerce site rely solely on third-party “script scanning” tools for compliance with 6.4.3?

Tools can help identify and track scripts, but PCI DSS requires an authorized process plus written justification. Automated scanning is great, but you still need a formal approval workflow and tamper-detection or subresource integrity to meet the integrity aspect.

‍

Conclusion

PCI DSS 4.0 Requirement 6 underscores the importance of secure coding, robust patch management, and managing scripts in e-commerce environments to prevent modern web-based attacks. By keeping software up to date, verifying all scripts, and enforcing a structured secure SDLC, you mitigate risks from both unknown zero-days and long-known vulnerabilities.

If you’re juggling end-of-life frameworks or struggling to implement script authorization processes, HeroDevs can help you refactor, upgrade, and automate your path to continuous compliance—ensuring your applications stay secure and your business remains ahead of evolving threats.