Overcoming Obstacles to Transformational DevOps: Security and Compliance

In my role, I get to talk to a lot of executives looking to transform their software and IT delivery organizations by using DevOps principles and practices. While most are generally excited about the benefits of DevOps (e.g., faster time to market, improved quality, reduction of security issues, increased employee morale, etc.), many leaders are skeptical that it will work in their environment. I hear the same set of concerns and objections in every meeting. But, in my experience, the promise of DevOps can be achieved in almost every situation as long as organizations are fully committed to it.

In this blog series, I will capture some of the most common objections and demonstrate how DevOps principles and practices have helped other companies facing similar problems achieve their goals. I will also outline some key strategies to help your organization get past these objections.

Common Objections

As I said above, I often hear the same set of concerns about DevOps transformation from leaders at different companies. The most common objections are:

• We have security or compliance requirements that prevent us from using DevOps.

• Our people don’t have the skills to work in this environment.

• Our workforce requires training and cannot move that fast.

• We don’t have time to do all the “re-tooling” required.

• We’ve already tried automating X (e.g., deployments, testing, etc.) and it didn’t work.

• That’s for high tech, internet companies.

• We use mostly third-party software or legacy solutions.

In this blog post, I will cover the first objection. Over the next three weeks, I’ll discuss the other six and finally end with a summary of the recommendations to accelerate your DevOps journey.

Security and Compliance

Without a doubt, security and compliance concerns are the number one objection I hear to implementing DevOps. This has always confounded me since the data illustrates that DevOps high performers spend 50% less time remediating security issues (see 2017 State of DevOps Report). Why? DevOps encourages “shifting left on security,” that is, considering security concerns as early in the solution delivery process as possible.

We think of this approach as “building security in” versus “bolting it on.” For example, rather than having developers build an entire application and then having the security team review it, security is involved from the beginning to provide patched OS images, approved libraries, etc. Automated tools identify common security vulnerabilities with every compile, not just with each major release. By building reusable, secure patterns, these practices can become integrated into the software delivery lifecycle without slowing down developers.

This is also true from a compliance perspective. Automation gives regulators and auditors a way to validate that the same testing or deployment steps are performed consistently—manual processes provide no such guarantee. When combined with cloud-based solutions, automation also reduces the need for individuals to access protected environments, improves testing of security-related changes, and guarantees a record or log of all activities and changes.

Key Strategies

So, how do you get over these objections? How do you get security and compliance organizations to embrace DevOps? How do you get development teams to “bake in” these requirements without slowing the pace of delivery? Well, I’ll admit it’s not easy. It involves a lot of cultural and process changes. But here are some key strategies we have found to be helpful

• Executive sponsorship: DevOps transformations require more than just support from leadership. They require a commitment to work through the challenges and hold people accountable for achieving results. In some instances, we have seen executives incorporate DevOps milestones and metrics into their leader’s objectives (e.g., revenue impact of reduced mean time to repair).

• Iterative and incremental approach: Transformational efforts must have quick wins to develop momentum or they die out. Rather than spending months trying to automate all aspects of security and compliance, we recommend starting with small efforts that show tangible, measurable results and then building on these successes and lessons learned. For example, develop a resource “catalog” that allows individual teams to self-provision cloud infrastructure from a set of security-approved “templates.” This simple step can help cut significant time out of the delivery life cycle, building momentum and freeing people’s time to focus on additional improvements. Other quick wins might include automating code reviews or automating privileged access management.

• Cross-functional teams: Security, compliance, infrastructure, and developers have traditionally been separated by organizational silos—they interacted only through structured handoffs. This approach leads to long delays, lack of communication, and misaligned priorities. Integrating all required resources into cross-functional teams helps ensure security and compliance needs are addressed throughout the product development lifecycle.

Summary

DevOps is proven to help organizations improve their security and compliance posture, when executed well and with strong buy-in from executive leadership. You don’t have to “boil the ocean”—instead take an incremental approach to improvement, measure the results, and repeat. Hopefully, this blog post has provided those concerned about security and compliance with a different perspective. In the next blog post, we will consider the common “people” objections to DevOps:

• Our people don’t have the skills to work in this environment.

• Our workforce requires training and cannot move that fast.

• DevOps
• Cyber Security