The Cloud Security Problem Nobody’s Talking About

Lukasz Jagiello
VP of Engineering and Founder
Mar 5, 2025
If you were to tally up all of the data breaches in history and rank the factors that caused them, bad password security would probably be near the very top of the list. It doesn’t really matter how secure your system is, once account credentials leak, you’re cooked. And credentials are historically very prone to leakage.
The thing is, password security isn’t complicated. It’s simple: store your passwords using good encryption, use long strings, avoid easily guessed patterns, and never use the same password for multiple logins. Everybody knows this. Everybody has always known this. And yet for most of the history of computers, the bulk of users have still secured all of their accounts using things like their cat’s name followed by their birthdate.
Better education didn’t solve this. Requiring frequent password refreshes didn’t solve it. Even hard-coded password complexity requirements didn’t solve it—users just added more zeros to the end of their easily-guessed passwords. The industry tried these kinds of solutions for more than a half century and the only thing to show for it was a higher account lockout workload for IT.
You know what actually started to fix password security? Widespread adoption of password managers. This is because a password manager does something that no other solution ever did—it makes doing things right even easier than doing them wrong.
It turns out that password security was a user experience problem masquerading as a technology problem.
Cloud Security’s User Behavior Problem
I bring this up because cloud infrastructure security is actually very similar. While the modern cloud can get very, very complicated, the things we need to do to keep each resource safe are clearly defined and often surprisingly simple.
It’s basic stuff: secure access through channels set up according to best practices, proper permissions scoping, robust logging and transparency. And yet somehow it isn’t happening. According to SentinelOne, more than a quarter of companies have experienced a breach in their cloud infrastructure, and slightly less than a quarter of those breaches happened because a cloud resource was misconfigured. The number one reason that happens? User error, accounting for 82% of all misconfigurations.
The challenge isn’t doing this right, then. The challenge is doing it right every single time, across an organization where hundreds of developers will create thousands of environments each year, with varying levels of expertise and oversight. It’s user behavior.
As we learned with password security, there’s only one way to solve user behavior problems at scale: you have to make it so the right way to do things is also the easiest way to do things.
When you put the problem in those terms, you start to understand why cloud infrastructure security is still an issue, even with Infrastructure as Code (IaC) well on its way to the mainstream. It’s because IaC on its own really only gives us the first part of a solution: it lets us define “the right way” to set things up in code so that repeatability is no longer an issue.
But you still need people to find the right configuration file, understand it well enough to supply the correct data, and to deploy it without error. In a truly self-serve environment, some parts of the security puzzle—especially credentialing and visibility—can actually get more complicated. Until you can make all of this easier than bashing something together with scripts or just asking DevOps to do it for you, half-assed cloud security will proliferate.
You need a better user interface for cloud infrastructure.
You need something like Tempest, in other words.
How Tempest Levels Up Cloud Security by Solving Developer Experience
Tempest is designed to take all of the boilerplate, credential-wrangling, and oversight headaches that typically plague a cloud environment and hide them behind a simple set of buttons, forms, and automated workflows.
This isn’t simply a menu of black box, prebuilt configurations—DevOps defines how things should be configured themselves using a combination of our first-party integrations and their own code, and this can get quite intricate. But most of the complexity is fully abstracted from the user. For them, it really is almost as simple as “push button, get environment.”
That way, instead of digging around in a repository to locate the right OpenTofu file—or, worse, hacking together ad-hoc bash scripts—developers can simply select “Create EC2 instance” (or “Create Database” or “Deploy new microservice to Kubernetes cluster.” etc.) and Tempest handles the rest. We only ask for as much user input as is necessary to create a resource, and you can even compose multiple different apps into your workflows to create as complicated an environment as required. All of those crucial security configuration steps—role-scoped credentials, encryption in transit, best-practice ports and policies—are baked right into the form, so end users don’t need to think about them.
Because Tempest is multi-cloud and extensible by design, you can do this on AWS, Google Cloud, or your own private environment. You don't even need to design new automations if you're already doing IaC—wrap your existing .tf or .yaml files in a Private App, and they become exactly like a first-party integration in Tempest, freely composable into whatever pipeline you need. The underlying infrastructure is still fully yours; Tempest just makes it so that spinning things up the right way is easier than doing it the wrong way.
This is a user experience win, of course. Developers love being able to just skip straight to coding without the associated ops and security burden they take on when they have to build and manage everything from scratch. But it’s even more transformational for security. Here’s a few ways Tempest is paradigm-shifting:
Security through guardrails, not gate-keeping
There are two main approaches to creating a consistent, compliant, and secure cloud environment. One is gatekeeping: building rigid barriers that block suboptimal practices. While straightforward to implement, this can ruin developer productivity. It’s also brittle. The first thing an engineer does when they hit a hard stop is to start looking for workarounds, and that leads to shadow processes and even bigger blind spots. The other approach, used by innovation-driven companies like Google and Netflix, is guiding developers with attractive, well-defined pathways that naturally steer them away from pitfalls. This is exactly what Tempest makes really, really easy. DevOps teams can quickly define and deploy secure, compliant “happy paths” for everything from spinning up containers to configuring VPCs, then make them widely accessible internally. As a result, following best practices becomes the path of least resistance, striking an ideal balance between security, productivity, and agility for organizations of any size.
An end to credential sprawl
One of the biggest issues with cloud security is credential sprawl—everyone has their own set of AWS or GCP keys, scattered among dozens (or hundreds) of services. To make matters worse, not every resource is as good at narrow scoping permissions as they should be—in some cases you are forced to trust developers quite a lot just to give them the basic functions they need to work. That’s a recipe for disaster. It creates a huge, largely unaccountable threat surface that makes permission escalation easier, credential leakage more likely, and both attacks significantly harder to spot. But with Tempest, you no longer need to give out credentials for every cloud service. Instead, that access can live with Tempest itself, and only be exposed to developers in a narrowly-scoped way through well-defined workflows.
Strict accountability and faster incident response
A huge benefit of Tempest’s approach is the way it centralizes and clarifies what’s really happening under the hood across an organization’s cloud. Every resource you spin up is logged and attributed to a specific user and team, along with any dependencies or associated configurations. That means when something goes wrong—and in complex cloud environments, eventually it will—there’s a single place to see who did what, when they did it, and how everything ties together. A process that could otherwise take hours of guesswork in multiple consoles or logs now becomes a matter of checking Tempest’s holistic record. Ultimately, this level of built-in transparency transforms your day-to-day operations and makes rapid security responses much easier.
Wrapping up
Securing the cloud is, at its heart, a massive user experience challenge. Companies might have thousands of developers creating and updating infrastructure on a daily basis, and every single one of those interactions is an opportunity for costly mistakes. Infrastructure as Code helps, but without an approachable, user-friendly platform on top, you still end up relying on inconsistent human behavior.
That’s why we built Tempest: to make the right way to do things the easiest way, so organizations can lock down their cloud environments without sacrificing speed or autonomy. Developers get a frictionless experience—no more juggling credentials and one-off scripts—and security teams get consistent best practices that scale.
We think it’s something rare in the security industry: a win for everyone.
Share
