The organization:

Requires the developer of the information system, system component, or information system service to follow a documented development process that:

Explicitly addresses security requirements;

Identifies the standards and tools used in the development process;

Documents the specific tool options and tool configurations used in the development process; and

Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and

Reviews the development process, standards, tools, and tool options/configurations Assignment: organization-defined frequency to determine if the process, standards, tools, and tool options/configurations selected and employed can satisfy Assignment: organization-defined security requirements.

SA-15 (1) Quality Metrics

Organizations use quality metrics to establish minimum acceptable levels of information system quality. Metrics may include quality gates which are collections of completion criteria or sufficiency standards representing the satisfactory execution of particular phases of the system development project. A quality gate, for example, may require the elimination of all compiler warnings or an explicit determination that the warnings have no impact on the effectiveness of required security capabilities. During the execution phases of development projects, quality gates provide clear, unambiguous indications of progress. Other metrics apply to the entire development project. These metrics can include defining the severity thresholds of vulnerabilities, for example, requiring no known vulnerabilities in the delivered information system with a Common Vulnerability Scoring System (CVSS) severity of Medium or High.

The organization requires the developer of the information system, system component, or information system service to:

SA-15 (1)(a)

Define quality metrics at the beginning of the development process; and

SA-15 (1)(b)

Provide evidence of meeting the quality metrics Selection (one or more): Assignment: organization-defined frequency; Assignment: organization-defined program review milestones; upon delivery.

SA-15 (2) Security Tracking Tools

Information system development teams select and deploy security tracking tools, including, for example, vulnerability/work item tracking systems that facilitate assignment, sorting, filtering, and tracking of completed work items or tasks associated with system development processes.

The organization requires the developer of the information system, system component, or information system service to select and employ a security tracking tool for use during the development process.

SA-15 (3) Criticality Analysis

This control enhancement provides developer input to the criticality analysis performed by organizations in SA-14. Developer input is essential to such analysis because organizations may not have access to detailed design documentation for information system components that are developed as commercial off-the-shelf (COTS) information technology products (e.g., functional specifications, high-level designs, low-level designs, and source code/hardware schematics).

The organization requires the developer of the information system, system component, or information system service to perform a criticality analysis at Assignment: organization-defined breadth/depth and at Assignment: organization-defined decision points in the system development life cycle.

SA-15 (4) Threat Modeling / Vulnerability Analysis

The organization requires that developers perform threat modeling and a vulnerability analysis for the information system at Assignment: organization-defined breadth/depth that:

SA-15 (4)(a)

Uses Assignment: organization-defined information concerning impact, environment of operations, known or assumed threats, and acceptable risk levels;

SA-15 (4)(b)

Employs Assignment: organization-defined tools and methods; and

SA-15 (4)(c)

Produces evidence that meets Assignment: organization-defined acceptance criteria.

SA-15 (5) Attack Surface Reduction

Attack surface reduction is closely aligned with developer threat and vulnerability analyses and information system architecture and design. Attack surface reduction is a means of reducing risk to organizations by giving attackers less opportunity to exploit weaknesses or deficiencies (i.e., potential vulnerabilities) within information systems, information system components, and information system services. Attack surface reduction includes, for example, applying the principle of least privilege, employing layered defenses, applying the principle of least functionality (i.e., restricting ports, protocols, functions, and services), deprecating unsafe functions, and eliminating application programming interfaces (APIs) that are vulnerable to cyber attacks.

The organization requires the developer of the information system, system component, or information system service to reduce attack surfaces to Assignment: organization-defined thresholds.

SA-15 (6) Continuous Improvement

Developers of information systems, information system components, and information system services consider the effectiveness/efficiency of current development processes for meeting quality objectives and addressing security capabilities in current threat environments.

The organization requires the developer of the information system, system component, or information system service to implement an explicit process to continuously improve the development process.

SA-15 (7) Automated Vulnerability Analysis

The organization requires the developer of the information system, system component, or information system service to:

SA-15 (7)(a)

Perform an automated vulnerability analysis using Assignment: organization-defined tools;

SA-15 (7)(b)

Determine the exploitation potential for discovered vulnerabilities;

SA-15 (7)(c)

Determine potential risk mitigations for delivered vulnerabilities; and

SA-15 (7)(d)

Deliver the outputs of the tools and results of the analysis to Assignment: organization-defined personnel or roles.

SA-15 (8) Reuse Of Threat / Vulnerability Information

Analysis of vulnerabilities found in similar software applications can inform potential design or implementation issues for information systems under development. Similar information systems or system components may exist within developer organizations. Authoritative vulnerability information is available from a variety of public and private sector sources including, for example, the National Vulnerability Database.

The organization requires the developer of the information system, system component, or information system service to use threat modeling and vulnerability analyses from similar systems, components, or services to inform the current development process.

SA-15 (9) Use Of Live Data

The use of live data in preproduction environments can result in significant risk to organizations. Organizations can minimize such risk by using test or dummy data during the development and testing of information systems, information system components, and information system services.

The organization approves, documents, and controls the use of live data in development and test environments for the information system, system component, or information system service.

SA-15 (10) Incident Response Plan

The incident response plan for developers of information systems, system components, and information system services is incorporated into organizational incident response plans to provide the type of incident response information not readily available to organizations. Such information may be extremely helpful, for example, when organizations respond to vulnerabilities in commercial off-the-shelf (COTS) information technology products.

The organization requires the developer of the information system, system component, or information system service to provide an incident response plan.

SA-15 (11) Archive Information System / Component

Archiving relevant documentation from the development process can provide a readily available baseline of information that can be helpful during information system/component upgrades or modifications.

The organization requires the developer of the information system or system component to archive the system or component to be released or delivered together with the corresponding evidence supporting the final security review.