PCI Secure Software Lifecycle v1.1

Control Objectives:
4.1 Existing and emerging software vulnerabilities are detected in a timely manner.
Test Requirements:
4.1.a The assessor shall examine vendor evidence and interview personnel to confirm the following:

4.1.b The assessor shall examine evidence, including software-specific security testing configurations and test results to confirm the following:

4.1.c The assessor shall examine vendor evidence and interview personnel to confirm that personnel responsible for testing are knowledgeable and skilled in the following areas in accordance with Control Objective 1.3: 

4.1.d For a sample of vendor software, examine software-specific testing results to confirm that security testing is performed throughout the software lifecycle. 
Guidance:
Software should be monitored or routinely tested to confirm that vulnerabilities are identified and mitigated before software or code updates are released into production, and to address any vulnerabilities that may have been discovered since release. 
Routine security testing should be performed prior to or as part of the code-commit process to detect coding errors or the use of insecure functions. It could also be performed during unit, integration, regression, or interoperability testing, or during separate security testing. Security testing should be performed consistently and throughout all stages of the software lifecycle, including during various pre-release phases of the software development process and after code release, to ensure the software is free from vulnerabilities upon launch and any subsequent updates, and remains free from vulnerabilities throughout its lifetime. 
Security testing should be performed by appropriately skilled vendor personnel or third parties. In addition, security testing personnel should be able to conduct tests in an objective manner and be authorized to escalate any identified vulnerabilities to appropriate management or development personnel so they can be properly addressed. 
Evidence to support this control objective could include softwarespecific requirements documentation, security test results, feature lists, change-management documentation, entries in the vendor’s workflow (bug tracking) database, or any other evidence or information that clearly and consistently shows that security testing is performed routinely to detect vulnerabilities in code prior to release as well as vulnerabilities discovered since code launch. 

Control Objectives:
4.2 Newly discovered vulnerabilities are fixed in a timely manner. The reintroduction of similar or previously resolved vulnerabilities is prevented.
Test Requirements:
4.2.a The assessor shall examine vendor evidence and interview personnel to confirm the following: 

4.2.b For a sample of vendor software, the assessor shall examine software-specific security-testing results and the details of software updates to confirm that security fixes are made available and deployed (where applicable) in accordance with defined criteria.
4.2.c For a sample of vendor software, the assessor shall interview personnel to confirm that decisions not to provide security fixes in accordance with defined criteria are justified by appropriate personnel. 
Guidance:
Vulnerabilities should be addressed in a manner commensurate with the risk they pose to the software or its stakeholders. The most critical or severe vulnerabilities⎯i.e., those with the highest exploitability and/or the greatest impact to stakeholders⎯should be patched immediately, followed by those with moderate-to-low exploitability and/or impact. Additionally, the discovery of new classes of vulnerabilities should be used as a source of input for process improvement. Software should be reviewed for instances of similar vulnerabilities, and the vendor’s development processes updated to enable detection and mitigation of such vulnerabilities in the future. 
In some cases, it may be impractical for a vendor to fix all identified vulnerabilities prior to the release of production code or updates. In such circumstances, the vendor should have a methodology with clear criteria defined for prioritizing vulnerability fixes. The default outcome should always be that vulnerabilities are fixed before the software is released. In cases where it is not possible to fix a vulnerability prior to release, an exception process involving management at a level commensurate with the severity of the vulnerability should be invoked. The process should include documented justification for why a fix for was not provided to address the vulnerability. 
If it is not possible to mitigate a certain vulnerability prior to release, the vendor should provide stakeholders with additional guidance to mitigate the risk of exploitation until a security update to fix the vulnerability can be made available. 
Under no circumstances should a previously resolved vulnerability be reintroduced into production code, nor should similar vulnerabilities within the same class of vulnerabilities be reintroduced. Additional assurance processes and safeguards should be implemented to ensure that such incidents are avoided. The specific processes to prevent such occurrences will largely depend on how the vendor’s software is structured and how the vendor manages software updates. It is up to the software vendor to determine the most appropriate methods to prevent the reintroduction of vulnerabilities into production code.