The idea of integrating security into the software development process is not new. I can’t say for sure if Microsoft really was the first one who came up with this concept, but the Secure Development Lifecycle (SDL) that Microsoft published in 2002 lay doubtless the foundation of what is today generally referred to as a Secure Software Development Lifecycle (Secure SDLC or SSDLC).
Even today, more than 20 years later, Microsofts SDL can fact still be useful for explaining what an SSDLC is generally about. However, it is probably not the best choice to be used as a blueprint to implement software security in the practice nowadays. I will not go into too many details here, but our understanding of software development and security in the development has of course evolved a bit over the last two decades.
Development has become more complex, and more agile, and the boundaries of development, operation, and security have become increasingly blurred. What we need is a more holistic understanding of software security that covers all relevant aspects, not just the development process, and a little training and incident response. I’d like to call this approach a Secure Software Lifecycle Management (SSLM).
Modern Concepts
Although this term seems not to be widely used yet, we find the idea behind it implemented by many of today’s secure software development frameworks. For instance, SafeCodes Fundamental Practices for Secure Software Development from 2018, the BSA Framework from 2020, the NIST SSDF from 2021, and OWASP SAMM from 2020.
I recently came across another interesting concept that is absolutely worth mentioning in this context. In their book Agile Secure Software Lifecycle Management by Barry Derksen and others from the Secure Software Alliance the authors describe their version of a modern secure software lifecycle management in the following way:
I think this is a great example of such a lifecycle for a particular application or product, starting with the initial project kickoff and ending with its operational servicing time which shows a lot of understanding of the practice to me. However, this is, of course, not really a framework but an example implementation like Microsoft SDL. Also, what I miss a bit are practices like AppSec architecture & governance that are not part of the development process or lifecycle itself.
A Secure Software Lifecycle Management
After some thinking, I came up with the following holistic view of how a Secure Software Lifecycle Management could look like and which works with all kinds of development methodologies, including DevOps. It even includes one important aspect that I often came across: Companies can actually have multiple Secure SDLC processes – e.g. one for modern development and one for SAP development.
It’s important to understand that the idea behind this is not defining a new standard or something like this. Of course, not everyone would (or should) need to implement all these practices. But this visualization may be useful to identify suitable practices and especially important areas that haven’t been thought about yet.
Addressing AppSec in governance and especially central AppSec architecture are two of these areas that often receive way too little attention. Particularly in a world of DevOps etc. where releases are often very short and where dev teams get an increasing amount of autonomy, it is important to define a solid AppSec architecture using reference architectures, blueprints, and guardrails in which dev teams can make their own decisions.
Not every organization builds and operates software in the same way. Therefore, there cannot be one standard that fits everyone. Here are some important aspects that distinguish what parts of an SSLM you may consider implementing and how to do that:
- Engineering Mindset: Enterprise, agency, or hybrid
- Development Model: Own development, development by a provider, or development as a provider
- Operation Model: Own operation, operation by a provider, operation by the customer
- Security Risk and Risk Appetite.
- Scope
For instance, when you don’t operate your applications yourself, you probably do not need to think about operational security that much. If your software is completely developed by an external provider, you will probably not be able to tell them to implement a particular SSDLC but to comply with certain requirements or to select one that does.
Based on your specific profile you can define an SSLM implementation that suits your organization. This is the reason why we see so many different ways of such implementations in the field.
Conclusion
When we want to improve AppSec for a whole organization, we need to look at more than just the development process. Software security is more than just shift left, we need to shift security everywhere. This is especially important in times of DevOps and DevSecOps where boundaries of development, operation, and security become increasingly blurry.
Every organization is different, so there cannot be one set of practices that fits everyone. The idea behind SSLM is to advocate a more holistic view of AppSec and to help organizations to identify missing areas and controls.