There’s an emerging conversation in information technology (IT) surrounding DevSecOps and SecDevOps and what, if anything, defines and distinguishes one from the other. While the overall goal might be the same — namely, to produce more secure applications — the approaches are quite different in both practice and philosophy.

DevSecOps is primarily concerned with integrating security processes into DevOps cycles while maintaining efficiency, while SecDevOps prioritizes security as much as the actual steps of integrating security into the DevOps process itself. 

In essence, SecDevOps means making every decision from a security-first mindset. SecDevOps doesn’t integrate security so much as cultivate a security ethos within every team member to ensure that security becomes a shared responsibility across the entire application lifecycle.

Speed kills

While that sounds good in practice — after all, who doesn’t want better security when their data and brand is at stake — SecDevOps can come with some surprising pitfalls.

Part of that is simply how application development and support has changed. While DevOps was embracing Waterfall and Agile methodologies that transformed the industry, the cyber threat landscape was also evolving into a much more consistent and dangerous enterprise risk. 

For most DevOps teams, security is a counterintuitive step because speed and automation are not necessarily valued components of the development lifecycle equation. What good is a speedy release cycle if it leads to a breach? Unsurprisingly, speed and security were at loggerheads, especially when a security check bolted onto the end of development processes could stop a release in its tracks.

Defining critical KPIs

Those conflicts helped create DevSecOps, where real progress has been made in ensuring both application delivery and security. DevSecOps harnesses the power of the cloud and cloud native platforms to automate infrastructure and platform provisioning as much as possible while also meeting both business and security objectives. The beauty of DevSecOps is that those goals are the same. 

Over time, DevSecOps will dramatically reduce the hours enterprises devote to resolving security issues. Time to resolution is a critical key performance indicator (KPI) — much more so than the number of defects. It’s also the most effective way DevSecOps programs can understand where they are improving and where they need to mature. And it helps create a common language between developers and security practitioners that lets them communicate across their natural divide and accelerate the resolution of issues as they arise.  

SecDevOps can easily focus on the wrong thing

But with SecDevOps, those metrics and even communication processes are not as important. SecDevOps believes all DevOps professionals should be security practitioners, which is a much different focus. To illustrate the difference, think of removing your shoes at an airport checkpoint. 

That process is designed for security, not speed. A SecDevOps solution might be to invest in developing better detection methodologies or requiring additional scanning or pat downs, while a DevSecOps solution would likely involve better planning and processing of passengers.

The point is to illustrate security-based decisions versus business-based decisions that encompass security concerns. The hazard there is that, if not careful, SecDevOps can incorporate a significant amount of security theater. In the real-world checkpoint analogy, how many actual explosive devices have been found? That is not to suggest we should stop monitoring for those threats, but it does illustrate how SecDevOps can easily focus on the wrong thing, namely raw vulnerability counts without the proper context to understand their significance. In other words, it’s about the prism, not the process.

When organizations first start moving towards a DevSecOps model, many are derailed by the sheer volume of vulnerability information that is returned by automated scanning tools. It takes significant expertise and experience to triage those and begin reducing technical debt.

Put simply, not every vulnerability is created equal. Context matters. Developers simply aren’t out-of-the-box security experts. That is not to say they lack the capability — security, like programming, is a discipline that requires its own dedication. Application security involves much more than just secure coding. There are simply too many complexities and too much disruption to think otherwise. 

For that reason, enterprises will find on a very human level that DevSecOps causes less churn than SecDevOps. We can pretend otherwise, but the psychology of the ‘Sec’ placement matters. 

Bottom line: transforming developers into security practitioners requires significant investments in both finances and focus for the training and tools necessary to make that happen. And it requires developers willing to embrace that change and learn the skills necessary to make it work.

Security means managing risk, not eliminating it 

Security is important enough to be treated as an equal player and integrated with DevOps processes, but that doesn’t mean that security is more important than business objectives. For organizations who protect information that could lead to the loss of life, security will outweigh business goals and objectives. But for most, DevSecOps will more than adequately address their security, delivery and business requirements. 

DevSecOps means delivering secure software inside of processes resilient enough to recover from inevitable vulnerabilities and attacks. It doesn’t mean that a critical security vulnerability won’t impact a delivery date — that’s not the purpose — but it does help ensure that a vulnerability in a non-critical location, such as one that resides in a non-internet facing application protected by a network firewall, won’t be treated the same as one that could lead to financial ruin.

At the end of the day, application security isn’t about eliminating risks, but managing them in a manner that both protects data and delivery schedules. Enterprises ultimately find that by moving to DevSecOps and including security at each step of the process, their applications become more stable, require less patching and can be released on a faster cycle. DevSecOps is a business enabler, not an insurance policy. While SecDevOps might claim to offer more protection, the costs of that protection are significant. Obviously, there are reasons for each approach. But when choosing between SecDevOps and DevSecOps approaches, make your decision carefully.