How to explain DevSecOps in plain English

DevOps transformed how many IT groups build and maintain software. DevSecOps – development, security, and operations - changes how they secure that software. Here's how to explain DevSecOps to anyone
322 readers like this.

Just as DevOps transformed how many IT shops build, deploy, and maintain software,  DevSecOps – short for development,  security, and operations – is changing how they secure that same software.

As the closely linked terms DevOps and DevSecOps suggest, there’s a lineage here.

“DevSecOps is building upon DevOps, the practice of combining software development with more traditional IT operations,” says Sean Wright, lead application security SME at Immersive Labs.

What is DevSecOps?

At its core, DevOps removed the traditional walls – whether physical, cultural, technical, or all of the above – isolating development and operations teams from one another.

“The intent was to reduce the time it takes to get changes and updates into production, ultimately allowing organizations to become more agile,” Wright says.

It’s as if DevOps teams, once their efforts began to bear tangible and recurring results, had an epiphany: “Hey, we should invite security to this party!”

DevOps and security pros recognized an opportunity to embed security more proactively throughout the software delivery pipeline. Enter DevSecOps.

To be fair, the early days of DevOps didn’t forget security. Rather, DevOps and security pros later recognized there was a bigger opportunity to embed security more proactively throughout the software delivery pipeline.

“Early discussions and written works about DevOps make it clear that security was always an essential component of this vision,” says Red Hat technology evangelist Gordon Haff. “However, as time went by, it became clear that the integration of security often lagged and that it would be useful to treat it more explicitly. Hence DevSecOps.”

[ What DevSecOps tools might your team consider? Read also: 5 DevSecOps open source projects to know. ]

How DevSecOps makes security everyone's job

DevOps practices work to share responsibilities more evenly and reduce finger-pointing and toxicity. Developers shouldn’t just assume someone else will fix a production problem caused by their code, for example, and Ops pros might be more likely these days to learn a programming language or two, especially if they’re well-suited to automation.

DevSecOps also means building a culture of shared responsibility.

DevSecOps extends the same basic principle to security: It shouldn’t be the sole responsibility of a group of analysts huddled in a Security Operations Center (SOC) or a testing team that doesn’t get to touch the code until just before it gets deployed.

That was the dominant model in the software delivery pipelines of old: Security was a final step, rather than something considered at every step. And that used to be at least passable, for the most part. As Red Hat's DevSecOps primer notes, “That wasn’t as problematic when development cycles lasted months or even years, but those days are over.”

Those days are most definitely over. That final-stage model simply didn’t account for cloud, containers, Kubernetes, and a wealth of other modern technologies. And regardless of a particular organization’s technology stack or development processes, virtually every team is expected to ship faster and more frequently than in the past.

At its core, the role of security is quite simple: Most systems are built by people, and people make mistakes. (Even automated systems typically require human builders and maintainers.)

If your security practices lag behind as your software development accelerates, then your risks are likely to increase.

Enter DevSecOps, which brings security more proactively into the fold at every phase of the software pipeline.

“DevSecOps isn’t necessarily limited to containerized cloud-native environments,” Haff says. “However, the concept of rapid, iterative development is inherently better paired with loosely coupled microservices architectures than it is with large monolithic applications that have many dependencies and long test cycles.”

DevSecOps also means building a culture of shared responsibility – which means you need to be ready to explain DevSecOps to people. Here are some more definitions you can use.

3 DevSecOps definitions to use

  • “DevSecOps stands for development, security, and operations. It’s an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle.” –redhat.com
  • “DevSecOps is the practice of embedding security within this established practice [of DevOps], baking security into an organization’s delivery of software changes. It often relies heavily on automation to help drive efficiency, as well as speed of delivery.” –Sean Wright, lead application security SME at Immersive Labs
  • “DevSecOps, nee DevOps, is a term that traces its roots back to a 2014 book called More Agile Testing. In the past seven years, DevSecOps has quickly become the Greek God Proteus of technology terms and, like its namesake, now means ‘versatile,’ ‘mutable,’ or ‘capable of assuming many forms.’” –Jerry Gamblin, director of security research, Kenna Security, now part of Cisco.

[ Want more detail on DevSecOps and its benefits? See What is DevSecOps? ]

How is DevSecOps implemented?

Just as with DevOps, you can’t just say “we’re a DevSecOps team” now and pat yourself on the back. Whether you’re starting from scratch or extending an established DevOps practice, DevSecOps is not simply a matter of adding a particular tool or role.

Our sibling site, opensource.com, has a great breakdown of how to adopt DevSecOps successfully – consider it recommended reading.

As Gamblin notes with his Proteus comparison, DevSecOps is adaptable – so long as you’re operating on the principles of embedding security at every phase of your software lifecycle. Some organizations are even building DevSecOps teams.

“In many organizations, DevSecOps means a single team responsible for end-to-end development, security, and delivery of a system with no or little help from any other group,” Gamblin says. “A whole class of tooling has been built around it to help people who are often generalists provide both secure and stable systems while not needing extensive specialist knowledge.”

[ Also read 8 DevSecOps pitfalls to avoid. ]

In any iteration, automation is as critical to DevSecOps as it is to its DevOps roots. For a specific example, think processes and tools like automated vulnerability scans of container images. The idea is to ensure “strong security” doesn’t mean “dumping untenable workloads on people.”

DevSecOps is also an emerging area (like DevOps before it) where cross-functional experience and skills are likely going to pay off on the job market, too. No matter an organization’s particular implementation, there will likely be some bumps in the road – people who can navigate them will be valuable.

[ How do containers and Kubernetes help manage risk? Read also: A layered approach to container and Kubernetes security. ]

Kevin Casey writes about technology and business for a variety of publications. He won an Azbee Award, given by the American Society of Business Publication Editors, for his InformationWeek.com story, "Are You Too Old For IT?" He's a former community choice honoree in the Small Business Influencer Awards.