Security management is the umbrella practice: it keeps security work planned, documented, assigned and checked across the whole product life-cycle so later practices are not starved of time, skills or process support.
SM requirement summaries
SM-1: Development process
Clause: 5.2
Summary
A general product development/maintenance/support process must be documented and enforced that is consistent and integrated with commonly accepted product development processes that include, but are not limited to: configuration management with change controls and audit logging; product description and requirements definition with requirements traceability; software or hardware design and implementation practices, su…
SM-2: Identification of responsibilities
Clause: 5.3
Summary
A process must be employed that identifies the organizational roles and personnel responsible for each of the processes required by this standard.
SM-3: Identification of applicability
Clause: 5.4
Summary
A process must be employed for identifying products (or parts of products) to which this standard applies.
SM-4: Security expertise
Clause: 5.5
Summary
A process must be employed for identifying and providing security training and assessment programs to ensure that personnel assigned to the organizational roles and duties specified in 5.3,
SM-5: Process scoping
Clause: 5.6
Summary
A process, that includes justification by documented security analysis, must be employed to identify the parts of this standard that are applicable to a selected product development project. Justification for scoping the level of compliance of a project to this standard must be subject to review and approval by personnel with the appropriate security expertise (see SM-4: Security expertise).
SM-6: File integrity
Clause: 5.7
Summary
A process must be employed to provide an integrity verification mechanism for all scripts, executables and other important files included in a product.
SM-7: Development environment security
Clause: 5.8
Summary
A process that includes procedural and technical controls must be employed for protecting the product during development, production and delivery. This includes protecting the product or product update (patch) during design, implementation, testing and release.
SM-8: Controls for private keys
Clause: 5.9
Summary
The supplier must have procedural and technical controls in place to protect private keys used for code signing from unauthorized access or modification.
SM-9: Security requirements for externally provided components
Clause: 5.10
Summary
A process must be employed to identify and manage the security risks of all externally provided components used within the product.
SM-10: Custom developed components from third-party suppliers
Clause: 5.11
Summary
A process must be employed to ensure that product development life-cycle processes for components from a third-party supplier conform to the requirements used in this document when they meet the following criteria: the components are developed specifically for a single supplier for a specific purpose; and the components can have an impact on security.
SM-11: Assessing and addressing security-related issues
Clause: 5.12
Summary
A process must be employed for verifying that a product or a patch is not released until its security- related issues have been addressed and tracked to closure (see 10.5, DM-4: Addressing security- related issues).
SM-12: Process verification
Clause: 5.13
Summary
A process must be employed for verifying that, prior to product release, all applicable security- related processes required by this specification (see SM-5: Process scoping) have been completed with records documenting the completion of each process.
SM-13: Continuous improvement
Clause: 5.14
Summary
A process must be employed for continuously improving the SDL. This process must include the analysis of security defects in component/subsystem/system technologies that escape to the field.