With 9 out of 10 breaches beginning with defects in code, it’s no wonder that companies have rushed to incorporate security into their development pipelines. And with that rush has come a whole new industry – DevSecOps – and the jargon to go with it.
What are some of the phrases you may hear?
Rugged DevOps is focused on the culture of integrating security into development. The Manifesto written by Josh Corman, Jeff Williams, and David Rice hones in on the “ability to create available, survivable, defensible, secure, and resilient software” in a world where the threat landscape is continually changing and software may be used in ways we never intended. It is not tied to a specific development methodology, but rather about being proactive about security to continually evolve as part of development.
Just as it sounds, Security-by-Design focuses on building secure coding practices into the product or specific functionality. It looks at applying robust security controls at the earliest stage to minimize attack surface area, and predict areas of risk to ensure depth of defense. You’ll often hear about exercises like threat modelling here – in some ways it is like predictive pen testing, in that you try to look at the ways that your code could be maliciously used before you’ve ever written it.
Shift-left focuses on moving security testing earlier in the development lifecycle – literally moving it left in the process. Emphasis is placed when, where and how often security testing occurs in the SDLC. It relies heavily on the automation of DevOps pipelines to enable AppSec testing in parallel with development. However, Companies often struggle with this as they worry about testing too soon and disrupting the balance between speed and security.
Wait what. Didn’t you just say that the industry is called DevSecOps?
Yes – that is the common nomenclature. And there’s even a debate if there’s just DevSecOps or that’s an umbrella term for integration of security into development pipelines with three sub-varients being DevSecOps, DevOpsSec and SecDevOps.
We believe that there is a difference, with the three variants of DevSecOps are actually reflective of the maturity of integrating security into a development pipeline.
DevOpsSec puts security after her development. It still implies a level of integration into the Development process (versus a DevOps + Sec), but only once code is already in production. 90% of companies begin security testing after code is in production, even though it’s harder and more expensive to fix vulnerabilities in production.
Do you have DevOpsSec?
- Security teams are siloed from Development teams and have limited interaction other than in critical situations
- You have regularly scheduled vulnerability scans because you know security is about more than just compliance
- Results are managed in separate workflows and are likely manually managed
DevOpsSec is like building a house, having its occupants move in, and then checking if it was built correctly after. And then when it comes time to fix it, it takes longer and is never quite right…
DevSecOps focuses on the integration of testing tools into the development pipeline. However, by focusing on the tools, it lacks project context, meaning there is a trade off between speed and security. And when 57% of development teams are shipping code weekly or more frequently, nowadays, it’s hard to say, let’s slow down.
Do you have DevSecOps?
- Security and Development teams have visibility into each others processes
- Security testing is more than just SAST & DAST, using IAST & RASP as well as for other components of the SDLC (e.g. container security, cloud configuration security)
- Results are managed in the same product management platform
Back to our building a house analogy, DevSecOps is like compiling a punch list of things that need to get fixed as it is being built, but not having enough information to know what order to fix them in, or if they even need to all be fixed.
SecDevOps is about the integration of Security into Development processes. By focusing on the alignment of Security processes with Development processes, rather than just focusing on the tools, Security can be integrated into every stage, and then supported by tools rather than held up by them.
Do you have SecDevOps?
- Security and Development teams have a regular, integrated cadence (Sec may even attend code reviews!)
- Projects get specific policies assigned based off the project details
- Results are automatically prioritized and integrated back into the Development workflow as work items
SecDevOps is how we build houses: processes are defined in advance, to ensure inspections are conducted at the right time, and critical items are fixed before advancing, while others can be appropriately prioritized and fixed later or allowed to become part of Security Debt.
No transformation will ever occur overnight. However, reaching the ulitmiate SecDevOps state is not a utopian dream, but rather an easily obtainable one when you align the people, proccesses, and tools that Development, Operations and Security teams use.