PCI-DSS for Developers: What Your Code Must Satisfy

The Payment Card Industry Data Security Standard (PCI-DSS) is a set of security requirements for organizations that handle credit card data. Maintained by the PCI Security Standards Council (a body formed by American Express, Discover, JCB, Mastercard, and Visa), PCI-DSS applies to any organization that stores, processes, or transmits cardholder data — including merchants, payment processors, and software vendors whose applications touch payment flows.

PCI-DSS v4.0, effective since March 2022 (with v3.2.1 sunset in March 2024), organizes requirements into twelve domains. For development teams, the most directly relevant are:

• Requirement 6: Develop and Maintain Secure Systems and Software — mandates secure development practices, vulnerability management, and code review
• Requirement 3: Protect Stored Account Data — governs encryption and handling of cardholder data at rest
• Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission — mandates TLS 1.2+ for all transmissions
• Requirement 2: Apply Secure Configurations to All System Components — covers default credentials and unnecessary services

Non-compliance can result in fines from $5,000 to $100,000 per month, card scheme penalties, increased transaction fees, and loss of the ability to process card payments. For software vendors, a breach in a non-compliant application can trigger liability for the full breach response cost.

PCI-DSS Requirement 6 is the most code-centric requirement. It mandates that organizations protect systems and applications from known vulnerabilities and follow secure development practices. In PCI-DSS v4.0, the key sub-requirements for development teams are:

6.2 — Bespoke and Custom Software

• 6.2.2: All personnel developing bespoke software are trained in secure development practices at least once per year, including the OWASP Top 10 and techniques for preventing common vulnerabilities
• 6.2.3: Bespoke and custom software is reviewed prior to production release to identify and remediate potential vulnerabilities — including manual and automated code reviews
• 6.2.4: Software engineering techniques are defined and in use to prevent or mitigate common software attacks, including injection attacks, attacks on data and data structures, attacks on cryptography usage, attacks on business logic, attacks on access controls

6.3 — Security Vulnerabilities Identified and Addressed

• 6.3.2: An inventory of bespoke and custom software is maintained to facilitate vulnerability management and patching
• 6.3.3: All software components are protected from known vulnerabilities by installing applicable security patches

6.4 — Public-Facing Web Applications

• 6.4.1: Public-facing web applications are protected against attacks by deploying an automated technical solution that continually detects and prevents web-based attacks
• 6.4.2: An automated technical solution is deployed for public-facing web applications that continually detects and prevents web-based attacks

Requirements 6.4.1 and 6.4.2 are frequently satisfied by SAST tools that run on every pull request — providing continuous, automated detection documented for auditors.

PCI-DSS Requirement 6.2.4 explicitly references the OWASP Top 10 as the vulnerability taxonomy developers must understand and prevent. The two standards align closely:

Injection (OWASP A03 / PCI Req 6.2.4)

SQL injection in a payment application can expose cardholder data directly. PCI-DSS requires prevention of injection attacks. Parameterized queries, ORM usage, and SAST scanning satisfy this requirement with documented evidence.

Broken Access Control (OWASP A01 / PCI Req 6.2.4)

Unauthorized access to cardholder data through IDOR vulnerabilities, path traversal, or missing authorization checks violates PCI-DSS Requirement 3 (protect stored data) and Requirement 6 (secure systems). Access control checks must be in both the code and the test suite.

Cryptographic Failures (OWASP A02 / PCI Req 3 and 4)

PCI-DSS Requirement 3 prohibits storing PANs (Primary Account Numbers) in cleartext. Requirement 4 mandates TLS 1.2+ for transmission. SAST checks for hardcoded keys, weak algorithms (MD5, SHA-1), and HTTP instead of HTTPS directly satisfy these requirements.

Vulnerable Components (OWASP A06 / PCI Req 6.3.3)

PCI-DSS Requirement 6.3.3 mandates that all software components are protected from known vulnerabilities. Dependency scanning against CVE databases is the primary mechanism, and the scan reports serve as audit evidence.

These specific coding practices satisfy PCI-DSS Requirement 6 and can be demonstrated to auditors through SAST reports:

Parameterized queries (Req 6.2.4)

// COMPLIANT: Parameterized query — no injection risk
const result = await db.query(
  'SELECT * FROM payments WHERE card_id = $1',
  [req.params.cardId]
);

// NON-COMPLIANT: String concatenation — SQL injection risk
const result = await db.query(
  'SELECT * FROM payments WHERE card_id = ' + req.params.cardId
);

Strong cryptography for cardholder data (Req 3 and 4)

# NON-COMPLIANT: MD5 is weak — not PCI compliant
pan_hash = hashlib.md5(pan.encode()).hexdigest()

# COMPLIANT: AES-256 encryption for stored PANs
from Crypto.Cipher import AES
import os
key = os.environ['PCI_ENCRYPTION_KEY']
cipher = AES.new(key.encode(), AES.MODE_GCM)
ciphertext, tag = cipher.encrypt_and_digest(pan.encode())

Secrets out of source code (Req 6.2.4)

# NON-COMPLIANT: Hardcoded API key — fails PCI Req 6 and Req 8
STRIPE_KEY = "sk_live_abc123..."

# COMPLIANT: Environment variable injection
import os
stripe_key = os.environ['STRIPE_SECRET_KEY']

PCI-DSS v4.0 Requirement 6.4.2 mandates an "automated technical solution" for public-facing web applications. SAST running on every pull request satisfies this requirement and generates audit evidence:

• Continuous scanning: Every code change is analyzed before it can reach production — satisfying "continually detects and prevents web-based attacks" (Req 6.4.2)
• Documented findings: SARIF reports uploaded to GitHub Security Tab create a timestamped audit trail of identified vulnerabilities and their resolution status
• OWASP Top 10 mapping: Findings tagged with OWASP categories directly map to PCI-DSS Requirement 6.2.4's reference to OWASP
• Dependency scanning: CVE-matched dependency findings with remediation timestamps satisfy Requirement 6.3.3

CodeSlick provides 308 security checks across JavaScript, TypeScript, Python, Java, and Go with OWASP Top 10 mapping, CVSS severity scoring, and SARIF export. The GitHub App runs automatically on every pull request, generating documented evidence that satisfies PCI-DSS v4.0 Requirements 6.2.4 and 6.4.2.