SDLC or S-SDLC (Secure Software Development Life Cycle) is a methodology that aims to improve the overall security of web and regular application development processes. The main idea is to understand your current, or to-be, development process and include your business`s minimal security requirements on it. Considering development good practices, standards and guides on the different phases of the whole development process, might be an ambitious and challenging project that would require money, man-hours and cultural changes as well.
There are many proprietary and open-source methodologies each one with their specific characteristics and requirements but in the end, the goal is eventually the same, improve the overall security of your development process. While you can discuss and evaluate the development process of your company, the best approach I would recommend is to adapt security to the current process, instead of changing the current process so it become compliant to your security requirements. Doing it this way, would minimize the cultural shock and effort needed to deploy such requirements and it would less “friction” and resistance to your company.
I’d define this initiative in two different projects, based on the reality you’re facing:
- Implementing a SDLC into your company’s development team, if there are any
- Defining your company’s requirements to buy/hire development services
For this post, I’ll be discussing the first point as the SDLC would fit better for this reality.
The first step is to understand how your development process works, what are the main phases, which are the artifacts, documentations, standards and activities that the development team does/has. Generally speaking, your development processes would, at a certain point, fit into one of the most used methodologies like Waterfall, DevOps, Agile, etc. but, as I stated on the start of this post, the idea isn’t to change the development process but is to implement a minimum security standard to it. An overall secure development process can, at a high level, be defined on the following steps:
- Training/Awareness
- Professionals are presented to the methodology and complimentary security training is provided
- Requirements
- Security requirements are defined and formalized in an overall manner so it applies to all development projects, based on the business risk appetite
- Design
- Threat modeling and early definitions of how the coding work should be carried on
- Code
- Coding is done in a secure way, using secure and up-to-date libraries and languages, static code analysis may also be done
- Testing
- Pen-tests, static and dynamic analysis are executed on this phase, the project must achieve a result aligned to the defined risk appetite
- Release/Sustain
- Vulnerability management, recurrent testing and incident management are the activities done in this phase. This needs to occur until the solution is decommissioned.
At each step, security requirements should be added, for instance when doing the regular development training for employees, secure development practices should also be included in this training, teaching developers the good security practices and bringing awareness to the topic. Having security addressed at each one of the main development phases, will reduce the amount of re-work and most importantly risks at the end of the development project. Leaving the security checks for the end of the project will, almost certainly, impact business`s deadlines due to vulnerabilities or security risks needing to be fixed on production or pre-production environments. That’s why it isn’t enough to just do dynamic analysis or pen-tests as the last check before going to production.
Unfortunately, as many other things in life, there’s no silver bullet that would perfectly fit your reality, the whole SDLC methodology is, more than anything else, an awareness and training initiative. A detailed and deep study of your current reality needs to be done, at the same time that your risk appetite defined and because of that, each SDLC project may differ from the other.
Let me know what you think of this topic, feedback is always welcome and check out some references and sources below.
secvision22 