Published on
There was a point in time when the only thing that mattered when it came to software development was that functional software was deployed in the stipulated time. There wasn't much emphasis on software security, and software applications were only checked for security flaws in the testing stage before being deployed to production. This often caused friction between development and security teams, who were at odds with each other due to having competing motivations - speed of deployment for dev teams, application security for security teams.
However, the increased sophistication in the attack methods used by malicious hackers over the years has rendered this old method of software development inadequate. It is no longer viable, as the frequency with which attacks occur has risen to dizzying levels. According to the U.S. Department of Justice, an average of more than 4,000 ransomware attacks have occurred daily since 2016!
This has forced developers and companies to re-evaluate how they approach software security. One answer to improving application security? The Secure Software Development Lifecycle (S-SDLC).
What is the Secure Software Development Lifecycle (S-SDLC)?
The S-SDLC, or secure SDLC, is a new approach to the existing software development framework where security is integrated into every stage of the software development life cycle, starting from the requirements gathering stage to the deployment and maintenance of the application.
The new method comes with several advantages over the traditional method.
Major benefits of using the secure SDLC
- It produces more secure software - That’s the whole point of it, right? In the S-SDLC, security measures are being taken at every development stage which helps identify and cover vulnerabilities that may have been missed if the software was only being tested for flaws once.
- Cost reduction - According to the Systems Sciences Institute at IBM, it’s 6x more costly to fix a security flaw discovered during software implementation than one identified during design. This is very much in line with Boehm’s Law, which states that “The cost of finding and fixing a defect grows exponentially with time”
- Helps developers stick to release deadlines - The problem with testing for vulnerabilities in the testing stage is that you never know what you will find. If it’s a major flaw that demands you change the existing code then that could interfere with the set release deadline. However, by catching the flaw in the earlier stages of a secure SDLC, security has already been addressed even before you reach the testing stage.
- Everybody is involved in application security - The task of securing the software does not only fall on the developer but rather, on everyone invested in the software. This shift in mindset helps decrease the number of vulnerabilities that end up in production.
The 5 Main Stages of Secure Software Development Life Cycle
On the surface level, there is no difference between an S-SDLC and traditional SDLC. They all follow the same basic steps. These are:
- Requirements gathering
- Design and architecture
- Test planning
- Coding
- Testing
- Deployment and Maintenance
These are the same basic steps you will find in almost every other software development method including the iterative and the more recent agile software development model. The steps are derived from the waterfall model which was among the earliest software development models.
Let’s explore the S-SDLC methodology to see the differences in the activities that happen at every stage. While we can’t exhaustively cover the activities at every stage, since there are many variances from one application to the next, the following section will provide a good overview of how security becomes an integral part of the development process in a secure SDLC.
1. Requirements gathering
This is one of the most critical stages of the software development life cycle. It lays a foundation upon which the software is built. The senior engineers, representatives from various company departments, domain experts, and all stakeholders collaborate to come up with the requirements for the project.
In this stage, the labor and material costs for the project are decided as well as the timetable for completion. Other activities in this stage include defining the scope and expected behavior of the software based on the feedback from customers, surveys, developers, sales reps, and other stakeholders.
To integrate security into the process, the parties have to perform a risk assessment, which produces a set of security requirements for the software. An example requirement is the type of cryptography to use to protect the application’s user data.
2. Design and Architecture
This stage involves transforming the gathered requirements into a blueprint that developers can follow during the development phase. The standard process is that the architect comes up with different models which will then be reviewed by the stakeholders to determine the most viable.
But, with S-SDLC this is not where it ends. The architect also needs to review the design to identify vulnerable points that hackers could exploit.
For example, if the software requires that users log in to access information, the design has to have a provision that checks if the user has a valid session token before they can access any data. Threat modeling frequently occurs at the tail end of the design and architecture stage of the SDLC.
3. Test Planning
This is the stage where the team defines the requirements needed to implement software testing such as the testing strategy, the test environment, frequency of tests, and resources needed. The team also has to factor in possible hurdles to the testing process.
4. Coding
This is the stage where the programming of the application begins. In alignment with the S-SDLC model, the developer has to make sure that they are following coding best practices as set by the organization and program-specific tools.
If the developer is modifying third-party components rather than starting the code from scratch they need to check these components for existing vulnerabilities.
An example of a secure coding guideline to follow is to use parameterized SQL queries to protect the software against SQL injection vulnerability. If developers aren’t adequately prepared to write secure code, then they should be assigned secure coding training to close that gap in knowledge.
5. Testing
This is the stage where developers test the application to make sure it is performing as required before putting it in production. In alignment with the S-SDLC, the developer also has to test the application for security vulnerabilities. In a contemporary DevOps/DevSecOps model, the use of SAST and DAST tools is commonplace.
6. Deployment and Maintenance
At this point, the application has ticked all the performance and security boxes and is ready to be implemented.
However, it’s still possible that some vulnerabilities were missed in the other stages and so, the application should regularly be checked for vulnerabilities. This could be done by employing ethical hackers or bug bounty programs that encourage users to find a vulnerability in the software in exchange for a reward.
Conclusion
The promise of the secure development lifecycle is to improve application security, while reducing inefficiencies that result in unexpected delays and costs. From an organizational perspective, this cultural and philosophical shift bears the promise of a more harmonious work environment, since everyone is on the same page regarding security. This article serves as a rudimentary introduction to the basics of the secure SDLC. To understand and be able to produce secure software, you will need to take additional steps. These can include, but aren't limited to becoming knowledgeable about secure coding practices, and becoming familiar with existing S-SDLC frameworks. A couple of good places to continue your secure software development journey are the Microsoft Security Development Lifecycle or NIST’s Secure Software Development Framework (SSDF).
