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:
- A mature process exists for distributing and deploying fixes for newly discovered vulnerabilities and preventing the reintroduction of previously resolved vulnerabilities.
- The process includes methods to prevent previously resolved vulnerabilities or other similar vulnerabilities from being reintroduced into the software.
- The criteria for determining the “criticality” or “severity” of vulnerabilities and how to address vulnerabilities are defined and justified.
- Fixes to address vulnerabilities in production code are made available and deployed in accordance with defined criteria.
- Decisions not to provide fixes in accordance with defined criteria are approved and justified by appropriate personnel on a case-by-case basis.
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.
