DevSecOps vs. SecDevOps: A Rose by Any Other Name?
Table of Contents
What’s in a name?
The terms DevSecOps and SecDevOps are often — but not always — used interchangeably. So is there any real difference between the two terms or is it all just semantics? Let’s look at how the role of security has changed as the software development life cycle (SDLC) has evolved to explore whether there’s really any difference between these two words.
The SDLC evolves
Transitioning from the Waterfall software development model to Agile and eventually DevOps changed the way security is managed. In Waterfall, a linear model in which project activities are broken down into different sequential phases, security comes after development and testing. Agile took a new iterative approach to development by allowing changes in product scope and requirements at any time. DevOps went one step further by bringing together development and operations for a more efficient software life cycle.
As a result of these changes, software development time decreased significantly. Software development teams went from a release every six months, to a release every week or two, to now as often as every few days.
Under this blistering DevOps timeline, software development teams found they couldn’t leave security until the end like in the Waterfall model. Addressing security flaws after development and testing slowed down the development process. With the increased focus on application security, security fixes became too time consuming and too costly when addressed just before software was released. A change was needed to fix this bottleneck. Security needed to be embedded into all stages of the SDLC.
Along comes DevSecOps
DevSecOps was born as a response to the security problem. It promised to bridge the chasm between continuous release cycles and security needs by addressing security at every stage of the SDLC. The DevSecOps approach shifted security left, advocating for security practices to be implemented from the earliest planning and design stages through development to testing and beyond. In this approach, developers take on the primary responsibility for security while writing code, and security testing is done throughout the development process, not after it is finished.
The idea of DevSecOps is full of promise, but the reality is somewhat less rosy. Though DevSecOps puts security in the hands of the developers, the pressure to complete development on time and on budget sometimes causes security to be pushed to the last step in development. Developers don’t have the tools and processes in place to address security until it becomes one final hurdle to get through in a gated process. Under DevSecOps, some argue, development remains the first priority, while security comes a distant second.
SecDevOps puts security first, literally
For those who argue there is a difference between DevSecOps and SecDevOps, it is about putting security first. Literally. It’s right there in the name: SecDevOps.
SecDevOps proponents believe it goes further than DevSecOps to promote secure coding practices. While DevSecOps argues that security should be embedded into every stage of the software development life cycle, SecDevOps believes security should come first at every stage in the SDLC. Though you might think this is a minor distinction, SecDevOps proponents argue it is an important one.
The following are several of the key tenets behind SecDevOps to reduce costly late-cycle security escalations and improve the outcome of each cycle:
- All teams share equal responsibility for security.
- Security policies are well defined across the enterprise.
- Security should be built into the planning, analysis, design, and deployment stages in addition to traditional implementation and testing stages.
- Security procedures for both development and operations are automated whenever possible. This includes fixes for known vulnerabilities.
- Changes in application code are tied to deployment procedures and rules.
SecDevOps believes all DevOps professionals should be security practitioners. To achieve this, developers need the tools and knowledge to implement security efficiently. This usually involves a huge investment in training and coaching.
It is not unusual in a SecDevOps approach to have a dedicated security team that doesn’t implement security, but rather defines security policies for the entire organization. These policies might consist of coding best practices, rules for encryption, and testing guidelines using SAST, DAST, or SCA. Here, the security team’s goal is to train developers, architects, operations, and others on security best practices and tools to foster security expertise across the SDLC.
Under SecDevOps, the goal is to have both developers and operations working toward creating software that is more secure as part of their daily routine. Thinking about security at the very beginning of each development cycle leads to the most secure development practices. Security is not optional, nor is it an afterthought with SecDevOps.
Security still smells as sweet
Some argue that DevSecOps is doing all the same things as SecDevOps and more. And in many organizations, this could very well be true. SecDevOps arose in organizations that felt security needed a more targeted focus. Is there really a difference? As Shakespeare wisely said, “That which we call a rose, By any other name would smell as sweet.”
It doesn’t matter whether you call it DevSecOps or SecDevOps, as long as you are managing and implementing security throughout your SDLC. In the end, DevSecOps and SecDevOps are slightly different approaches to the same overall goal: to deliver software quickly while avoiding security defects.
A rose by any other name may still smell as sweet, just as long as you make sure it’s secure.
