This article is based on a sponsored piece originally published on devclass.com, featuring commentary from Guy Eisenkot, co-founder and VP of Product at Bridgecrew.
The DevSecOps Promise vs. Reality
For several years, DevSecOps has been positioned as the answer to a persistent problem: how do you ship cloud applications quickly without compromising security? The traditional approach — retrofitting complex security policies onto a hierarchical development pipeline — simply doesn’t scale in a world of rapid, collaborative cloud development.
The DevSecOps model proposes a cleaner solution: bake security into the software development lifecycle from the earliest stages. Instead of a separate security team reviewing finished work, every developer becomes a security stakeholder. This “shift left” philosophy is designed to be preventative rather than reactive — catch problems at the source, and you spend far less time firefighting later.
In theory, this makes particular sense on cloud platforms that assume rapid deployment, distributed teams, and continuous delivery. There is no longer a hard boundary between the development team, the security team, and the operations team. In practice, however, “shift left” is more talked about than actually practised. Many organizations have adopted the terminology without making the cultural or tooling changes required to back it up.
The Governance Gap in Cloud Development
One of the core challenges is visibility and control. As Guy Eisenkot, co-founder and VP of Product at Bridgecrew, puts it:
“There is a lack of control in this model. With the shift into cloud development and the fact that coders can always get a better answer on Stack Overflow and GitHub, it’s become practically impossible to track the supply chain. It’s a governance problem.”
Security has become a focal point of continuous development, but it remains a work in progress alongside competing priorities like performance and new features. And crucially, the available tools — while useful — are not sufficient on their own.
Consider a common scenario: an Elasticsearch cluster is inadvertently left in a publicly accessible state. Under a traditional hierarchical model, a security scan flags this issue and sends it to a ticketing system, where it may sit for hours before someone with the right access resolves it. The more effective approach is to surface this misconfiguration as part of the CI/CD pipeline, pushing an immediate alert to the team that introduced the error. Remediation can then happen at compile time rather than at runtime — preventing a potentially serious exposure rather than scrambling to contain one.
“It’s not simply that the tools are not enough — it’s that too many of them are reporting alerts and sending them to Slack channels, Jira tickets, and other queues instead of going to a developer’s desktop and CI tools.” — Guy Eisenkot, Bridgecrew
Infrastructure as Code: A Double-Edged Sword
Infrastructure as Code (IaC) is often cited as the mechanism that makes security “everyone’s business.” By turning the provisioning of cloud and data centre services into machine-readable code — bundled into automated workflows or templates — IaC removes the need for manual configuration steps and fragmented console tools.
Tools like Terraform, Chef, and Puppet have become central to this model. IaC configuration can be pushed directly to servers or pulled via a configuration server to a cloud provider’s infrastructure. Terraform, for example, typically treats resources as immutable: rather than modifying an existing setup, it tears down and rebuilds the resource from scratch.
But IaC introduces its own risks. The same mechanisms that give developers extraordinary speed and freedom also make it easy to embed security misconfigurations at scale. According to analysis by Bridgecrew, at least four in ten IaC templates contain a misconfiguration that can slip through into runtime vulnerabilities. The tools to provision cloud infrastructure have been successfully decentralised — but the expertise required to manage that provisioning securely has often remained centralised and is therefore becoming less effective as teams grow.
As Eisenkot explains, deployment velocity compounds the problem:
“It suddenly doesn’t take six months to deploy a change to an application — it takes a few minutes. This speed is a blessing in disguise because it creates challenges when we deploy software very fast. Where do we make the compromises?”
The Blind Spots in Modern Cloud Architectures
A particularly difficult challenge is that compliance and risk managers often cannot see what is happening across environments where developers have been given broad, often necessary freedoms.
“There are blind spots. How do you ensure you know what’s going on in your environment? The idea that we know everything that’s going on in our architecture is an assumption we can’t make any more.” — Guy Eisenkot
This plays out in mundane but consequential ways. Older IaC templates — some dating back years — may encode practices that are now considered insecure. Encryption at rest, for instance, was not enabled by default in some database packages until relatively recently. Surfacing these historical misconfigurations through automated scanning can yield quick wins on day one of a security improvement initiative.
What a Practical DevSecOps Platform Looks Like
Bridgecrew’s approach illustrates one way to bridge the gap between intent and practice. Rather than adding another alert queue, the platform is designed to integrate directly into the developer’s existing workflow — scanning IaC templates for misconfigurations and policy violations before errors reach deployed infrastructure, and issuing pull requests to surface issues where developers are already working.
Key capabilities in this kind of platform include:
- Build-time scanning: Identifying IaC misconfigurations and policy violations during the build phase — before they reach production infrastructure. This also enables the generation of compliance reports against standards such as PCI DSS.
- Cloud integration: Connecting to AWS, Microsoft Azure, and Google Cloud Platform, as well as scanning configurations expressed in CloudFormation, Kubernetes, and Terraform.
- Read-only deployment model: The platform can be deployed by running a CloudFormation or Terraform template on the target cloud account, which creates a read-only role. This enables scheduled scans of configuration states and continuous evaluation without requiring write access to production environments.
- Playbooks and remediation scripts: Automation that addresses common problems across cloud platforms, reducing the number of manual steps required to resolve a known class of misconfiguration.
Playbooks have real-world limitations, however. In highly automated cloud deployments, a change applied by a playbook can be inadvertently reversed by a subsequent automated change. Remediation therefore needs to be integrated at the pipeline level, not applied as a one-off fix.
Open Source Tools Supporting IaC Security
Bridgecrew has contributed several open source tools to this space:
- Checkov: A static analysis tool for IaC that scans Terraform, CloudFormation, and Kubernetes configurations for misconfigurations.
- AirIAM: An AWS Least Privilege Terraformer that generates a Terraform template designed to reduce IAM permissions to the minimum required — limiting the blast radius of a compromise.
- Terragoat: A deliberately vulnerable learning environment for experimenting with secure cloud configuration pipelines — useful for training developers to recognise common mistakes.
The Technical Challenges of Scanning IaC at Scale
Scanning IaC templates accurately is harder than it sounds. Eisenkot is candid about the complexity involved:
“It becomes extremely complicated when trying to build a data model that depicts how configuration will eventually manifest based on the prescribed plan. It is imperative to extract its variables and dependencies against the entire code base. Without this step, scans could result in both false positives — configurations that don’t extract all their dependencies — or false negatives that are not identified due to misinterpretation of the IaC plan.”
This highlights an important point for teams evaluating IaC scanning tools: a tool that produces too many false positives will be ignored by developers, while one that misses real issues due to incomplete dependency resolution can create a false sense of security. The quality of the underlying data model matters as much as the scanning rules themselves.
Beyond Tooling: Education and Culture
Ultimately, Bridgecrew’s experience points to a lesson that applies more broadly across DevSecOps: giving developers a new tool to detect bad decisions is only part of the solution. The more durable fix is education — helping developers understand why certain configurations are dangerous and how to make better decisions before writing the code in the first place.
“We learned that it’s not only about giving developers the panic button, but we also had to educate them on making the right decisions when building new infrastructure in the public cloud.”
By surfacing misconfigurations at the pull request or build report stage — with actionable guidance on how to fix them — teams can address problems before they reach production rather than after. This changes the developer’s relationship with security from a compliance burden to an integral part of the build process.
Key Takeaways for DevOps and Platform Teams
- “Shift left” only works if security feedback reaches developers in the tools they already use — not in a separate queue or alert channel.
- IaC accelerates both delivery and the spread of misconfigurations. Automated scanning at build time is essential, not optional.
- Compliance and risk visibility requires read access across the full cloud environment, including historical templates that may encode outdated practices.
- Static analysis tools like Checkov help, but their accuracy depends on correctly resolving variable dependencies across the entire codebase.
- Playbook-based remediation is a useful starting point, but must be integrated into the pipeline to survive subsequent automated changes.
- Developer education — not just tooling — is the most durable investment in reducing cloud misconfiguration risk.
In a relatively short time, the cloud has evolved from a powerful enabler to a source of significant operational risk when poorly governed. The answer is not more security tools bolted onto an existing workflow — it is a deeper integration of security as both a practice and a mindset throughout the development lifecycle.