Cloud-native security practices are the set of controls, tools, and architectural patterns built to protect applications running in containers, Kubernetes clusters, serverless functions, and CI/CD pipelines. Unlike perimeter-based approaches that bolt security on after deployment, cloud-native security embeds protection into every layer of the build-deploy-run cycle, from the container image to production runtime behaviour.
Why Cloud-Native Security Differs from Traditional Cloud Security
Traditional cloud security focused on virtual machine hardening, network segmentation, and identity controls around fairly static infrastructure. Cloud-native environments are fundamentally different in character. Containers spin up and tear down in seconds. A single Kubernetes cluster can schedule thousands of pods across hundreds of nodes. Serverless functions execute transiently, often with no persistent file system state. The attack surface is not just larger, it changes continuously.
The 2024 CNCF Security Whitepaper describes this as the “dynamic, ephemeral, and distributed” problem. Your threat model cannot assume stable IP addresses, persistent processes, or predictable process trees. Traditional endpoint detection and response tools that rely on persistent agents or static baseline comparisons simply do not fit. The tooling has to match the environment’s pace of change.
Compounding this, cloud-native architectures introduce new attack vectors that have no equivalent in traditional setups. Supply chain attacks through compromised base images or malicious packages in registries, lateral movement via misconfigured Kubernetes RBAC, and privilege escalation through overpermissioned service accounts are the categories that dominated incident reports in 2024 and 2025. The MITRE ATT&CK framework’s Containers matrix, first published in 2021 and expanded substantially since, catalogs over 70 techniques specifically targeting containerised and cloud-native environments.
Container Security: What Actually Breaks in Production
Container security starts with the image, but most teams spend the least time there. A container image is effectively a software bill of materials, and every unpatched package in that image is a liability you carry into production. Trivy, the open-source vulnerability scanner maintained by Aqua Security, consistently reports that more than 60% of public Docker Hub images contain at least one critical or high-severity CVE when scanned against the NVD database. If your pipeline does not gate on vulnerability scan results before pushing to a registry, you are running software you have not actually reviewed.
Beyond scanning, image provenance matters more in 2026 than it did two years ago. Sigstore, the Linux Foundation project that provides free, transparent code signing infrastructure, makes it practical to cryptographically sign every image in your CI/CD pipeline and verify those signatures at admission time. The cosign tool from Sigstore integrates with Kubernetes admission controllers so you can enforce a policy that only signed, verified images from your own registry are allowed to schedule. This single control closes off a significant portion of the supply chain attack surface.
Runtime container security requires a different approach than build-time scanning. Once a container is running, you need visibility into what processes are executing, what syscalls they make, and whether network connections match expected behaviour. Falco, the CNCF-graduated runtime security tool, uses a rules engine built on top of the Linux kernel’s syscall stream to detect anomalies like unexpected shell execution inside a container, reading from sensitive host paths, or outbound connections to unexpected IPs. Falco ships with a default ruleset covering the most common attack patterns, and the community maintains additional rules aligned to the MITRE ATT&CK Containers matrix.
Kubernetes Security: CIS Benchmarks, RBAC, and Admission Control
Kubernetes security is one area where the gap between what teams think they have configured and what is actually running in production tends to be alarmingly wide. The CIS Kubernetes Benchmark, currently at version 1.9, provides 200-plus controls covering API server configuration, etcd encryption, kubelet settings, network policy, and RBAC. Running kube-bench against a production cluster for the first time often surfaces 30 to 50 failing controls, most of which were never explicitly chosen, they are just the defaults.
RBAC misconfiguration is the most common privilege escalation path in Kubernetes incidents. The core mistake is granting cluster-admin rights to service accounts that only need read access to a specific namespace. The principle of least privilege is obvious in theory and routinely violated in practice because creating a correctly scoped role takes longer than attaching an existing cluster role binding. The NSA and CISA Kubernetes Hardening Guide, updated in August 2022 and still the authoritative reference, dedicates an entire section to RBAC best practices, including the specific instruction to avoid using the system:masters group for anything other than bootstrapping.
Admission controllers are the enforcement point between the Kubernetes API and actual pod scheduling. Open Policy Agent (OPA) with the Gatekeeper distribution lets you write policy as code, enforcing controls like “no containers running as root”, “required resource limits on all deployments”, and “prohibited image registries”. Kyverno offers a Kubernetes-native alternative with a YAML-based policy language that many teams find easier to audit than Rego. Either tool, deployed correctly with policies in enforce mode rather than audit mode, provides a control layer that prevents misconfigurations from reaching production in the first place rather than detecting them after the fact.
Network policy is frequently the last control teams get to, even though it is one of the highest-value hardening steps. By default, all pods in a Kubernetes cluster can communicate with all other pods. A network policy should be your starting point: default-deny all ingress and egress, then explicitly allow only the traffic flows your application actually needs. This limits blast radius significantly if a pod is compromised. The cloud network security principles that apply at the VPC level have direct equivalents inside the cluster through network policies enforced by your CNI plugin.
CNAPP: What It Is and Whether It Actually Helps
A Cloud-Native Application Protection Platform (CNAPP) is a product category that consolidates cloud security posture management (CSPM), cloud workload protection (CWPP), container security scanning, and infrastructure-as-code analysis into a single platform. Gartner coined the term in 2021 and it has since become the dominant category label used by vendors including Palo Alto Networks (Prisma Cloud), Wiz, CrowdStrike (Falcon Cloud Security), and Orca Security.
The case for CNAPP consolidation is real but overstated by vendors. The genuine benefit is unified context. When a CNAPP detects a container running with a critical vulnerability, a misconfigured IAM role, and an exposed port simultaneously, it can correlate those signals into a single risk path that no individual point tool would surface. Wiz popularised the term “attack path” for this concept, and it has proven useful in prioritising what to fix first when vulnerability queues are thousands of items long.
The realistic limitations are equally real. No CNAPP provides runtime protection as capable as a dedicated eBPF-based runtime agent. No CNAPP’s CSPM accuracy matches a purpose-built posture tool configured specifically for your environment. You are buying breadth, and you will still need depth for your highest-risk workloads. The sound approach is to use a CNAPP as your visibility and triage layer while running dedicated runtime protection on production workloads. Your cloud security architecture should treat CNAPP as one component, not the entire strategy.
Supply Chain Security and SLSA Attestations in 2026
Supply chain security is the area where cloud-native security practices have evolved most rapidly over the past two years. The SolarWinds compromise in 2020 and the Log4Shell incident in late 2021 forced the industry to confront how much trust it places in third-party code and build systems. The US Executive Order 14028 on Improving the Nation’s Cybersecurity, issued in May 2021, mandated software bill of materials (SBOM) generation as a requirement for federal software vendors. That requirement has since filtered into enterprise procurement across sectors.
SLSA (Supply-chain Levels for Software Artifacts) is a security framework, initially developed by Google and now hosted under the OpenSSF, that defines four levels of supply chain integrity. SLSA 1 requires scripted, documented builds. SLSA 2 adds version control and hosted build services. SLSA 3 introduces auditable, non-falsifiable build provenance. SLSA 4 requires two-person review and hermetically sealed builds. Most organisations shipping commercial software today operate at SLSA 1 or 2 by default. Reaching SLSA 3 on your critical services provides strong guarantees that the artifact you deploy matches the source code you audited.
SBOM generation is now practical with tools like Syft (from Anchore) and CycloneDX libraries. Generating a CycloneDX or SPDX-format SBOM at build time, signing it with Sigstore, and storing it alongside your container image in the registry gives you the ability to query your entire production environment for exposure to a new CVE in minutes rather than days. This capability was theoretical in 2022 and is operational for teams that have built the pipeline in 2025 and 2026.
Serverless Security: The Attack Surface You Are Probably Ignoring
Serverless security gets significantly less attention than container and Kubernetes security, partly because the abstraction hides the infrastructure and partly because the attack surface looks less familiar. The reality is that serverless functions carry all the application-layer vulnerabilities of any other code, OWASP Top 10 injection flaws included, plus a set of risks unique to the execution model. Over-permissioned Lambda or Cloud Function execution roles are the most common issue. A function that only needs to read from an S3 bucket should not have iam:PassRole or s3:* permissions, but these over-permissions appear routinely in production environments.
Cold start behaviour introduces a nuance that matters for security monitoring. Because serverless functions execute transiently and do not maintain persistent process state, traditional behavioural baselines do not apply. Detection has to operate at the invocation level: what inputs triggered the function, what external services it called, whether it attempted any lateral movement within the account. AWS CloudTrail, Google Cloud Audit Logs, and Azure Monitor all provide function-level invocation logging, but you have to build the alerting logic to surface anomalous patterns. Out-of-the-box, these logs are a firehose without a filter.
Event injection is a serverless-specific attack pattern that deserves attention. Many serverless functions process inputs from queues, event buses, or webhooks without validating those inputs against a strict schema. An attacker who can influence the contents of an SQS message, an SNS notification, or an S3 object name can potentially inject payloads that manipulate function logic. The OWASP Serverless Top 10 project, which maps traditional web application risks to the serverless context, treats event data injection as the equivalent of SQL injection in this environment.
Runtime Protection with eBPF: How the Technology Actually Works
eBPF (extended Berkeley Packet Filter) is a Linux kernel technology that allows programs to run sandboxed code in the kernel without modifying kernel source or loading kernel modules. Security tools that use eBPF can attach to kernel probe points and observe every syscall, network connection, and file system event across the entire host, with sub-millisecond overhead and no modification to the workloads being monitored. This makes eBPF-based runtime protection categorically different from approaches that require sidecar injection or host-based agents with privileged container access.
Falco uses eBPF as its preferred kernel driver since version 0.33, replacing the older kernel module approach that required kernel headers and was incompatible with many managed Kubernetes distributions. Commercial runtime protection platforms including Datadog Cloud Workload Security, Sysdig Secure, and Aqua Security’s runtime agent also use eBPF as the kernel observation layer. The practical difference you notice in production is that eBPF-based tools work on GKE, EKS, and AKS without the kernel module patching that previously caused compatibility headaches.
For threat detection, eBPF provides ground truth. You are observing what the kernel actually does, not what process metadata claims is happening. A container that disguises itself with a legitimate process name but executes cryptomining binaries cannot hide its syscall pattern. A reverse shell spawned inside an application container makes network connections that eBPF captures at the socket level before any userspace tool can intercept or sanitise the telemetry. This is why runtime protection built on eBPF has become the baseline expectation in mature cloud-native security programs.
Infrastructure as Code Security Scanning Before Deployment
One of the most cost-effective cloud-native security practices is catching misconfigurations in infrastructure-as-code templates before they ever deploy. Scanning Terraform, Helm charts, Kubernetes manifests, and CloudFormation templates in your CI/CD pipeline costs essentially nothing in compute terms and prevents the category of misconfiguration that shows up as an open S3 bucket, a publicly accessible Kubernetes API server, or an ingress controller without TLS.
Checkov (from Bridgecrew, now part of Palo Alto) and tfsec (now merged into Trivy‘s IaC scanning module) are the most widely used open-source IaC scanners. Both support Terraform, CloudFormation, Kubernetes manifests, and Helm. Both map findings to CIS Benchmarks, NIST 800-53 controls, and the MITRE ATT&CK framework, so you can trace a scanner finding back to the control framework your compliance team cares about. Running either tool as a required CI/CD check, with a policy that blocks deployment on high-severity findings, shifts security left in a way that is genuinely measurable.
The less obvious benefit of IaC scanning is drift detection. When you scan templates and compare them against the deployed state using tools like driftctl or native CSPM features in a CNAPP, you surface changes made outside the IaC pipeline, the manual console clicks and emergency hotfixes that bypass your controls. Unmanaged drift is one of the most common preconditions for cloud security incidents because the change is not in any audit trail and nobody owns it. A complete picture of your cloud security tools stack should include IaC scanning as a mandatory pipeline stage, not an optional add-on.
Building a Cloud-Native Security Program in 2026: Where to Start
If you are building or significantly improving a cloud-native security program, the sequence of controls matters as much as the controls themselves. Starting with a CNAPP procurement before you have basic image scanning and Kubernetes hardening in place is spending money on a dashboard before fixing the underlying issues it will surface. The operational foundation comes first.
Begin with your build pipeline: implement image scanning with Trivy, enforce a vulnerability threshold that blocks critical CVEs from reaching your registry, and generate SBOMs for all production images. Next, harden your Kubernetes clusters against the CIS Benchmark using kube-bench to measure current state and track improvement over time. Add OPA Gatekeeper or Kyverno to enforce admission policies. Deploy Falco with eBPF for runtime detection. Only then does a CNAPP add meaningful incremental value, because you have a clean enough environment that its posture findings are actionable rather than a 4,000-item backlog of noise.
Security teams that follow this sequence consistently report faster time-to-remediation and fewer production incidents than teams that start with broad visibility tools and skip foundational hardening. The cloud-native security practices that stop breaches are not the most expensive or the most sophisticated. They are the ones that close the specific gaps that attackers actually exploit: unpatched images, overpermissioned service accounts, missing network policies, and runtime behaviour that nobody is watching.
Frequently Asked Questions
What is cloud-native security?
Cloud-native security is a set of controls and practices designed specifically for containerised, serverless, and Kubernetes-based applications. It embeds security into the build, deploy, and runtime phases rather than relying on perimeter defences. Core components include container image scanning, Kubernetes RBAC hardening, supply chain integrity verification, and eBPF-based runtime protection.
How is cloud-native security different from traditional cloud security?
Traditional cloud security focuses on VM hardening, firewalls, and static network segmentation. Cloud-native security addresses ephemeral workloads, container supply chains, Kubernetes orchestration risks, and serverless execution patterns. The attack surface changes continuously, so cloud-native controls must operate at the build and runtime layer rather than at a fixed perimeter.
What is a CNAPP?
A Cloud-Native Application Protection Platform (CNAPP) is a security platform that consolidates cloud security posture management, container vulnerability scanning, cloud workload protection, and infrastructure-as-code analysis into one product. Major vendors include Wiz, Palo Alto Prisma Cloud, CrowdStrike Falcon Cloud Security, and Orca Security. CNAPPs provide unified attack path analysis but should complement, not replace, dedicated runtime tools.
What are the biggest cloud-native security risks in 2026?
The four highest-impact risks in 2026 are unpatched container images in production registries, over-permissioned Kubernetes service accounts enabling privilege escalation, software supply chain compromise via malicious base images or dependencies, and misconfigured serverless function execution roles. All four appear consistently in CNCF security reports, MITRE ATT&CK Containers matrix incident data, and cloud provider breach disclosures.
