Pre-Production Code Tests: PCI DSS for Developers

Annual code review is dead for serious payment software.

If your team waits until the yearly penetration test to discover insecure checkout code, vulnerable open-source packages, exposed secrets, or broken API authorization, the pipeline is already too late. Modern payment engineering needs security validation before code reaches production.

For DevOps engineers, AppSec architects, Engineering VPs, and release managers, PCI DSS for developers now means building secure testing directly into CI/CD. Static Application Security Testing, Dynamic Application Security Testing, Software Composition Analysis, dependency tracking, SBOM generation, peer review, and release gates must become part of the delivery workflow, not a manual compliance activity at the end.

PCI DSS v4.0.1 Requirement 6 places strong expectations on secure software development, bespoke and custom software review, vulnerability management, and software component tracking. The official PCI DSS standards page and the PCI SSC Document Library remain the primary references for developers, QSAs, merchants, and service providers working with payment security requirements.

Professional note: This guide is for compliance education only. Always confirm Requirement 6 interpretation, vulnerability timelines, custom software inventory, and ROC evidence expectations with your QSA, acquirer, payment brand, and internal security leadership.

Why Annual Code Review Fails Modern PCI

A once-a-year code review cannot protect a weekly release cycle.

Payment platforms may deploy dozens of changes every month:

• Checkout API updates.

• Gateway SDK upgrades.

• GraphQL resolver changes.

• Payment webhook handlers.

• Tokenization logic.

• Fraud service integrations.

• Authentication middleware.

• Logging and observability changes.

• Frontend payment scripts.

• Third-party package updates.

• Infrastructure-as-code changes.

If security testing happens only during the annual audit, vulnerable code may already be running in production for months.

That is why PCI DSS v4.0.1 Requirement 6.2.3 matters. Bespoke and custom software must be reviewed before release into production or after significant changes. That review can include manual or automated methods, but it must be real, documented, and tied to the release workflow.

OWASP’s Secure Software Development Lifecycle Cheat Sheet and OWASP’s Code Review Guide are useful references for development teams building repeatable secure review practices.

Old Pattern vs PCI-Ready Pattern

A PCI-ready pipeline does not ask, “Did we test sometime this year?” It asks, “Did this release pass the required security gates before production?”

PCI DSS Requirement 6: What Developers Must Prove

Requirement 6 is where secure software development becomes audit evidence.

For developers and AppSec teams, the key proof points include:

The QSA will not only ask whether tools exist. They will ask whether tool results block risky releases and whether exceptions are justified.

For broader application security control planning, OWASP’s Application Security Verification Standard can help teams map security requirements into testable engineering controls.

The Open-Source Dependency Risk

Modern payment applications are not written from scratch.

A checkout API may include hundreds of direct and transitive dependencies from npm, pip, Maven, NuGet, Composer, RubyGems, or container images. One vulnerable package can expose authentication, payment workflows, cryptography, logging, serialization, or admin interfaces.

This is where Software Composition Analysis, or SCA, becomes essential.

SCA tools should identify:

• Direct dependencies.

• Transitive dependencies.

• Vulnerable package versions.

• Known CVEs.

• License risk.

• Abandoned packages.

• Malicious packages.

• Deprecated libraries.

• Container image packages.

• Framework versions.

• Cryptographic library versions.

CISA’s SBOM guidance and resources explain why software bills of materials are important for software supply-chain transparency. NIST’s National Vulnerability Database is also a key public reference for tracking CVEs and vulnerability metadata.

For PCI teams, SCA is not optional hygiene. It supports the requirement to identify and manage vulnerabilities in software components.

Requirement 6.3.2: Custom Software and Component Inventory

PCI DSS Requirement 6.3.2 requires organizations to maintain an inventory of bespoke and custom software, plus third-party software components incorporated into that software.

That means your team must know what is actually running in production.

A proper inventory should include:

Shadow APIs and undocumented modules are serious audit risks because they cannot be assessed, scanned, patched, or defended.

If a payment-related service is running in production but missing from the inventory, the audit question becomes obvious: how can the organization prove it is secure?

SBOM Compliance: The Release-Level Evidence Layer

A Software Bill of Materials, or SBOM, gives security and compliance teams a machine-readable list of software components.

For payment software, an SBOM should be generated for every production release, not only once a year.

A release SBOM should capture:

• Package names.

• Package versions.

• Dependency relationships.

• Transitive dependencies.

• Container base images.

• Open-source licenses.

• Component hashes.

• Vulnerability references.

• Build metadata.

• Release version.

• Repository and commit ID.

Common SBOM formats include SPDX and CycloneDX. The SPDX specification and the CycloneDX project are widely used references for structuring SBOM data.

SBOM Operating Rule

No production payment release should exist without a matching SBOM artifact.

This makes vulnerability response faster. When a new critical CVE appears, the team can search SBOMs and know which payment services are affected.

Critical Vulnerability Remediation Timeline

PCI DSS v4.0.1 requires organizations to address vulnerabilities based on risk ranking, and critical/high security patches have strict timelines.

For PCI operations, a safe rule is:

The brief’s 30-day rule is most defensible for critical and high-risk vulnerabilities where PCI patching expectations apply. Medium-severity issues normally follow the organization’s risk framework, QSA expectations, and internal remediation policy.

The NVD CVSS calculator can help teams understand severity scoring, but PCI remediation decisions should also consider exploitability, payment-scope exposure, compensating controls, and QSA expectations.

Do not allow “we will fix it next sprint” to become an undocumented risk acceptance.

Architecting a Gate-Driven CI/CD Pipeline

A gate-driven pipeline prevents risky code from moving forward.

Instead of relying on humans to remember every compliance step, the pipeline enforces security checks automatically.

PCI-Ready CI/CD Gate Map

The best pipelines make secure behavior the easiest behavior. GitHub’s documentation for code scanning and Dependabot alerts shows how teams can automate vulnerability and code-quality checks directly in repository workflows.

Step 1: Run Localized SAST and Linter Quality Checks

The first gate should run as close to the developer as possible.

When a developer commits code to a feature branch, the pipeline should execute Static Application Security Testing and security linting.

SAST should detect:

• SQL injection.

• Command injection.

• Server-side request forgery.

• Insecure deserialization.

• Hardcoded credentials.

• Broken authorization checks.

• Unsafe cryptographic use.

• Sensitive logging.

• Path traversal.

• Unsafe XML parsing.

• Insecure payment payload handling.

Security linters should also enforce coding standards:

OWASP’s Source Code Analysis Tools page provides useful background on SAST tooling approaches, while SonarQube documentation can help teams understand quality gates and code-analysis workflows.

SAST is not perfect. It produces false positives and misses logic flaws. But it is the first automated safety net.

Step 2: Execute Software Composition Analysis

After code checks, scan the dependency graph.

SCA should analyze:

• Application packages.

• Lockfiles.

• Transitive dependencies.

• Container image packages.

• Base images.

• Build tools.

• Runtime libraries.

• Gateway SDKs.

• Authentication libraries.

• Cryptographic packages.

A strong SCA workflow should:

1. Generate a dependency inventory.

2. Generate or update the SBOM.

3. Match packages against vulnerability databases.

4. Detect critical and high vulnerabilities.

5. Check whether fixed versions exist.

6. Block release where policy requires.

7. Open remediation tickets automatically.

8. Store the report as release evidence.

Dependency Gate Rules

Tools such as OWASP Dependency-Check help detect publicly known vulnerabilities in project dependencies. Teams using containers should also scan base images and runtime layers, not only application libraries.

SCA must understand context. A vulnerable package in the payment runtime is different from a dev-only package that never ships.

Step 3: Trigger Automated DAST in a Sandbox

SAST reads code. DAST attacks the running application.

Dynamic Application Security Testing should run against an isolated staging environment that resembles production enough to test real behavior safely.

DAST should cover:

• Checkout APIs.

• Authentication flows.

• Payment token endpoints.

• Webhook handlers.

• GraphQL queries.

• REST endpoints.

• Session management.

• Input validation.

• Error handling.

• Security headers.

• Access control checks.

• Tenant isolation.

OWASP’s ZAP project is a widely used DAST tool that can support automated web application security testing in CI/CD workflows. Teams should configure DAST carefully so scans are safe, repeatable, and scoped to approved staging environments.

A DAST staging run should not use real cardholder data. Use test tokens, sandbox gateways, synthetic users, and payment-provider test cards.

DAST Gate Questions

If DAST finds a critical payment-path flaw, the release should stop.

Step 4: Enforce Mandatory Peer Code Review and Sign-Off

Automation cannot replace human judgment.

Peer review should focus on logic, business impact, and payment-specific risks that tools may miss.

A payment-code review should verify:

OWASP’s Secure Code Review Guide is a useful reference for structuring secure peer review and identifying flaws that automated scanners may miss.

A strong peer review includes named reviewers, comments, approvals, and linked security findings.

Step 5: Build the Production Release Evidence Pack

Every production release affecting payment systems should generate an evidence pack automatically.

The pack should include:

• Commit hash.

• Pull request link.

• Change ticket.

• SAST report.

• SCA report.

• SBOM.

• Container scan report.

• DAST report.

• Peer review approval.

• AppSec approval where required.

• Open findings list.

• Exception approvals.

• Deployment timestamp.

• Rollback plan.

• Production monitoring confirmation.

This turns the CI/CD pipeline into a PCI evidence machine.

Build-Breaker Rules for Payment Pipelines

A build-breaker rule defines when a release must stop.

Recommended Build-Breaker Matrix

Build breakers should be written into policy and enforced through CI/CD, not negotiated manually during deadline pressure.

Managing False Positives and Code Exceptions

False positives happen. But undocumented false positives become audit gaps.

A valid exception record should include:

A QSA will not accept “the scanner is noisy” as evidence. The team must show structured review.

Tracking Bespoke Software Inventory for an Annual ROC

For ROC preparation, maintain a live inventory of all bespoke and custom software.

Include:

• Application name.

• API name.

• Repository.

• Runtime.

• Owner.

• Business function.

• Payment impact.

• CDE relationship.

• Production URL or service endpoint.

• Dependency inventory.

• SBOM location.

• Last release date.

• Last SAST date.

• Last DAST date.

• Last SCA date.

• Open vulnerability status.

• Exception status.

Shadow API Control

Shadow APIs are dangerous because they usually skip:

• Authentication review.

• Logging review.

• SAST.

• DAST.

• SCA.

• SBOM tracking.

• PCI scope review.

• Change control.

Use API discovery, gateway inventories, cloud service discovery, and repository scanning to identify undocumented services.

OWASP’s API Security Top 10 is a strong reference for understanding common API risks such as broken object-level authorization, weak authentication, and unsafe API exposure.

Secure SDLC Deployment Lifecycle

The definitive pipeline sequence should look like this:

This lifecycle should run every time payment-impacting code changes.

Why Training Matters for Developers

Secure pipeline automation touches many teams.

Developers write code. DevOps builds the pipeline. AppSec tunes SAST and DAST. Security engineers define build breakers. Product owners approve releases. Compliance teams defend evidence to the QSA. Engineering leaders decide how much release risk is acceptable.

A specialized course such as PCI DSS For Developers — Secure Payment Integrations helps these groups understand PCI DSS for developers through practical release engineering: SAST, DAST, SCA, SBOM generation, custom software inventory, vulnerability remediation, exception handling, and secure SDLC evidence.

The goal is not to slow delivery. The goal is to make unsafe delivery impossible.

Conclusion

Treating secure coding rules as an afterthought creates unstable codebases, audit panic, and preventable payment security failures.

Strong PCI DSS for developers means moving security into the pipeline itself. Every payment release should pass SAST, SCA, SBOM generation, container scanning, DAST, peer review, and documented security sign-off before production deployment.

Integrating automated testing directly into your deployment pipelines through PCI DSS For Developers — Secure Payment Integrations delivers stable, secure, and compliant payment features at scale.

FAQs

Does the 30-day remediation mandate apply to medium-severity software vulnerabilities under v4.0.1 instructions?

Usually, the strict one-month remediation expectation is associated with critical and high-risk security patches or vulnerabilities under PCI vulnerability management rules. Medium vulnerabilities should still be tracked and remediated according to the organization’s risk-ranking process, internal SLA, QSA expectations, and exposure context.

How must a development team document code exceptions or false positives to pass a QSA platform review?

The team should maintain a formal exception record showing the finding ID, affected component, severity, reason for exception, technical evidence, compensating controls, owner, approval, expiry date, and retest plan. False positives should be supported by code evidence or tool analysis, not informal comments.