PCI DSS does not name SAST, DAST or API testing as mandatory tools. It requires outcomes: secure development, managed vulnerabilities, protected public web applications, regular scans and penetration tests. SAST covers source code, DAST covers the running application, and API testing covers the interfaces that carry cardholder data. Together they produce evidence for several requirements.
What does PCI DSS actually require here?
The PCI Security Standards Council describes PCI DSS as a baseline of technical and operational requirements designed to protect payment account data. The software relevant parts sit mainly in Requirement 6, which covers developing and maintaining secure systems and software, and Requirement 11, which covers testing security regularly.
A caution on sources. The council gates its document library behind an acceptance step, and we could not fetch the v4.0.1 text for this post, so we describe the requirements by theme and give no requirement numbers. Confirm the exact wording and numbering in the version your assessor uses. Your Qualified Security Assessor decides what counts as evidence.
Where does SAST fit?
Static analysis reads source code without running it. OWASP says it can find well-known flaws such as buffer overflows and SQL injection, and points to the exact file and line, which helps developers fix them. Its weaknesses are just as clear in the same OWASP page: it finds only a limited share of flaws, produces many false positives, struggles with authentication and access control problems, and cannot see configuration that is not in the code.
For PCI, SAST supports the expectation that bespoke and custom software is developed securely and reviewed before release, and that common coding flaws are addressed.
Where does DAST fit?
Dynamic testing probes the running application from outside. OWASP notes DAST tools do not need source code or knowledge of the framework, can run from a nightly scan once set up, and cover both client and server side. It sees what SAST cannot: deployed configuration, headers, session handling and how components behave together.
It supports the expectation that public-facing web applications are protected against known attacks, and it can feed quarterly vulnerability scanning and the application-layer parts of penetration testing. It does not replace the human tester.
Why does API testing need its own line?
Payment flows increasingly run through APIs rather than pages. The OWASP API Security Top 10 for 2023 starts with Broken Object Level Authorization, then Broken Authentication, Broken Object Property Level Authorization and Unrestricted Resource Consumption, and also includes Improper Inventory Management. Many of these are authorization logic flaws, which scanners find poorly. Testing needs real accounts, real roles and a current inventory of every endpoint, including old versions.
What does a gap look like?
Constructed example: a merchant scans its checkout site with DAST every night and passes. A mobile app calls a separate orders API where changing an order number returns another customer's order. The web scanner never touched that API, and static analysis could not tell that the authorization check was missing. A tester with two accounts finds it in minutes. Each tool was fine and the coverage had a hole.
How to check or apply this
- Draw the cardholder data environment and list every application and API inside or connected to it.
- Run SAST on bespoke code in the pipeline, and block merges on high-confidence findings.
- Inventory third-party components, since vulnerable dependencies are in scope of secure development. Safeguard's SBOM and dependency scanning and reachability analysis cover this part.
- Run DAST against staging on every release and against production on a schedule agreed with your assessor.
- Keep an API inventory and test authorization with at least two roles and two tenants.
- Schedule penetration tests by humans, and after significant changes.
- Store reports, tickets and retest results as evidence, and tie each to a requirement number.
- Ask your assessor early which evidence formats they accept.
Quick check
Does PCI DSS require SAST and DAST by name?
No. It sets outcomes for secure development, vulnerability management, web application protection and testing. Tools are one way to produce evidence.
Can automated scans replace penetration testing?
No. Scans find known patterns at scale. Penetration testing adds human reasoning about logic and authorization, and PCI DSS treats it as a separate activity.
Sources
- PCI Security Standards Council, PCI Data Security Standard
- OWASP, Source Code Analysis Tools
- OWASP DevSecOps Guideline, Dynamic Application Security Testing
- OWASP API Security Top 10, 2023
Last reviewed: 18 October 2026.
