PCI Secure Software Lifecycle v1.1

Control Objectives:
3.1 Critical assets are identified and classified.
Test Requirements:
3.1 The assessor shall examine vendor evidence to confirm the following: 

Guidance:
Before the software vendor can determine how to effectively secure and defend its software against attacks, it must first develop a thorough understanding of the software’s critical assets that could be targeted by attackers. 
Critical assets include any sensitive data collected, stored, processed, or transmitted by the vendor’s software, as well as any sensitive functions and sensitive resources within or used by the software. Examples of analysis techniques that could be used to identify critical assets include, but are not limited to, Mission Impact Analysis (MIA), Functional Dependency Network Analysis (FDNA), and Mission Threat Analysis. 

Control Objectives:
3.2 Threats to the software and weaknesses within its design are continuously identified and assessed.
Test Requirements:
3.2.a The assessor shall examine vendor evidence, including process documentation and assessment results to confirm the following:

3.2.b Where open-source software components are utilized as part of the software, the assessor shall examine vendor evidence, including process documentation and assessment results to confirm these components are managed as follows: 

3.2.c For a sample of vendor software, the assessor shall examine assessment results for the selected software to confirm the following:

Guidance:
Determining how to effectively secure and defend software against attacks requires a thorough understanding of the specific threats and vulnerabilities applicable to the vendor’s software. 
This typically involves understanding: 

This information helps the software vendor to identify the threats and design flaws that present the most significant and immediate risk, and to prioritize remediation activities necessary to address them. 
Information regarding software threats can be obtained from a variety of sources, both external and internal. Examples of external sources include publications from organizations such as SANS, MITRE, and CERT that specialize in tracking common system vulnerabilities and attack techniques, or industry-specific sources that provide threat intelligence for specific sectors, such as FS-ISAC for the financial services industry and R-CISC for the retail industry. Other external sources of threat information and design weaknesses could include technology vendors, open-source user communities, industry publications, and academic papers. Internal sources could include reports from internal research and design teams, formal threat models, or actual activity data from internal security or operations teams. 

Where open-source software components are used, the software vendor should consider any risks associated with the use of the open-source components and the extent to which the open-source software provider manages the security of those components. Additionally, the software vendor will need to confirm that support—including up-to-date security patches—is available (whether provided by an internal or external entity) for the open-source component. The use of open-source components should be supported by a clear policy about how those components are evaluated and implemented. A reliable support system should be in place to identify errors or problems and evaluate and address them in a timely manner. 
Where vulnerabilities are identified in open-source components that are applicable to their software, software vendors should have processes in place to analyze those vulnerabilities and update the components to appropriate, non-vulnerable versions in a timely manner. When patches for open-source components are no longer available, those components should be replaced by actively supported ones. Vendors should identify and establish sources and processes for managing vulnerabilities in open-source components that are appropriate for their software design and release frequency.

Control Objectives:
3.3 Software security controls are implemented in the software to mitigate threats and design weaknesses.
Test Requirements:
3.3.a The assessor shall examine vendor evidence, including process documentation and software-specific threat and design information, to confirm the following: 

3.3.b The assessor shall examine evidence and interview personnel to confirm the following: 

3.3.c The assessor shall examine vendor evidence to confirm that security controls have been implemented to mitigate all identified threats and design flaws. 
Guidance:
To ensure that its software is resistant to attacks, software vendors must implement software-specific controls or countermeasures in their software to mitigate the specific threats and design weaknesses. Examples of such controls include the use of multi-factor authentication mechanisms to prevent unauthorized individuals gaining access to critical assets, and logging mechanisms to detect if and when authentication mechanisms might have been circumvented. Other examples include the use of input validation routines or parameterized queries to protect software from SQL-injection attacks. Except where specific software security controls and countermeasures are defined within this standard, it is up to the vendor to determine the most appropriate software security controls to implement. The specific controls used will be dependent on the software threats identified in Control Objective 3.2 as well as the software’s architecture, the software’s intended function, the data it handles, and the external resources it utilizes. 
Evidence to support this control objective may include softwarespecific requirements documentation, feature lists, security control inventories, change-management documentation, risk assessment reports, test results, or any other evidence or information that clearly and consistently illustrates that the software vendor implements and maintains security controls in software to address the risks to that software. 

Control Objectives:
3.4 Failures or weaknesses in software security controls are detected. Weak or ineffective security controls are updated, augmented or replaced.
Test Requirements:
3.4.a The assessor shall examine vendor evidence and interview personnel to confirm the following: 

3.4.b The assessor shall examine vendor evidence, including software-specific data or test results, and details of software-specific updates to confirm the following: 

Guidance:
Vendors should monitor and/or routinely test their software to confirm that implemented software security controls remain appropriate (i.e., fit for purpose) and effective for sufficiently mitigating evolving risks or design flaws. For example, a software-specific security requirement may call for cryptography to be used to protect software communications. While the use of SSL may have been sufficient upon the initial design and release of the software, SSL is no longer sufficient to adequately protect communications as new threats and attack methods have significantly reduced its effectiveness as a security control. Therefore, it is imperative that vendors have processes in place to continuously monitor implemented security controls to make sure that they remain appropriate and sufficient to mitigate evolving threats and design flaws throughout the entire lifetime of the software. 
Evidence to support this requirement might include software-specific documentation, features lists, software-specific security control inventories, change-management documentation, risk-assessment reports, penetration test results, output from active monitoring systems, bug bounty program data, or any other evidence or information that clearly and consistently illustrates that the effectiveness of software security controls is monitored and that software-specific software security controls are updated, augmented, or replaced when no longer effective at satisfying their intended purpose of resisting attacks.