I recently saw a tweet that mentioned how trending SecDevOps is becoming. For those that don’t know, that is the “secure” devops, or shall I say devops with security injected. It really got me thinking about not only devops, but also the Software Development Life Cycle (SDLC). We keep saying security can’t be bolted on and that it needs to be built in, yet we keep bolting it on.
For years, we have talked about how the SDLC doesn’t have security built in and how we can create a “secure” SDLC, or the Secure Development Lifecycle (SDL). My concern is that as long as we have an SDLC and a “Secure” SDLC, or a DevOps or “Secure” DevOps, we will always have the insecure implementation. In addition, we are lacking a way to determine what security enhancements are built into “your” SDLC.
So why not version these items? Rather than creating a “Secure” SDLC (or SDL) lets look to create SDLC 2.0. Now this wouldn’t be the end all for a secure SDLC, but it could be used to build a maturity model to help identify what controls are in place. Like BSIMM or OpenSAMM, it creates the opportunity for a maturity model to form. This maturity model not only provides goals for the organization to grow towards, it also makes auditing easier. Imagine going through a PCI audit and instead of answering a bunch of questions on your secure SDLC you can select what version you conform to. We seem to have too many different ways of doing things around application security which makes it more confusing. Development programs know SDLC, so versioning it vs. BSIMM or OpenSAMM may have some better traction. This is just a thought.
The same concepts go for versioning devops, or any other framework we are using. This is not something that could possibly happen overnight, but if properly implemented could be very beneficial. I would be curious if there are any thoughts on this, or if it has even been thought of previously. Is this possible? What would go in each version to help build up to a mature program?