Despite all the industry attention around DevSecOps — the recent RSA Conference 2019 in San Francisco even devoted a full day to the topic — the buzzword is often met with shoulder shrugging inside most organizations.

How severe is the current disconnect between hype and reality? A newly released Deloitte survey of 500 C-suite executives with security responsibilities found 85% of respondents said they're using agile and/or DevOps practices in application development. 

Yet DevSecOps was ranked as the lowest security priority area.

It's not surprising that DevSecOps, a portmanteau of development, security and operations, is hitting some speed bumps on the road to the wide adoption.

This approach — integrating security into the full application lifecycle so it is a priority from the start, beginning with the development phase, rather than tacked on at the end — represents a massive process and cultural shift.

To put it in perspective, DevSecOps' predecessor, DevOps, has been around a few years longer and most organizations are still trying to wrap their arms around it.

DevOps is a significant change too. In the traditional application development structure, one team (Development) made the product and another (Operations) deployed it. The skill sets were different — one expert in programming, the other knowledgeable about servers and operating systems.

With DevOps, the teams are merged. While team members may primarily work on development or deployment, all team members must be aware of both sides of the equation or face extinction in today's world of high-velocity, continuously-delivered software.

DevOps is certainly a popular industry topic, but 10 years after the first DevOpsDays conference in Belgium, only 28% of companies have adopted "very mature" DevOps practices in all or parts of their organizations, according to a recent survey by CloudBees, Sonatype and Carnegie Mellon University's Software Engineering Institute.

The momentum is there  — that's up from 25% a year ago – but with fewer than three in 10 enterprises on board, there's still a long way to go.

DevSecOps demands a similarly dramatic mindset change. In the post-DevOps world, organizations have an engineering team (DevOps people) and a security team (those who perform compliance audits, security scans, etc., but are isolated from details about code deployment).

The DevSecOps model calls on the DevOps practitioner to also know how to run the security scans and interpret the results.

In the future, if a security person only knows how to run scans, they will become irrelevant. Instead, security teams will be expected to be consultants to the DevSecOps teams by providing guidance, best practices and help with mitigating difficult vulnerabilities.

DevSecOps makes too much sense not to gain wide acceptance in the coming years. It simultaneously addresses two needs: stronger cybersecurity defense and agile, rapid software development.

But DevSecOps doesn't happen overnight; it takes time and dedicated re-orientation.

Here are three tips for getting started on making DevSecOps a reality in any organization:

Train, train, train 

Since DevSecOps is in its infancy, there's little point in looking for people with DevSecOps experience — they don't yet exist.

The only realistic option is to have an aggressive training program for DevOps people to integrate vulnerability scanning and insights into the application development process.

Expect pushback

Don't be surprised by this initial reaction from the DevOps people: "Wait a minute, there's a whole security team. Why do I have to spend time on security scans and compliance tests and baking security into the model when I can just have someone else come in and audit it?"

Be prepared to address these understandable concerns.

The explanation is pretty clear: When an organization releases code every three months or so, the old ways are fine.

Now, with new code released every week or every day, it's not workable to call the security team and say, "Hey, we are about to release code. Could you take a look at it and tell us if it's secure?" That's too slow and there aren't enough security people to handle the load.

It's important to convince people that once they go through the training, the organization ends up with a much more efficient and secure way of dealing with code deployment.

Set clear lines of responsibility. 

A trap that is easy to fall into is to ask the DevOps team to run scans but still have the security team ultimately responsible. DevOps people will sheepishly run the scans because they're expected to, but will pay little attention to the process or results.

That undermines the agility and stronger security that DevSecOps is supposed to promote. It's important to have responsibility lie with the newly minted DevSecOps people.