Full Lifecycle Cloud Security, Part II

by Jamie Gale on April 6, 2020

In the first part of this blog series, we described how both the prevention of risk during the continuous innovation/continuous deployment (CI/CD) process and the detection of risk at runtime paired with automated remediation are essential components of full lifecycle cloud security. In this follow up, we explore the longer term benefits of having a comprehensive strategy for cloud security during CI/CD. Let’s first recall some of the immediate benefits that we covered in part 1.

First and most evident, is that by preventing misconfigurations before they occur through the use of Infrastructure as Code (IaC) templates, you achieve much better security. Cyberattackers can’t take advantage of a misconfiguration that doesn’t exist. A second immediate benefit is the reduction of friction between security and developers. Engaging developers in the cloud security process during CI/CD (DevSecOps) reduces friction related to security and thus speeds up development efforts. This means the cloud is more secure and developers are more productive.

But there is another significant benefit of engaging developers in cloud security in the right place and at the right time. Developers are actually more likely to participate in the security process, which is vital to the success of cloud security. Let’s be honest, you need developers to be participants in the cloud security process to handle the scale and scope of cloud security.

Why? Because moving to public cloud (software-defined infrastructure) has democratized access to infrastructure. This self-service access to software-defined infrastructure means developers have the ability to build and deploy in real-time. Gone are the long waits and approval processes that once slowed innovation. But self service needs to go beyond creation to include remediation of issues. Security engineers can’t reconfigure every problematic cloud service on the fly because they don’t know the context of the application running on top of it or the other complexities that only the development team knows about.

What security engineers need is the ability to automate the process of getting developers to participate in the cloud security process. This allows security to scale and developers to be more productive (and really helps stop making security a four-letter word to developers). In this new world, security engineers are presenting security risks in the right place and at the right time by shifting cloud security left into CI/CD through evaluation of IaC templates. This shift should not only identify the risk, it should also communicate guidance on how to resolve the risk. Decision making is delegated to the lowest level possible, closest to the individuals affected most. Developers are empowered to participate, which means they are more likely to participate, and this becomes a virtuous cycle through which even better cloud security is achieved and achieved at scale.

Sponsorships Available

And yes, you still need the ability to detect and remediate issues that circumvent or slip through this process, but ultimately, by shifting cloud security left, you have fully embraced the cultural shift from “command and control” to “trust but verify” that needs to occur as part of the organizational transformation to fully embrace cloud.

This freedom further embraces and encourages individual participation in the process. From start to finish, all team members are involved in security. Through the non-invasive nature of how IaC prevents developers from introducing vulnerabilities into cloud infrastructure, their participation becomes seamless. Developers are guided toward compliance and security using the tools they want to use, receiving relevant security and compliance guidance within those tools, all while they are delivering their work with greater speed and ease.

If you would like to learn more about how DivvyCloud’s IaC Security capability delivers on this vision, contact us today.

Cloud Security Democracy