Secure-by-Design Cloud Security: How Native Moves Security Into the Architecture

Cloud security teams have worked for years to speed up detection of configuration errors, exposed resources, suspicious activity, and policy violations. But even fast detection means the unsafe condition was already present. This gap is more important now because cloud environments are easier to change and attacks happen faster.

On the SoftwarePlaza podcast, editor Twain Taylor interviewed Gal Ordo, co-founder and CPO of Native, about secure-by-design cloud architecture. Ordo previously led AWS Security Hub before founding Native.

He emphasizes that cloud security needs more than simply identifying and detecting threats. The architecture should prevent unsafe states from happening. Native uses security controls already built into AWS, Azure, Google Cloud, and Oracle Cloud Infrastructure (OCI). The company calls its platform a Cloud Security Control Plane, which turns these controls into active defenses across cloud environments.

The response window for cloud attacks is shrinking

Periodic detection worked better when security teams had enough time between a new exposure and an attacker taking advantage of it.

Now, it’s harder to count on that extra time. Attack timelines that can now be measured in minutes. AI adds another factor because it can accelerate vulnerability research, reconnaissance, code generation, and other stages of an attack.

There’s another AI-related security issue. More applications now include AI models, agents, and automated workflows that interact with infrastructure and data. If an agent has too many permissions, it can create risks even without an active attack. It might expose information, change resources, or do something developers didn’t expect.

Relying only on prompt-level instructions is not enough to enforce infrastructure security. The architecture needs clear controls for identity, networking, data access, and resource behavior.

Secure by design changes where security happens

Secure-by-design architecture begins by deciding what should be technically impossible in the environment.. For example, a company may want to prevent production systems from communicating with non-production systems.

It’s easy to write that requirement in a security document, but enforcing it across a large cloud environment is much harder.

The organization may need controls for workload identities, network paths, cloud accounts or projects, service permissions, data access, and new resources. A change in one area can affect whether the policy still works.

A scanning-based approach can detect when a configuration violates the intended architecture. The secure-by-design approach described by Ordo instead encodes the architecture into controls that prevent the prohibited connection.

Shift left and shift down solve different problems

For years, software security has encouraged teams to shift left. This usually means doing security checks earlier in the development process. Code scanning, infrastructure-as-code checks, dependency analysis, and CI/CD security tests give developers feedback before code goes to production.

Ordo doesn’t disagree with this approach. The problem arises when a policy relies on multiple resources or cloud services simultaneously.

A scanner can check a proposed configuration, but it’s much harder for it to guarantee an organization-wide architectural result. This is especially true when networks, identities, accounts, data paths, and resources are created outside the same deployment pipeline.

Turning cloud-native controls into enforceable outcomes

Cloud providers offer many security mechanisms. The challenge is turning these separate tools into a consistent architecture. Native tackles the problem by focusing on the security outcome, instead of making teams configure each provider control one by one.

A security team might set a rule to stop production workloads from talking to non-production environments. Native maps that rule to the controls needed in the chosen cloud platform. The product groups these defenses into several architectural areas, as discussed in the podcast:

• Perimeter segmentation controls communication between environments and external systems.
• Environment segmentation restricts communication between groups such as production and non-production.
• Baseline policies set expected behavior for resources, including requirements such as encryption.

Native’s current product materials describe a similar model based on perimeters, segmentation, and baselines, using controls already offered by the cloud platforms.

Enforcement requires simulation and gradual adoption

Preventive security also brings its own operational risks. A detection rule that gives a false alert creates noise. An enforcement policy that blocks real traffic can cause outages.

That makes testing part of the deployment process. Native offers simulation so teams can see the likely impact of a policy before enforcing it. Adoption starts gradually. Organizations can test policies in non-production environments, review the results, handle exceptions, and then roll out enforcement to production.

Occasionally, a workload needs to cross a restricted boundary for a valid reason. During migration, temporary access may be needed even if the final architecture will block it. Security teams require ways to handle these cases without dropping the policy.

After deployment, controls must keep up with new resources and configuration changes. Native sees policy updates, exceptions, and drift as ongoing parts of enforcement, not just a one-time setup.

Secure-by-design enforcement doesn’t mean detection is no longer required.

Organizations still need to see suspicious activity, vulnerabilities, unexpected behavior, and attacks that aren’t covered by architectural policies. CSPM, SIEM, scanning, and other security systems still play important roles.

Native’s main point is about what should happen before those tools are needed. If the cloud architecture already blocks certain communication paths, permissions, and resource setups, security teams have fewer problems to find after deployment.

This approach matters even more when infrastructure changes quickly and AI gives defenders less time to respond. Native’s model moves preventive architecture to the start of the cloud security stack. First, define what the environment should allow, enforce those rules with the cloud provider’s controls, and use detection systems for anything that can’t be prevented.

To learn more about shift-down security, multi-cloud policy enforcement, AI-related risks, and Native’s secure-by-design approach, listen to the full Software Plaza podcast episode with Gal Ordo.

Discover how Native uses cloud-native controls, shift-down security, and architecture-level policies to stop cloud security issues before they happen.