Model | Design | Security Requirements
The Security Requirements (SR) practice focuses on security requirements that are important in the context of secure software. A first type deals with typical software-related requirements, to specify objectives and expectations to protect the service and data at the core of the application. A second type deals with requirements relative to supplier organizations that are part of the development context of the application, in particular for outsourced development. It is important to streamline the expectations in terms of secure development because outsourced development can have significant impact on the security of the application. The security of 3rd party (technical) libraries is part of the software supply chains stream (see Secure Build), and it is not included in this practice.
| Maturity level | Stream ASoftware Requirements | Stream BSupplier Security | |
|---|---|---|---|
| 1 | Consider security explicitly during the software requirements process. | High-level application security objectives are mapped to functional requirements. | Evaluate the supplier based on organizational security requirements. |
| 2 | Increase granularity of security requirements derived from business logic and known risks. | Structured security requirements are available and utilized by developer teams. | Build security into supplier agreements in order to ensure compliance with organizational requirements. |
| 3 | Mandate security requirements process for all software projects and third-party dependencies. | Build a requirements framework for product teams to utilize. | Ensure proper security coverage for external suppliers by providing clear objectives. |