The Software (Systems) Development Life Cycle (SDLC) is the industry standard to build software/applications. It is a proven and efficient system used by most software companies around the world. When the SDLC was released, security was not a concern and did not include any security checks. A generic model of the SDLC is shown below.
As software’s role in everyday life increased, so did the attacks and breaches due to software security vulnerabilities. In response, the industry started doing security checks after the software was released (deployed). Doing security checks after deployment is used widely across the industry and it allows vulnerabilities to be detected.
Figure 1: Extracted from OWASP in SDLC[1]
This system has proven risky and costly, as fixing the vulnerabilities needs resources and downtime. Also, if a vulnerability is exploited before it can be fixed; can bring the company to ruin. In response to this risky and costly practice, the engineering and security communities came up with the Secure Software Development Life Cycle (SSDLC).
The SSDLC
The SSDLC embeds security policy, process, checks and tests into the SDLC, allowing apps to be secure-by-design. Secure-by-Design or Shift Left, as the SSDLC system is known, allows security to be integrated from the planning stage.
The SSDLC ensures the app is as secure as possible; minimising the risk and cost of vulnerabilities during the app’s life cycle. Implementing the SSDLC will ensure apps produced are secure and of higher quality in every deployment. It will reduce the risk of serious compromise and reduce the cost of fixing vulnerabilities during the life of the app. The SSDLC can be described as shown in figure 2 below.
Figure 2: Based on OWASP SAMM[2] and NIST 800-218[3]
Governance
The Governance function can be divided into three security practices: documentation, metrics, and training. Documentation focuses on Policies, Standards, and guidelines. The Documentation will help standardise, provide guidance and culturally embed secure-by-design. The metrics practice provides measurements and useful guidance to drive the effectiveness of the SSDLC. Training focuses on helping the engineering workforce use the SSDLC. Governance is key to ensuring that the SSDLC is synchronous and easy to apply by all stakeholders.
Design
The design function ensures the app is designed with secure-by-design principles. In this function, the SSDLC embeds the security practices of Threat Modelling, Security Requirements, and Security Architecture. Threat modelling ensures the app risks are taken into account and ensures they won’t have an impact on its operations. Threat modelling guides the security requirements and security architecture designs. Threat modelling as a minimum provides a baseline of the security practices required during the implementation phase. Security Requirements and Architecture are the documents where the application security standard is documented and guides the engineering teams on security practices needed to secure the application. The design function is the cornerstone of the SSDLC and lays the basis for a secure application.
Implementation
This function focuses on the app’s secure build and secure deployment. This function should include but is not limited to the security practices of Secure Build, Secure Deployment, and Vulnerability Management. Secure build and deploy focuses on building the application securely; doing sufficient automatic testing such as SAST, DAST, SCA, Secret Scanning and having a good and reliable secure code review process. The vulnerability management practice focuses on managing the findings from automatic testing and ensuring they are resolved before deploying the application. Overall, this function will ensure the deployed app is as secure as possible.
Verification
This function tests and verifies that the app is secure before it goes to production. Security practices in this function include but are not limited to testing the design requirements, app, and architecture. This function ensures the requirements are met, the app doesn’t have any major vulnerabilities and the infrastructure where the app is going to operate is secure.
Operations
This function ensures the app is secure while in use. The security practices in this function include but are not limited to the incident, environment, and operational management. The incident management practice ensures the effective handling of incidents. Environment management focuses on keeping the app’s operational environment as secure as possible. Operational management focuses on monitoring the environment and capturing incidents and events effectively. The Operations function ensures the app is as secure as possible during day-to-day operations.
Conclusion
The SSDLC will enable any organisation to significantly improve the security posture of all their apps. It will enhance the organisation’s security culture and enable the skilling-up of the workforce. Overall, It is an essential practice that will have a positive impact on the organisation and save the cost of operating the apps.
Thanks for reading!
If you’ve got AppSec troubles, feel free to reach out to us. At Galah Cyber we have experience helping clients across a range of industries with rolling out programs, teaching developers, tuning tools, and reviewing products for vulnerabilities.
Acknowledgments
A big shout out to Cole Cornford and my Galah Flock for their support and help in the development of this blog.
References
OWASP in SDLC, https://owasp.org/www-project-integration-standards/writeups/owasp_in_sdlc/, accessed on: 03 Oct 2022 at 21:56 AEST
OWASP SAMM, https://owaspsamm.org/, last accessed on: 20 Oct at 0700 AEST
NIST 800-218
