Three ways to overcome cloud DevSecOps bottlenecks

In part one, we talked about how the “shift left” movement has lagged when it comes to cloud security. DevSecOps is intended to create processes and knowledge to share between engineering and security teams, but it can also create more work and friction. Here are some of the reasons why:

• Conflicting goals and strategies between DevOps and security.
• Unclear and inconsistent policy governance between infrastructure code and deployed cloud resources.
• Skills and access gap when it comes to identifying and fixing misconfigurations that may lead to cloud risk.

Those bottleneck-causing challenges aren’t trivial. They’re the result of deep-seated processes and tooling that support DevOps and security individually, but not collectively. They’re also the byproduct of the rapidly evolving infrastructure landscape, and no single tool or technology can make them disappear. We at Bridgecrew see these challenges as opportunities and believe that we already have many of the solutions to overcome them.

In this post, we’ll share how to use existing methodologies to effectively shift cloud security left.

Automate everything

You’re probably automating much of your software testing—from unit testing to dependency scanning—and cloud security should be no different. It’s completely unrealistic to expect even the most seasoned security experts to stay up to date with every security best practice for every cloud provider, service layer, orchestration platform, resource, etc., and apply it back to your specific architecture. Automated scanning is the only way to do so comprehensively, without spending inordinate amounts of time and resources combing through documentation and compliance standards. There are plenty of commercial and open source tools available to scan for known misconfigurations in your cloud resources (we’re big fans of open source tool Prowler) and provisioning frameworks (including our own open source tool Checkov).

However, automation can end up creating more friction, as we mentioned in part one of this series. Although better visibility and understanding of your cloud security posture is overall a plus, it has to be in service of efficiently improving your posture over time. Without actionable feedback, automating the identification of issues will just result in more work—or at least more tickets that may or may not turn into scheduled work.

To bridge the gap between code and security, finding the right tooling to automate the identification of issues is imperative—but applying that same methodology to fixing issues is even better. We’ll go one step further to say that applying automation to preventing issues from occurring in the first place is even better still.

Provision in code, secure in code

A lot of DevSecOps friction comes from the historically reactive security mindset, that aims to protect against outsider threats rather than prevent issues from the inside. That couldn’t be more true for cloud security, where much (if not all) monitoring had to happen outside of internal development processes. Now, with the rise of provisioning frameworks like infrastructure as code, we can start to flip that mindset into a proactive approach.

Taking a preventative versus reactive approach will not only put consistent guardrails in place, but will also harden your infrastructure over time and save you resources in the long run—by preventing misconfigurations from being deployed in the first place.

To do that, however, policies need to be translated to code, enforced in code, and delivered in code.

Whether you call it policy-as-code or security-as-code, translating governance automation to a common language equips both security practitioners and DevOps engineers with actionable solutions. Delivering fixes to misconfigurations and policy violations, instead of tickets, has the ability to alleviate cloud DevSecOps bottlenecks—which has long-term positive effects. Enforcing policies at the code layer ensures that cloud security is consistently applied and enables it to scale throughout the environment over time.

Leverage your existing processes

But surfacing even the most actionable feedback at the wrong time in the wrong place can be noisy at best and disruptive at worst. The only way to make DevSecOps in the cloud accessible and readily adopted is by embedding it into the tools and processes developers depend on every day. Luckily for us, the key to embracing automation and security-as-code is already likely in place.

Although there’s no one-size-fits-all solution for every organization, making your automated checks a required part of every code review is a great way to leverage existing workflows to encourage the adoption of cloud DevSecOps. Governing policies from within your CI/CD pipeline, or surfacing feedback on commits and pull requests, is a great way to enforce guardrails and surface actionable feedback.

How you use that feedback is up to you and should be contingent on your cloud DevSecOps maturity. Ideally, you want to get to a point where misconfigured infrastructure code is blocked from being merged, and you have loops in place to quickly implement remediations before deploying—much like you probably already do when your integration tests fail a build.

Conclusion

By automating cloud security, delivering it as code, and integrating it into developer workflows, you can make it accessible to the people who can be most effective with it. The goal of shifting cloud security left isn’t to turn your infrastructure engineers into security experts, but to make it easily digestible and make sure it never slows down your DevOps processes. In that way, you can ensure that cloud security is addressable and adopted by the people who can have the biggest impact on it.