The concept of integrating security into the software development process is not new. While I cannot definitively assert that Microsoft was the pioneer of this concept, the Secure Development Lifecycle (SDL) published by Microsoft in 2002 undoubtedly laid the foundation for what is now commonly known as a Secure Software Development Lifecycle (Secure SDLC or SSDLC).
Even today, over 20 years later, Microsoft’s SDL can still be useful for illustrating the general concept of an SSDLC. However, it may not be the optimal choice as a blueprint for implementing software security in today’s practical scenarios. Without delving into extensive details here, it’s worth noting that our comprehension of software development and security has naturally progressed over the past two decades.
Development has become more complex, agile, and the boundaries between development, operations, and security have blurred significantly. What we require now is a more comprehensive understanding of software security that encompasses all relevant aspects, extending beyond just the development process, and encompasses aspects like training and incident response. I’d like to refer to this approach as 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 reflection, 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 underlying concept here is not about establishing a new standard or similar measures. Naturally, not everyone would (or should) be required to implement all these practices. However, this visualization can be valuable for identifying relevant practices and especially crucial areas that may have been overlooked.
Addressing AppSec in governance and, particularly, central AppSec architecture are two such areas that often receive insufficient attention. Especially in a landscape dominated by DevOps, where releases are frequently brief and development teams are granted increasing autonomy, establishing a robust AppSec architecture becomes vital. This can be achieved through reference architectures, blueprints, and guardrails, providing dev teams the flexibility to make their own decisions.
Since not every organization builds and operates software in the same manner, there can’t be a universal standard applicable to 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 example, when you are not directly operating your applications, operational security might not be your primary concern. If your software is entirely developed by an external provider, you might not have the ability to dictate the implementation of a specific SSDLC, but you can require compliance with certain standards or the selection of one that aligns with your needs.
Tailoring an SSLM implementation to your organization is possible based on your unique profile. This flexibility explains why there are numerous diverse implementations in the field.
Conclusion
When aiming to enhance AppSec across an entire organization, we must consider more than just the development process. Software security extends beyond the shift-left paradigm; we need to integrate security comprehensively. This is particularly crucial in the era of Dev(Sec)Ops, where the distinctions between development, operations, and security are becoming increasingly blurred.
Given the unique nature of each organization, there cannot be a one-size-fits-all set of practices. The concept behind SSLM is to promote a more holistic perspective on AppSec and assist organizations in identifying gaps and controls that may be missing