The aim of this post is to provide you with the required knowledge for defining a Secure Software Development Lifecycle, whether it’s for cloud based application or “on-premise” applications, and why it’s important for your organization to define processes around that.
Why & what is a secure development lifecycle?
It’s a common belief that security slows down the development process, however, a secure DLC (Development LifeCycle) provides the necessary method and processes for breaking down security into stages during the development process. Ensuring that development and security teams are working together to deliver secure software without being delayed. It reduces the risk of finding security vulnerabilities in your application.
Security applies at every phase of the software development life cycle (SDLC) and needs to be at the forefront of your developers’ minds as they implement your software’s requirements.
As a reminder, for cloud based application the following Shared Security Model is applicable:
Phases
Software Development Lifecycle (SDLC) describes how software applications are built. It usually contains the following phases:
- Gather requirements
- Design new features based on the requirements
- Develop new capabilities to meet the requirements
- Verify the developed new capabilities
- Maintain and improve the capabilities
Each phase of the SDLC must contribute to the overall security of the application. This is done by raising awareness for the developers and by putting security at the forefront of the entire team’s mindset.
Requirements
During the gathering of requirements for new features and capabilities, it’s crucial identify any security considerations for functional requirements being gathered for the new release.
Design
In this phase you most of the time focus on what should happen, on top of that you must ask the question of what shouldn’t happen.
Development
First of all the development team must be aware of the best practices for development software in a secure way (depending on the language used). Secure coding principles and guidelines, as well as code reviews to double check that the guidelines have been followed correctly is a must (e. g. static application security testing).
Because nowadays developers rely on pieces of codes developed by someone else make sure to use secure and tested code (e.g. Software Composition Analysis).
Example of secure coding guidelines:
– Validation of user inputs before processing data contained in them
– Sanitization of data send back out to the users from the database
– Checking of open source libraries
– Code reviews
Verification
The Verification phase is where applications go through a testing cycle to make sure that they meet the original design & requirements.
This is also a moment to introduce automated security testing using a variety of technologies. The application is not deployed unless these tests pass, think of “security gates”. This phase often includes automated tools like CI/CD pipelines to control verification and release.
Examples
Here are some examples of well known frameworks for establishing secure software development lifecycle:
OWASP Comprehensive, Lightweight Application Security Process (CLASP)
CLASP is built of rule-based components that implement security best practices. It can help developers secure applications at early phases of the development cycle and implement security in a structured and repeatable way.
CLASP was developed by analyzing actual development teams in the field, deconstructing their development lifecycles, and identifying the most effective way to add security practices to their established workflows. CLASP not only addresses ways to enhance established processes, but also helps teams address specific vulnerabilities and coding weaknesses which could be exploited and lead to major security breaches.
NIST Secure Software Development Framework (SSDF)
Created by the National Institute of Standards and Technology (NIST), the SSDF defines software development practices that can help realize a secure SDLC. This framework aims to reduce the number of vulnerabilities in software released to production environments, as well as mitigate the impact of potential exploitation of unaddressed and undetected vulnerabilities.
Conclusion
As said in the introduction the goal of this article is to describe from a high level standpoint what must be done by your organization to ensure that software is released free of vulnerabilities and reduce the impact of unaddressed ones. Hopefully, this article raised some curiosity and motivates you to dig into this super interesting topic.
And in case it’s not sufficient, let’s talk about money, and see the price of fixing a defect in each phase of the development lifecycle (IBM study).
As a key takeaway, remember that raising security awareness among your teams is always worth it.
