Cloud & Infrastructure Security: IaC, CNAPP & Container Security (2026)

Why cloud security is different

Infrastructure used to be physical. You bought servers, racked them, and locked the data center door. Changes happened slowly because every change required a human touching hardware. Security teams had weeks to review architecture changes before anything went live.

That world is gone. In cloud environments, a developer can spin up a database, expose it to the internet, and store production data in it before lunch. Terraform applies in seconds. CloudFormation stacks deploy in minutes. The speed that makes cloud powerful is the same speed that makes it dangerous.

Misconfiguration is the number one cause of cloud security breaches. Not sophisticated zero-days. Not advanced persistent threats. Simple mistakes: a storage bucket left public, an IAM policy granting admin access to every user, a database running without encryption. According to IBM’s Cost of a Data Breach report, 82% of breaches now involve data stored in cloud environments. Gartner estimates that through 2027, 99% of cloud security failures will be the customer’s fault, not the provider’s.

The shared responsibility model is the root of this problem. AWS, Azure, and Google Cloud secure the infrastructure itself. Everything you build on top of it is your responsibility: configurations, access controls, data protection, network rules. Most teams understand this in theory but underestimate it in practice.

Three characteristics make cloud security fundamentally different from traditional infrastructure security:

Infrastructure is code. Definitions live in version control as Terraform, CloudFormation, Pulumi, or Kubernetes manifests. Misconfigurations are code bugs, and like code bugs, they can be caught by automated scanning before deployment.

Resources are ephemeral. Containers live for minutes. Lambda functions execute for seconds. Auto-scaling groups create and destroy instances based on load. Manual reviews and periodic audits cannot keep up.

Attack paths cross layers. A misconfigured IAM role, a vulnerable container image, and a public subnet combine into an attack path that no single tool sees in isolation. Cloud security requires correlating findings across infrastructure, workloads, and identities.

Infrastructure as Code security

IaC security is the practice of scanning infrastructure code for misconfigurations before deployment. If your Terraform file defines an S3 bucket without encryption, an IaC scanner flags it in the pull request. Fix it before it reaches production.

The concept mirrors what SAST does for application code. SAST scans source code for vulnerabilities. IaC scanning scans infrastructure definitions for misconfigurations. Both shift the detection left, catching problems when they are cheapest to fix.

IaC scanners support the major frameworks: Terraform, CloudFormation, ARM templates, Pulumi, Kubernetes manifests, Helm charts, Dockerfiles, and Ansible playbooks. They work by parsing templates into a structured representation, then evaluating each resource against a policy library. Checkov, for example, ships with over 3,000 built-in policies covering AWS, Azure, GCP, and Kubernetes.

The workflow is simple. Add the scanner to your CI/CD pipeline. It runs on every pull request. If it finds a security group that allows SSH from 0.0.0.0/0, the pipeline fails and the developer fixes the issue before merging. No tickets. No handoffs. No security team bottleneck.

The best part: most IaC scanning tools are free. Checkov, KICS, and Trivy are all open-source under Apache 2.0 licenses. The IaC security space is one of the few areas in AppSec where the strongest tools cost nothing.

For a deeper look at how IaC scanning works and which tools to start with, read our What is IaC Security? guide or browse all IaC Security Tools.

Cloud Security Posture Management

IaC scanning catches misconfigurations before deployment. CSPM catches them after. Together they cover both sides: prevention and detection.

CSPM tools connect to your cloud accounts via API and continuously monitor your running infrastructure against security benchmarks. CIS Benchmarks, PCI DSS, SOC 2, HIPAA, NIST 800-53. They check whether your actual cloud configuration matches what your compliance framework requires.

The value of CSPM becomes clear when you consider configuration drift. A developer fixes a security group in Terraform but also makes a manual change in the AWS console that bypasses the code. IaC scanning does not catch the manual change. CSPM does, because it monitors the live environment regardless of how changes were made.

Key CSPM capabilities include:

Continuous monitoring. CSPM tools poll cloud APIs on a schedule (typically every few hours) to detect new misconfigurations. Some offer near-real-time detection through event-driven architectures using CloudTrail or Azure Activity Log.

Compliance mapping. Each finding maps to specific compliance controls. A CSPM dashboard can show you exactly which CIS Benchmark rules you pass and fail, broken down by cloud account, region, and resource type.

Auto-remediation. Some CSPM tools can automatically fix certain misconfigurations, such as re-enabling encryption on a storage bucket or restricting a security group. This is powerful but risky. Most teams start with alerts only and add auto-remediation selectively.

Alert prioritization. Not every misconfiguration carries the same risk. A public S3 bucket containing production data is more urgent than one holding static marketing images. Better CSPM tools correlate findings with context (data sensitivity, network exposure, identity permissions) to prioritize what matters.

CSPM is available as standalone products and as part of broader CNAPP platforms. Standalone CSPM tools include AWS Security Hub, Azure Defender for Cloud, and Google Security Command Center from the cloud providers themselves. Third-party options are folding CSPM into their CNAPP offerings.

CNAPP: the unified approach

Before CNAPP existed, securing a cloud environment meant buying separate tools for five or six different problems: CSPM for infrastructure misconfigurations, CWPP for workload protection, CIEM for identity and entitlement management, IaC scanning, container security, and vulnerability management. Each had its own dashboard, its own alerting format, and its own blind spots.

CNAPP (Cloud-Native Application Protection Platform) combines all of these into a single integrated product. Gartner coined the term in 2021, and by 2025 it became the fastest-growing category in cloud security. The consolidation appeal is obvious: fewer tools to manage, fewer dashboards to check, and most importantly, correlated context across all of those security domains.

The killer feature of CNAPP is the risk graph. Instead of looking at a misconfigured IAM role in isolation, a CNAPP connects it to the vulnerable container it can access, the public-facing load balancer routing traffic to that container, and the sensitive database the container connects to. One misconfiguration might be low severity on its own. Combined with the rest of the attack path, it becomes critical.

CNAPP platforms fall into two architectures:

Agentless. The platform reads cloud APIs and takes periodic snapshots of workloads to analyze them for vulnerabilities and misconfigurations. No software installed on your instances. Wiz pioneered this approach and built a multi-billion dollar business on the simplicity of agentless deployment.

Agent-based. A lightweight agent runs on each workload, providing real-time visibility into processes, network connections, and file activity. This gives deeper runtime insight but requires deployment and management overhead. Aqua and Sysdig lean more heavily on agents.

Most modern CNAPP vendors offer both options: agentless for broad coverage and fast deployment, agents for deep runtime monitoring on critical workloads.

The leading CNAPP platforms in 2026 include Wiz, Orca Security, Palo Alto Prisma Cloud, and Lacework (now part of Fortinet). Each has different strengths. Wiz leads in agentless simplicity. Prisma Cloud offers the broadest feature set. Orca Security provides strong identity and data security analysis.

Read our full What is CNAPP? guide for a detailed breakdown of components, vendor comparison, and decision framework.

Container and Kubernetes security

Containers changed how applications are packaged and deployed. They also introduced a new attack surface that traditional security tools do not cover.

Container security spans three phases: build, deploy, and runtime.

Build: Image scanning

Every container starts as an image. That image contains an operating system, language runtime, application dependencies, and your code. Any of these layers can introduce vulnerabilities. A base image running Debian 11 might include OpenSSL versions with known CVEs. A Python dependency installed via pip might have a remote code execution flaw.

Image scanning tools analyze each layer of the image against vulnerability databases (NVD, GitHub Advisory Database, vendor databases). Trivy is the most widely used open-source image scanner. It runs in seconds, covers OS packages and language dependencies, and integrates into CI/CD pipelines with a single command. Grype, Anchore, and Snyk Container are other options.

Best practice: scan images in CI/CD before they are pushed to a registry. Block images with critical or high vulnerabilities from being deployed.

Deploy: Admission control

Kubernetes admission controllers are gatekeepers that enforce policies at deploy time. When a developer tries to deploy a pod that runs as root, the admission controller rejects it. When a deployment tries to pull from an untrusted image registry, the admission controller blocks it.

OPA Gatekeeper and Kyverno are the two main policy engines for Kubernetes admission control. They let you define rules in code: no privileged containers, no latest tags, resource limits required, approved registries only.

Runtime: Monitoring and detection

Runtime security tools watch running containers for anomalous behavior. If a container that normally serves HTTP requests suddenly spawns a shell process, that is suspicious. If it opens a network connection to an IP address it has never contacted before, that warrants investigation.

Falco is the standard open-source tool for container runtime security. It uses eBPF to hook into kernel system calls without modifying the container or requiring privileged access. Sysdig, Aqua, and the CNAPP platforms provide commercial runtime security capabilities.

Kubernetes-specific security also includes network policies (restricting which pods can communicate), pod security standards (enforcing least-privilege at the pod level), and KSPM (Kubernetes Security Posture Management) for auditing cluster configurations against CIS Kubernetes Benchmarks.

Shift-left for cloud

Shift-left means finding problems earlier in the development process. For cloud infrastructure, that means catching misconfigurations in the IDE or pull request instead of in production.

The shift-left pipeline for cloud infrastructure has four checkpoints:

Pre-commit. Developers run IaC scanners locally before pushing code. Checkov and Trivy have IDE plugins and pre-commit hooks that flag issues in seconds. This catches the obvious problems (public buckets, open security groups) before the code even reaches version control.

Pull request. The CI/CD pipeline runs IaC scanning on every PR. Results appear as inline comments on the changed files. The developer sees exactly which resource failed which policy and why. This is the most effective checkpoint because it integrates into the existing review workflow.

Deployment gate. Before Terraform applies or CloudFormation creates a stack, a policy check validates the plan output against organizational security requirements. OPA (Open Policy Agent) with Rego policies is the standard approach. This catches issues that only appear in the resolved plan, such as dynamic references that IaC scanning cannot evaluate at template level.

Post-deployment. CSPM monitors the live environment for drift and manual changes. This is the safety net. If something slips through the earlier gates or a developer makes a change outside the IaC workflow, CSPM catches it.

Policy as code deserves special mention. Instead of security requirements living in a spreadsheet that nobody reads, you express them as executable policies. “All S3 buckets must have encryption enabled” becomes a Rego rule that runs automatically on every deployment. The policy is versioned, reviewed, tested, and enforced just like application code. OPA/Rego and Sentinel (HashiCorp’s policy framework) are the leading tools for this approach.

Building a cloud security program

You do not need a CNAPP to start securing your cloud infrastructure. The right approach depends on the size of your environment, the maturity of your team, and your budget.

Stage 1: IaC scanning in CI/CD

Start here. It is free, takes an afternoon to set up, and delivers immediate value. Add Checkov or Trivy to your CI/CD pipeline. Configure it to fail builds on high and critical severity misconfigurations. You will fix more cloud security issues in the first week than most teams fix in a quarter of manual reviews.

Focus on the basics first: no public storage buckets, no overly permissive IAM policies, encryption enabled everywhere, logging turned on. These straightforward checks prevent the misconfigurations that cause most cloud breaches.

Stage 2: Cloud provider native tools

Enable your cloud provider’s built-in security services. AWS Security Hub, Azure Defender for Cloud, and Google Security Command Center provide basic CSPM functionality at low cost. They are not as feature-rich as third-party tools, but they cover the fundamentals and integrate natively with your cloud environment.

Set up alerting on critical findings. Assign ownership for remediation. Establish SLAs: critical findings fixed within 48 hours, high within one week.

Stage 3: CSPM or CNAPP

When you outgrow native tools, usually when you manage multiple cloud accounts, need compliance reporting, or want correlated risk analysis, evaluate third-party CSPM or CNAPP platforms.

If you have a single cloud provider and straightforward workloads, a focused CSPM tool might be sufficient. If you run containers, Kubernetes, multi-cloud, or need identity and workload protection, a CNAPP provides the breadth you need.

Stage 4: Runtime and advanced detection

Add container runtime security (Falco or a CNAPP agent), Kubernetes admission control (OPA Gatekeeper or Kyverno), and automated remediation for high-confidence findings. This stage requires more operational maturity because runtime tools generate noise that needs tuning.

Ownership matters

Cloud security programs fail when nobody owns the findings. Developers write the IaC. Platform teams manage the cloud accounts. Security teams set the policies. Define who triages alerts, who fixes findings, and who verifies remediation. Without clear ownership, dashboards turn red and stay red.

The most effective model: security teams define policies and set severity thresholds. Platform teams implement guardrails (admission controllers, pipeline gates). Developers fix the findings in their own code. Security reviews the exceptions.

Browse Tools by Category

This hub covers 1 application security categories with 6 tools total. Dive into any category to compare tools, read reviews, and find the best fit for your stack.

Learning Resources

Deepen your understanding with these in-depth guides covering key concepts, tool comparisons, and implementation strategies.

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.