PCI Secure Software Lifecycle v1.1

Control Objectives:
5.1 All changes to software are identified, assessed, and approved.
Test Requirements:
5.1.a The assessor shall examine vendor evidence and interview personnel to confirm:

5.1.b For a sample of changes, the assessor shall examine software-specific and change-specific documentation or evidence to confirm the following:

Guidance:
All changes to software should be defined, documented, approved, and tracked so that any vulnerabilities attributed to such changes may be identified and resolved as quickly as possible. The harder it is to trace vulnerabilities back to the changes that introduced them, the longer it takes to resolve those vulnerabilities⎯thus placing the software at greater risk of attack or compromise. 
It is imperative to understand the security risk of a change to the software to ensure that it is addressed accordingly. It often involves understanding the types of software functionality the change impacts (e.g., functionality that deals with encryption or authentication processes), the type of information assets that the functionality can access or manipulate, the likelihood of successful vulnerability exploitation, and the impact a successful attack may have on stakeholders. 

Control Objectives:
5.2 All software versions are uniquely identified and tracked throughout the software lifecycle.
Test Requirements:
5.2.a The assessor shall examine vendor evidence and interview personnel to confirm the following: 

5.2.b For a sample of software updates, the assessor shall examine vendor evidence, including change-specific documentation, to confirm the following: 

Guidance:
Without a thoroughly defined versioning methodology, changes to software may not be properly identified, and customers and integrators/resellers may not understand the impact of such changes. 
The system or methodology adopted by the vendor should allow different release versions of a software product to be easily distinguishable. To ensure a software version accurately represents the release version, the versioning system or methodology should be integrated with applicable lifecycle functions, such as code control and change management. 
The versioning system or methodology should encompass all changes to all relevant software components. As several iterations of a software component may be produced for a single software release, the versioning system or methodology should easily identify the version of each component associated with a specific software release version. 
The method used for identifying the software release versions—for example, a version numbering scheme— should be documented and reflect the type of change and its impact on the software. 
For software intended to be validated under the PCI Software Security Framework, the vendor’s versioning system or methodology is important in determining updates to the PCI SSC List of Validated Payment Software. Refer to the PCI Secure Software Program Guide for further information.