Under active development Content is continuously updated and improved

SA-11Developer Security Testing

PBMM (P3)
Secret (P3)
Management

>Control Description

(A) The organization requires the developer of the information system, system component, or information system service to create and implement a security assessment plan. (B) The organization requires the developer of the information system, system component, or information system service to perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at organization-defined depth and coverage. (C) The organization requires the developer of the information system, system component, or information system service to produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation. (D) The organization requires the developer of the information system, system component, or information system service to implement a verifiable flaw remediation process. (E) The organization requires the developer of the information system, system component, or information system service to correct flaws identified during security testing/evaluation.

>Supplemental Guidance

Developmental security testing/evaluation occurs at all post-design phases of the system development life cycle. Such testing/evaluation confirms that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements. Security properties of information systems may be affected by the interconnection of system components or changes to those components.

These interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely affect previously implemented security controls. This control provides additional types of security testing/evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches.

Developers can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Security assessment plans provide the specific activities that developers plan to carry out including the types of analyses, testing, evaluation, and reviews of software and firmware components, the degree of rigour to be applied, and the types of artifacts produced during those processes. The depth of security testing/evaluation refers to the rigour and level of detail associated with the assessment process (e.g., black box, gray box, or white box testing).

The coverage of security testing/evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security assessment plans, flaw remediation processes, and the evidence that the plans/processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the information system.

Contracts may specify documentation protection requirements. Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2

Ask AI

Configure your API key to use AI features.