The purpose of this post is to illuminate one of modern cloud computing’s most crucial concepts and relate it back to the tools and tech available in Azure. Here at OpsCompass, we enjoy a unique perspective because our SaaS product, Helm, is a cloud-native app living in Azure that we operate and secure to meet customer demand.  However, another reason stems from the fact that our customers use Helm to drive their own cloud scenarios in Azure through continuous, automated cloud operations.

It is nearly conventional wisdom in the C-suite that: 1) digital transformation is the desired outcome, 2) that cloud transformation is necessary to get there, and 3) DevOps is how it will happen. But few decision makers can meaningfully define these admittedly nebulous (pun intended) terms.  The word ‘transformation’ is especially apt as the capabilities and nature of the cloud force organizations to truly transform how they consume IT going forward.

This re-thinking of technology for a cloud-first world has manifest itself in waves of trendy yet widely adopted mixes of disciplines, methodologies, and processes such as Site Reliability Engineering (SRE), DevOps, and Lean. In this case, trendy is not meant to mean pejorative.  Instead, it characterizes how the quickly evolving shifts in how technology is built and utilized has had a material impact on the nature of cloud adoption for real-world companies across industries.

One emerging cloud concept that follows this “trend” is DevSecOps, the topic of today’s blog.  DevSecOps grew out of enterprise utilization of the public cloud and the operational and regulatory compliance requirements that so often accompany the most common cloud scenarios.  DevSecOps is an excellent illustration of how companies using a lot more cloud creates underlying operational and regulatory requirements that are unfunded and stretch key company resources.  It also illustrates an opportunity for organizations to take simple steps to lay the foundation for long-term cloud success.

DevSecOps is exactly what you might think; DevOps with some security in it. But, the key here is to understand that DevOps is as much a philosophy and a directional approach as it is a set of particular technologies.  So it should follow that DevSecOps is simply the core DevOps philosophy applied to IT security, right?  Not quite, because in DevSecOps, security becomes a distinct third pillar and core domain like Dev and Ops.

In other words, DevOps isn’t necessarily applied to security, security gets injected into DevOps. So it’s security, not DevOps, that get’s a new set of tools and necessitates an evolving perspective. This means that building secure cloud tools is not an isolated function but a component of the DevOps processes.  Through this integrated effort, multiple departments and stakeholders from development, to IT, to security, and even the operating business units, collaborate to deliver consistently secure and integrated software.

At a high level, a cloud-native DevSecOps approach should have the following characteristics:

  • Templated Infrastructure – secure infrastructure is defined in consistent templates.
  • Policy as Code – policies are applied as code through infrastructure templates or the API.
  • Continuous Automation – processes such as CI/CD, configuration inspection, or threat assessment should be continuous.
  • Event-driven – actions occur and response is immediate and automated.

Organizational cloud transformation does not happen overnight.  Companies struggle with where to begin the transformation – paralyzing the process through no ill will, but simply organizational malaise.  To move more quickly, companies need to recognize that DevOps and DevSecOps are organizational in nature, meaning that breaking down organizational walls between teams is as important as building slick new automation.

But to help facilitate organizational engagement, we recommend an incremental approach with a small and simple start.  This smaller step approach has helped companies succeed in their cloud transformation strategy.  Thus, the best practice is for companies to take a small step to ensure early success.  Following this early success, the team can work to make incremental improvements. In other words, by letting the teams coalesce around the early, simple projects that focus on cloud foundations and best-practices, successful companies are seeing tangible, early cloud return on investment (“ROI”) as well as establishing a platform for the future.

The Azure DevSecOps stack

Tooling is a central component of DevSecOps and in the cloud many of the tools are built into the respective platforms. Whether it’s Azure or AWS, there are distinct scripting languages, API’s, and services that must be leveraged to truly have a secure and production-ready environment. Below is the Azure DevSecOps stack that we leverage internally. We use scripts to configure the things we’re going to build using the Azure Resource Manager API; and then focus our continuous operations on specific, high risk components of the cloud environment.

The Azure DevOps Stack


To an organization already mature with regard to DevSecOps this example may seem simplistic, but it’s these simple projects that introduce early integration and automation that help define future cloud success. Building upon a good start is exciting and tackling things like deeper, automated threat detection, compliance, and continuous assessment are natural next steps in the DevSecOps journey.

Like what you see? Try OpsCompass for free!

Get started right now by signing up for a free trial of OpsCompass. Or, learn more with a live demo.