Skip to main content

Why You Should Rethink Your Cloud Infrastructure Security

By August 12, 2021November 1st, 2023Blog, Community

Contributed by Ulrica de Fort-Menares, Indeni (not a CDF Member)

The shift to cloud native technology has changed the way cloud infrastructure is deployed today. With Infrastructure as Code (IaC) and full automation going mainstream, organizations are adopting the GitOps concept. GitOps is a way of implementing Continuous Deployment for cloud native applications. It focuses on a developer-centric experience when operating infrastructure by using tools developers are already familiar with, including Git and Continuous Deployment tools. With GitOps, developers can seamlessly develop and deploy cloud environments in a matter of minutes. This level of independence empowers organizations to deploy infrastructure faster than ever. 

While GitOps promises unprecedented speed for infrastructure deployment, security is often viewed as the bottleneck, ultimately slowing down application delivery. According to a recent report by Trend Micro, cloud misconfiguration is the number one cause of cloud security issues. The report reveals 230 million cloud misconfigurations occur every day, proving this risk is widespread. The stakes are high; one misconfigured cloud storage is all it takes to endanger millions of records being exposed. Organizations must ensure that the configuration of their cloud resources is secure by design. The challenge organizations face is to maintain the balance between governance and speed. 

The friction between security teams and development teams is ongoing in many organizations. Developers have extremely demanding schedules and are often frustrated with the security gates slowing down the delivery pipeline. The security teams are typically risk-averse and are often misrepresented as inhibitors to innovation. 

Does it have to be this way? Let’s look at a few reasons why this situation occurs and whether this challenge is warranted.

1 Legacy Approaches to Security Programs Are Too Late

According to the ATARC (Advanced Technology Academic Research Center) Federal DevSecOps Landscape survey, security is one of the top three causes for deployment delays. All too often, organizations tack on security scanning towards the end of the delivery process. Developers are typically required to get in line and submit a security scan after the production environment is spun up. If security issues are found, developers have to spend significant time and energy investigating these issues. This is a frustrating experience for development teams with insane deadlines. Developers use IaC to develop and deploy cloud infrastructure. From the developer’s perspective, the task is simple since it is typically a few lines of code to spin up a resource. Yet they have to waste additional cycles at the last minute on what they thought would be a trivial task. Uncovering issues late into the cycle frustrates developers and creates friction between them and the security team. 

2 Context Switching Is Disruptive to Developers

Context switching is expensive for developers who constantly do focused work. Every time you switch tasks, you lose the momentum as developers take time and effort to get into focus again. You don’t want to bother your developers with security issues that happened a few sprints ago. Instead, you want to provide immediate feedback when the code is complete, so they can stay on the same task within the same sprint. 

3 Expensive to Fix After Deployment 

Fixing a security issue after the resource has been deployed in the cloud can be extremely costly. For example, if you create a database without enabling encryption at rest, you need to destroy the resource and rebuild it from a backup. This translates to production downtime, performance impacts, and lost time on the sprint where you could have been delivering business value. Chances are, you are likely not going to fix the issue. You can read this cloud encryption blog for more insight. Encrypting your database in AWS is easy if you haven’t provisioned it yet. Ideally, you want to catch the issue before the resource is deployed.  

4 Challenges Providing more Autonomy to Developers

With GitOps, developers are beginning to take responsibility for infrastructure and release. Developers own both the application and infrastructure stack. This new way of product deployment gives unprecedented autonomy to developers enabling them to deliver products faster than ever. The lag time between making a request for infrastructure change and it actually being deployed vanishes. It seems counterintuitive to have to go through the security team for security reviews. To make the matter worse, humans are too slow and the problem is exacerbated by the security skill gap. Meanwhile, the developer teams would have to prioritize the critical issues in their sprints, leading to the context switching challenge described above. What if we could just automate the security review step altogether? While ensuring the configuration of their cloud resources is secure from the start and achieve continuous security?

Rethinking Cloud Infrastructure Security

The GitOps concept is creating a great opportunity to bridge the gap between the security and development teams without slowing down delivery and with a “security by design” approach. As you start to treat your infrastructure like code, you can apply the same disciplines and quality gates that are used to manage applications to the cloud infrastructure. You can enjoy the many benefits from the core practices of DevOps such as version control, CI/CD, and security testing. By incorporating security scanning into the CI/CD pipeline, IaC will be automatically evaluated for security impacts early in the development process. This enables immediate feedback to developers so they can remediate the misconfiguration quickly. You can also stop the pipeline if a critical security issue is detected, thereby preventing an insecure infrastructure from being deployed. Effectively, you are taking a more continuous approach to detect non-compliant issues for cloud infrastructures. When a cloud asset is about to become non-compliant, you can detect that in code so you can mitigate the issue instantly,  maintaining a tight security posture. In the world of continuous everything, you can now achieve Continuous Compliance.

As more developers are owning the infrastructure stack, you want a developer-centric tool that integrates IaC security scanning into the application workflow. Developers are more likely going to adopt security if it is part of the workflow especially if it is integrated with a tool that they are already familiar with. This way, security will just happen even if you have a very tight timeline. 


In the race to launch applications faster, you should adapt your security tooling to the GitOps style of infrastructure deployments. Adopting a preventive cloud security strategy is key to scaling your cloud deployments. It is time you take the appropriate preemptive steps to remediate misconfigurations. This way, you can effectively stop security risks before they manifest themselves in the cloud.