Define and implement a SDLC process for application design, development, deployment, and operation in accordance with security requirements defined by the organization.
Defining security requirements should be the first step in the secure software development lifecycle (SSDLC) process to ensure that security is integrated into the product from its creation. All security requirement aspects should be considered from functional, physical, and business requirements perspectives. In addition, security requirements should derive from security objectives and/or organizational goals and regulatory requirements. Industry standards should be applied at project inception and every stage of the SSDLC process—including requirements analysis, design, coding, testing, deployment, and end-of-life (EoL) processes. To successfully enable SSDLC security, roles and expectations should be clearly defined and published, and an inventory of applications and their metadata should exist in an easily accessible format. Appropriate security practice examples for the common stages of an SSDLC are provided below to include the following categories: training, requirements, design, development, testing, and release and response. A. Training:
- Role-based secure development training should be required at multiple stages of employment (or other contractual relationships), including on-boarding and role changes.
- Refresher training should be delivered throughout one's career, regardless of position or movement in their organization.
- Targeted, specialty training should be created and made available as the organization adopts new technologies.
- Progressively advanced training should be made available to relevant employees (and contractors whenever applicable) as they transition through technical roles and/or champion program participants.
- Generic and specialized security requirements should be defined, published, organized, and easily accessible to all organizational roles.
- Every application, during each iteration, should review existing requirements and research if additional requirements are necessary. It is beneficial for the engineering teams to consult with a security professional at this time.
- Security-focused design reviews are conducted.
- Threat models are developed or modified.
- The design of new or enhanced security controls, required by the application design, is developed.
- Develop, as per design specifications.
- Abuse cases are used to develop a security-focused unit and integration tests during development.
- Secure coding practices are implemented and enforced through automation and manual peer code reviews.
E. Security Testing:
- Manual and automated test plans are developed and executed with abuse cases in mind.
- Automation may include one or more of SCA, SAST, DAST, IAST, fuzzing, credential scans, etc.
- Penetration testing may be executed during this stage, based on need.
- Crowdsourced testing or private bug bounty programs may be implemented.
- Change control is instituted, including gating and documenting releases to ensure requirements and compliance objectives are met.
- Monitoring and alerting are in place to identify security issues and enable response activities.
- A response plan exists and can be easily executed when a security issue is discovered.
- A process is established for monitoring external sources for vulnerability disclosures and responding when applicable.
- Examine policy and procedures for definition of SDLC (Software Development Lifecycle), security, and compliance requirements.
- Examine the state of implementation of the SDLC process.
- Verify that the SDLC implementation is in accordance with requirements.
[csf.tools Note: For more information on the Cloud Controls Matrix, visit the CSA Cloud Controls Matrix Homepage.]
Cloud Control Matrix is Copyright 2023 Cloud Security Alliance.