You can't just patch your way out of software risk. By the time a CVE hits your inbox, the vulnerability has been sitting in your code for months, maybe even years. If your security program still treats vulnerability management as a reactive cycle of scan-patch-repeat, you're using an outdated model.
This checklist outlines controls to shift vulnerability prevention upstream, before code reaches production and before attackers find what your scanners missed.
What This Checklist Covers
This isn't a penetration testing checklist or a patch management workflow. It's a set of preventive controls designed to reduce the attack surface of payment applications and Cardholder Data Environment (CDE) components before vulnerabilities become exploitable. Each item maps to a specific stage in your software development lifecycle where you can eliminate entire classes of risk.
Use this when you're:
- Designing new payment applications or CDE-connected services
- Reviewing third-party payment integrations
- Building secure development standards under PCI DSS Requirement 6
- Establishing cryptographic key management workflows
Prerequisites
Before you start this checklist, confirm:
- You've documented your CDE scope and data flows (PCI DSS Requirement 1.2)
- You have an accurate inventory of all software components that store, process, or transmit cardholder data
- Your development teams know which repositories and build pipelines touch CDE systems
- You have access to Software Composition Analysis (SCA) tooling or a dependency tracking system
Checklist Items
1. Run SCA on every repository that touches cardholder data
Scan all application code, libraries, and dependencies for known vulnerabilities before deployment. SCA identifies outdated packages, licensing risks, and components with published CVEs.
Done when: Every CDE-connected repository has an automated SCA scan in the CI/CD pipeline, and you have a documented process for reviewing and remediating findings within 30 days, or immediately for critical vulnerabilities.
2. Enforce split knowledge for all Key Encryption Keys (KEK)
No single individual should have access to a complete KEK used to encrypt Data Encryption Keys (DEK). Split the key into at least two components, each held by separate custodians.
Done when: Your key ceremony documentation shows that KEK components are generated, stored, and combined only in a Hardware Security Module (HSM) or cryptographic appliance, and no single person can reconstruct the full key. Audit logs confirm that key operations require dual authorization.
3. Validate that PAN rendering happens before logs are written
If your application logs transaction data, rendering Primary Account Number (PAN) unreadable must occur before the log entry is created, not after. Otherwise, plaintext PAN will hit disk even if it's masked in the final log file.
Done when: Code review confirms that PAN truncation, hashing, or tokenization occurs in the data layer before any logging framework is invoked. Test this by inspecting raw log buffers and temporary files during a transaction.
4. Restrict Role-Based Access Control (RBAC) to least privilege for CDE access
Every user, service account, and API key that accesses CDE systems should have the minimum permissions required to perform its function. Over-permissioned accounts are a primary vector for lateral movement after initial compromise.
Done when: You can generate a report showing each CDE account's permissions, the business justification for those permissions, and the date of the last access review. No account has default "admin" or "root" access unless it's explicitly required and documented.
5. Require Multi-Factor Authentication (MFA) for all administrative access to CDE components
Administrative accounts are high-value targets. MFA adds a second layer of defense if credentials are compromised.
Done when: Every administrative session, including SSH, RDP, database consoles, and cloud management interfaces, requires MFA. You've disabled legacy single-factor authentication methods. Audit logs show MFA challenges for every admin login.
6. Map all third-party libraries to a vulnerability feed
Your SCA scan tells you what libraries you use. This step ensures you know when a new vulnerability is published against those libraries, even if you're not running a scan that day.
Done when: You've subscribed to CVE feeds or vulnerability databases (NVD, GitHub Security Advisories, vendor-specific feeds) and mapped them to your dependency inventory. You receive alerts within 24 hours of a new CVE affecting a library in your CDE.
7. Harden cryptographic implementations against side-channel attacks
Cryptographic libraries can leak information through timing, power consumption, or cache behavior. Use constant-time comparison functions and validated cryptographic modules.
Done when: Your cryptographic operations use FIPS 140-3 validated modules. Code review confirms that secret comparisons use constant-time functions, not standard string comparison. You've disabled or removed any custom cryptographic implementations.
8. Segment CDE systems to contain lateral movement
If an attacker compromises a single CDE component, network segmentation limits their ability to pivot to other systems.
Done when: You've implemented network controls (firewalls, VLANs, ACLs) that restrict traffic between CDE segments. You've tested segmentation by attempting to connect from one CDE segment to another without traversing the defined access controls. PCI DSS Requirement 1.3 is met.
9. Establish a secure key lifecycle for DEKs
Data Encryption Keys should be rotated regularly, retired when no longer needed, and never stored in plaintext.
Done when: You have documented key rotation schedules (at least annually, or when personnel with key access leave). DEKs are encrypted under a KEK before storage. You can demonstrate that retired keys are destroyed in accordance with NIST SP 800-88 guidelines.
10. Validate input at every trust boundary
Input validation prevents injection attacks (SQL, command, LDAP). This must happen at every point where data crosses a trust boundary, not just at the application's front door.
Done when: Code review shows that every API endpoint, database query, and system call that handles user input or external data applies validation rules. You've defined and documented what constitutes valid input for each field. Automated testing includes injection attack scenarios.
Common Mistakes
Treating SCA as a one-time scan. Vulnerabilities are published continuously. A clean scan today doesn't mean your dependencies are safe next month. Automate SCA in your CI/CD pipeline and subscribe to real-time feeds.
Logging before rendering PAN unreadable. This is one of the most common causes of Account Data Compromise (ADC). Developers assume that masking PAN in the final log output is sufficient, but plaintext often hits disk in buffer files or temporary storage.
Confusing encryption in transit with rendering PAN unreadable. Point-to-Point Encryption (P2PE) protects data during transmission. It doesn't satisfy PCI DSS requirements for rendering stored PAN unreadable. You need both.
Implementing MFA only at the perimeter. If your MFA challenge happens once at login and then grants a long-lived session, an attacker who steals the session token bypasses MFA entirely. Require re-authentication for high-risk actions (key access, configuration changes).
Assuming vendor libraries are secure by default. Third-party libraries are a major source of vulnerabilities. The fact that a library is widely used or comes from a reputable vendor doesn't mean it's free of CVEs. Validate every dependency.
Next Steps
Once you've completed this checklist:
- Schedule quarterly reviews of your SCA findings and dependency inventory
- Conduct annual penetration testing focused on the controls above (PCI DSS Requirement 11.4)
- Document exceptions where a control can't be fully implemented, along with compensating controls
- Train development teams on secure coding practices specific to payment systems (PCI DSS Requirement 6.5.3)
- Review your key management procedures whenever personnel with cryptographic access change roles
If you found gaps in items 6 through 10, prioritize those. Late-stage controls like segmentation and input validation are critical, but they're also your last line of defense. The earlier you prevent vulnerabilities, the less you rely on detection and containment.
