PCI DSS 4.0
Req 6: Secure Systems and Software

PCI DSS 4.0 6.2.4: 6.2.4 Engineering techniques against common software attacks

Developers of bespoke and custom software must have defined and actually use software engineering techniques or other methods that prevent or reduce common software attacks and associated vulnerabilities, including at least: injection attacks (SQL, LDAP, XPath, plus command, parameter, object, fault and similar injection flaws); attacks against data structures and data, for example manipulation of pointers, buffers, shared data or input data; attacks on the use of cryptography, such as exploiting weak, insecure or unsuitable implementations, algorithms, cipher suites or operating modes; business logic attacks that abuse or bypass application features through tampering with APIs, protocols, communication channels, client-side functions or other system resources, including XSS and CSRF; attacks on access control mechanisms, such as bypassing or abusing identification, authentication or authorization, or exploiting weak implementations of them; and attacks through any high-risk vulnerability found by the Requirement 6.3.1 process. It applies to all entities. Applicability: covers all software built by or for the entity for its own use, bespoke and custom; third-party software is not covered. Objective under the customized approach: common attacks and related weaknesses cannot be used to exploit bespoke and custom software.

Maintained by Gerard BlokdykControl text last updated

What else in your programme already covers this

This control maps to 54 controls across 18 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.

CIS Controls v8 · 6 controls

  • CIS-16.10 Apply Secure Design Principles in Application Architectures
  • CIS-16.11 Leverage Vetted Modules or Services for Application Security Components
  • CIS-16.12 Implement Code-Level Security Checks
  • CIS-16.13 Conduct Application Penetration Testing
  • CIS-16.14 Conduct Threat Modeling
  • CIS-16.9 Train Developers in Application Security Concepts and Secure Coding

FedRAMP High · 5 controls

  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))
  • SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses (SA-11(2))
  • SA-15 Development Process, Standards, and Tools (SA-15)
  • SA-8 Security and Privacy Engineering Principles
  • SI-10 Information Input Validation

FedRAMP Moderate · 5 controls

  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))
  • SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses (SA-11(2))
  • SA-15 Development Process, Standards, and Tools (SA-15)
  • SA-8 Security and Privacy Engineering Principles
  • SI-10 Information Input Validation

ISO 27001:2022 · 5 controls

  • 8.25 Secure development life cycle
  • 8.26 Application security requirements
  • 8.27 Secure system architecture and engineering principles
  • 8.28 Secure coding
  • 8.29 Security testing in development and acceptance

ISO 27002:2022 · 5 controls

  • 8.25 Secure development life cycle
  • 8.26 Application security requirements
  • 8.27 Secure system architecture and engineering principles
  • 8.28 Secure coding
  • 8.29 Security testing in development and acceptance

SOC 2 · 5 controls

  • SOC2-CC5.1 CC5.1 Selecting control activities that mitigate risk (COSO principle 10)
  • SOC2-CC5.2 CC5.2 General controls over technology (COSO principle 11)
  • SOC2-CC6.8 CC6.8 Preventing and detecting unauthorised or malicious software
  • SOC2-CC7.1 CC7.1 Detecting configuration changes and new vulnerabilities
  • SOC2-CC8.1 CC8.1 Managing changes to procedures, software, data and infrastructure

NIST SP 800-53 Rev 5 · 4 controls

ISO 27701:2019 · 3 controls

  • 6.11 Systems acquisition, development and maintenance
  • 6.11.1 Security requirements of information systems
  • 6.11.2 Security in development and support processes
  • SEC11-BP01 Train for application security
  • SEC11-BP02 Automate testing throughout the development and release lifecycle
  • ASBv3-DS-4 Integrate static application security testing into DevOps pipeline
  • ASBv3-IM-8 Restrict the exposure of credential and secrets

C5 (Germany) · 2 controls

  • C5-DEV-04 Safety training and awareness programme regarding continuous software delivery and associated systems, components or tools
  • C5-PSS-04 Error handling and Logging Mechanisms

CMMC 2.0 · 2 controls

  • CCM-AIS-02 Application Security Baseline Requirements
  • CCM-AIS-04 Secure Application Design and Development
  • P1-3.1.3 P1-3.1.3 Development procedures address common coding weaknesses
  • P2-3.4.5 P2-3.4.5 Native framework protections enabled
  • AUCDR-IS-4 Formal vulnerability management program
  • NIST-CSF-PR.PS-06 Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle
  • 03.16.01 Security Engineering Principles

NIST SP 800-218 · 1 control

Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.

Other controls in Req 6: Secure Systems and Software

You are reading one control. How much of PCI DSS 4.0 have you already done?

PCI DSS 4.0 6.2.4 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of PCI DSS 4.0 your existing evidence covers. Hold ISO 27001:2022 and 139 of 280 PCI DSS 4.0 controls already carry evidence.

Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 415 were rejected on the ISO 27001:2022 pair alone.

Query this from an agent

The graph holds this control, the 54 it maps to, and the evidence behind each claim, over MCP and REST.