6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel
Defined Approach Requirements
6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:
- Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
- Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.
- Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.
- Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
- Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.
- Attacks via any "high-risk" vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.
Defined Approach Testing Procedures
6.2.4 Examine documented procedures and interview responsible software development personnel to verify that software engineering techniques or other methods are defined and in use by developers of bespoke and custom software to prevent or mitigate all common software attacks as specified in this requirement.
Purpose
Detecting or preventing common errors that result in vulnerable code as early as possible in the software development process lowers the probability that such errors make it through to production and lead to a compromise. Having formal engineering techniques and tools embedded in the development process will catch these errors early. This philosophy is sometimes called "shifting security left."
Good Practice
For both bespoke and custom software, the entity must ensure that code is developed focusing on the prevention or mitigation of common software attacks, including:
- Attempts to exploit common coding vulnerabilities (bugs).
- Attempts to exploit software design flaws.
- Attempts to exploit implementation/configuration flaws.
- Enumeration attacks – automated attacks that are actively exploited in payments and abuse identification, authentication, or authorization mechanisms. See the PCI Perspectives blog article "Beware of Account Testing Attacks." (continued on next page)
Customized Approach Objective
Bespoke and custom software cannot be exploited via common attacks and related vulnerabilities.
Applicability Notes
This applies to all software developed for or by the entity for the entity's own use. This includes both bespoke and custom software. This does not apply to third-party software.
Examples
Techniques include automated processes and practices that scan code early in the development cycle when code is checked in to confirm the vulnerabilities are not present.
Researching and documenting software engineering techniques or other methods helps to define how software developers prevent or mitigate various software attacks by features or countermeasures they build into software. This might include identification/authentication mechanisms, access control, input validation routines, etc. Developers should be familiar with different types of vulnerabilities and potential attacks and use measures to avoid potential attack vectors when developing code.
purpose
Install critical security patches/updates within one month of release.
compliance strategies
- Automated patch deployment
- Patch tracking
typical policies
- Patch Management Policy
common pitfalls
- Delayed patching
- Missed critical updates
type
Technical Control
difficulty
Moderate
key risks
- Exploitation of known vulnerabilities
recommendations
- Automate patch deployment and alerting
Eligible SAQ
- SAQ-A-EP
- SAQ-C
- SAQ-D MERCHANT
- SAQ-D SERVICE PROVIDER
Your perspective on this PCI DSS requirement matters! Share your implementation experiences, challenges, or questions below. Your insights help other organizations improve their compliance journey and build a stronger security community.Comment Policy