The Evolution of Cloud Security Toward the Daily Work of Security Teams

Before starting Native, I worked at AWS, leading one of its largest security products: AWS Security Hub. A few weeks into the role, I met the CISO of a Fortune 100 company that was spending hundreds of millions of dollars in the cloud (if not more). He told me something I still think about often: 

“We love Security Hub. But it doesn’t offer us security, just after-the-fact visibility. Why is AWS allowing the bad things to happen in the first place? How can I make sure they  don’t happen?” 

At first, I spoke with sister teams internally. Surely this has to be solvable. Cloud providers directly expose identity primitives and other guardrails. And yet, when I looked at what it would take to guarantee even one “simple” outcome for that customer, the answer was a messy web of partial technical capabilities and policies, plus a lot of manual stitching. 

When I came back to the customer with a path forward, the follow-up question was even more direct: 

“How were we supposed to know any of this? And how do we do it not just once, but for our entire cloud security standard? And how do we make it so it takes a day to implement, not a month?” 

We met again near the end of my time at AWS. Progress on their side had been minimal, not because they didn’t care, but because the work was manual, deeply technical, and never-ending. 

That gap, between the outcomes security teams are accountable for, and the workflows most cloud security tooling is built around, is what ultimately led us to start Native. 

How Cloud Security Got Here 

If you zoom back to the early 2010s, the first wave of cloud security products made perfect sense. 

Cloud adoption was still early. For most companies, cloud was a secondary environment. The crown jewels lived elsewhere, and security teams had plenty of “more urgent” problems. 

So the earliest cloud security tools focused on visibility. That model worked when cloud footprints were small and blast radius was limited. Teams saw relatively few findings and could work collaboratively to resolve them quickly. 

Fast forward to the late 2010s and early 2020s. Cloud became the primary computing environment for most enterprises. Teams built more in the cloud, more quickly, across more accounts and services. The industry evolved alongside it: CSPM, then CWPP and CIEM, and eventually CNAPP. But the core security motion stayed mostly the same: produce findings, triage, remediate. I’ve seen teams who receive tens of thousands of findings every week. And even when those findings are accurate, they often land at the wrong level of abstraction. 

Because what security leaders want to validate is rarely a single checkbox. 

If your desired outcome is “production and non-production should never be connected,” that’s not one control. It’s dozens of controls across networking, identity, workloads, and service-specific behavior, multiplied by every account, VPC or VNet, workload type, and exception. The result is a painful reality: locating the few findings that actually matter feels like finding a needle in a haystack, except the haystack keeps growing. 

Why “Shift Left” Doesn’t Fully Solve This

When security teams get overwhelmed, the instinct is to push things earlier. Scan the code. Add policy checks to CI. Block unsafe changes. 

That works for many classes of problems, and it’s absolutely part of a healthy program. But it struggles with outcome-level guarantees for two reasons. 

First, the “production vs. non-production connectivity” example exposes a scale problem. Even if you know every possible path that could connect those environments, it’s not realistic to test every variant in code for every service and every team. 

Second, code scanning only covers what flows through a specific pipeline. 

What about: 

• resources created outside the main pipeline, whether in other pipelines or directly in the console, 

• emergency changes, 

• teams with different deployment processes, 

• or connectivity patterns that span multiple applications? 

This becomes even harder in multi-cloud environments, where the same intent must be expressed using entirely different primitives. 

Trying to guarantee that single outcome with these tools is close to impossible. Outcome-level security is bigger than any single repo or pipeline. So the question becomes: where is the one place you can enforce intent consistently? 

Enforcing Intent at the Cloud Control Plane 

Cloud security teams have been vocal about the current state: too much noise, too many needles, and too little ability to guarantee what actually matters. 

“Secure-by-design” is the response to that. The goal is straightforward: turn single-sentence security outcomes into enforceable guardrails, and make them hard to bypass and safe to roll out. 

The only way to achieve this level of certainty is by enforcing guardrails at the source, within the cloud provider itself. Luckily, this is also where cloud providers are investing heavily. I’ve heard countless customers make the same request as that Fortune 100 CISO, and providers have listened. Over the last few years, AWS, Azure, Google Cloud, and OCI have introduced more and more capabilities that allow teams to enforce these outcomes. But there’s a catch. 

These capabilities are deeply technical. Security teams can’t simply log into a cloud console, declare “production should never talk to non-production,” and have that intent magically become reality. 

Instead, teams have to: 

• choose the right primitives, 

• write technical artifacts, 

• scope them carefully, 

• preview impact, 

• orchestrate rollout, 

• manage exceptions, 

• detect drift, 

• and keep everything aligned as cloud usage evolves and providers update their platforms. 

In other words, secure-by-design turns cloud security into cloud engineering, and that engineering requires time, resources, and expertise. 

How Security Teams Actually Do the Work 

One of the most consistent patterns we saw while spending time with cloud security teams is that secure-by-design isn’t a one-time project. It’s a repeating loop. 

When security engineers and cloud architects implement guardrails, they move through five steps: 

1. Discover: Identify the security outcome, then map the current cloud environment and existing enforcement controls to understand what already exists, what’s missing, and where the real gap is. 
   
   

2. Plan: Define how that outcome should apply in your environment. Scope it to the right environments, services, and business units. Decide what “good” looks like and where exceptions are acceptable, or even necessary. 
   
   

3. Simulate: Preview real-world impact before enforcement. This usually means collecting logs and signals to estimate who and what would be affected, so changes can be introduced safely without breaking existing applications. 
   
   

4. Implement: Translate the plan into provider-specific technical controls, manage rollout, and coordinate with the teams that will feel the impact. This often needs to be repeated across multiple cloud providers, each with its own model and primitives. 
   
   

5. Operationalize: Keep guardrails effective over time. Manage exceptions, watch for drift, adjust as business needs change, and adopt new cloud capabilities as they launch. 

This isn’t a linear path, it’s a cycle. 

First, once you complete one outcome, you move on to the next. 

Second, policies are living things. Cloud environments change daily. Teams refactor. New services are adopted. Providers introduce new features that create new paths, or new (and potentially better) ways to solve the same problem. 

So you’re never really “done.” You’re continuously steering architecture toward a set of outcomes. As you enforce more secure-by-design guardrails, the operational load adds up, which leaves less time and fewer resources for the next one. 

What we Heard Repeatedly from Security Teams 

Across conversations with organizations of different sizes and industries, a few themes kept coming up. 

1) The security outcome is the only thing that matters. 

Security teams care about principles such as safe AI adoption, perimeter protection, least privilege, blast-radius reduction. They do not care about reconstructing those principles from thousands of disconnected controls. 

2) The hardest part is making change safe. 

Many organizations know what they should enforce, but they can’t afford downtime or surprise breakages. Simulation, preview, and staged rollout need to be first-class capabilities. 

3) Exceptions are inevitable, but unmanaged exceptions are dangerous. 

Guardrails fail quietly when exceptions become untracked, unowned, or permanent. Teams want exceptions to be explicit and manageable at scale. 

4) Multi-cloud amplifies everything. 

The intent can be the same, but the implementation never is. Different providers expose different primitives, policy languages, and technical enforcement models. 

What this means is that mature cloud security programs often have a clear security standard on paper, but it’s only partially and inconsistently implemented. These challenges also lead to errors. We’ve seen policies inadvertently not enforced everywhere, and controls that exist but aren’t actually effective. As a result, organizations remain exposed even when they believe they’re safe.  

Why We Started Native (and What We’re Building) 

Native started from a simple observation: secure-by-design is clearly where the industry is heading, and the only place to achieve it is at the source. Indeed, cloud providers are working hard to deliver the underlying capabilities, but most teams don’t have the time or specialized cloud engineering capacity to do the work those capabilities require. 

So we built Native to be a force multiplier for the people doing this work every day: security engineers and cloud architects. Our goal isn’t to replace how teams operate, but to accelerate the secure-by-design cycle they already follow. We’re also taking a strong stance on how this should be done: using cloud providers’ own primitives, because that’s where durable enforcement actually lives. 

If this resonates, or even if it doesn’t, we’d love to hear what you think. Native came directly from what we heard in conversations with cloud security teams, and staying in that dialogue helps us keep improving.