Cloud-Native Application Security

Cloud-native application security addresses the distinct threat surface created when software is built, deployed, and operated using containers, microservices, orchestration platforms, and dynamic infrastructure. The attack surface in cloud-native environments differs structurally from that of monolithic or traditional web applications — it spans container images, inter-service communication, infrastructure-as-code definitions, service mesh configurations, and CI/CD pipeline integrity. Regulatory frameworks including NIST, FedRAMP, and PCI DSS have issued specific guidance addressing these environments, making cloud-native security a compliance domain with enforceable consequences alongside its technical dimensions. This page describes the service landscape, professional categories, structural mechanics, and classification boundaries that define this sector.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix
• References

Definition and scope

Cloud-native application security is the discipline of identifying, mitigating, and monitoring security risks that arise specifically from cloud-native architectural patterns: containerization (principally Docker and OCI-compliant formats), container orchestration (principally Kubernetes), microservice decomposition, serverless functions, and infrastructure-as-code (IaC) provisioning tools such as Terraform and AWS CloudFormation. The scope extends from the developer workstation through the build pipeline, container registry, orchestration control plane, runtime environment, and inter-service API fabric.

The Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) provides a formal control framework mapped to cloud-native deployment patterns, while NIST SP 800-190, Application Container Security Guide, establishes the federal reference baseline for container security specifically. The scope of cloud-native security differs from traditional application security in three structural ways: infrastructure is ephemeral and defined programmatically, the network perimeter is dissolved into service-to-service identity and policy, and the supply chain — base images, third-party charts, and public registries — becomes a primary attack vector.

The application security providers provider network catalogs service providers operating across this sector, including firms specializing in Kubernetes security posture management, container image scanning, and cloud-native penetration testing.

Core mechanics or structure

The structural components of cloud-native application security organize into five functional layers, each with distinct control categories:

1. Image and build-time security. Container images are the deployable unit of cloud-native software. Security at this layer involves scanning images for known CVEs using tools that reference the National Vulnerability Database (NVD) maintained by NIST, enforcing base image policies (e.g., prohibiting images running as root), signing images using cryptographic attestation standards such as Sigstore or Notary v2, and validating IaC templates against policy-as-code rulesets (e.g., OPA/Rego policies, Checkov for Terraform).

2. CI/CD pipeline integrity. The build pipeline is both a delivery mechanism and an attack surface. Controls include protecting pipeline secrets, enforcing signed commit policies, restricting who can approve pipeline changes, and generating Software Bills of Materials (SBOMs) — a requirement formalized in the White House Executive Order 14028 (2021), which directed NIST to define minimum SBOM elements (NIST SBOM guidance).

3. Orchestration platform hardening. Kubernetes introduces a control plane (API server, etcd, kubelet, scheduler) that must be hardened against misconfiguration. The NSA/CISA Kubernetes Hardening Guidance (NSA/CISA, 2022) specifies 53 discrete configuration controls covering RBAC, network policies, pod security standards, and audit logging.

4. Runtime security. Runtime controls detect anomalous behavior in running containers using kernel-level instrumentation — primarily eBPF-based tools — that observe syscall patterns, file system writes, and network connections against a baseline profile. CNCF (Cloud Native Computing Foundation) maintains the Falco project as a widely-referenced open-source runtime threat detection engine.

5. Service mesh and network policy. Microservice architectures require mutual TLS (mTLS) between services, enforced through service mesh implementations (Istio, Linkerd). Network policies at the Kubernetes layer implement least-privilege traffic rules between namespaces and pods, replacing traditional firewall perimeters.

Causal relationships or drivers

Adoption of cloud-native architectures has expanded the attack surface in measurable ways. A 2023 report by the Cloud Native Computing Foundation recorded over 10 million Kubernetes clusters in active use globally, creating a large aggregate target for control-plane attacks and misconfiguration exploitation.

Three structural factors drive security complexity in cloud-native environments:

Immutability and ephemerality. Containers are designed to be short-lived and replaced rather than patched in place. This challenges traditional vulnerability management workflows that assume persistent hosts with patch cycles. Security tooling must shift left — catching vulnerabilities at build time — because runtime patching is architecturally incompatible with immutable infrastructure.

Shared responsibility gaps. Cloud providers secure the underlying infrastructure; the customer secures the container configuration, orchestration policy, and application code. Misconfigured Kubernetes RBAC and overly permissive IAM roles represent the most frequently exploited gaps in this model, as documented in the CISA Known Exploited Vulnerabilities (KEV) catalog for cloud-native CVEs.

Supply chain exposure. Public container registries such as Docker Hub host millions of images, a significant fraction of which contain known critical CVEs at the time of pull. The OWASP Top 10 CI/CD Security Risks (OWASP) formalizes pipeline-specific threats including insufficient flow control and insecure third-party code integration as the primary drivers of cloud-native compromise chains.

Classification boundaries

Cloud-native application security is distinct from — though operationally adjacent to — the following domains:

Cloud security posture management (CSPM): CSPM addresses infrastructure-layer misconfigurations (S3 bucket policies, VPC configurations, IAM policies) without application-layer context. Cloud-native application security operates at the workload and code layer above the infrastructure baseline CSPM covers.

Traditional application security: Standard web application security — SQL injection, XSS, authentication flaws — applies to the application code running inside containers but does not address the container runtime, orchestration control plane, or IaC layer. The page describes how these domains are organized across the service landscape.

DevSecOps: DevSecOps is an organizational practice model for integrating security into software delivery workflows. Cloud-native application security is the technical discipline that DevSecOps practices implement within cloud-native delivery pipelines.

Serverless security: AWS Lambda, Google Cloud Functions, and Azure Functions introduce function-level attack surfaces (event injection, over-privileged execution roles, insecure deserialization of event payloads) that share principles with container security but require distinct tooling and threat models.

Tradeoffs and tensions

Speed versus depth of scanning. Image scanning integrated into CI/CD gates can add 30–90 seconds per build for large images. Enforcing blocking gates on critical CVEs reduces deployment velocity; relaxing gates increases risk acceptance. Organizations operating under FedRAMP High authorization cannot waive critical CVE gates; those outside regulated sectors must define explicit risk acceptance criteria.

Least privilege versus operational complexity. Implementing fine-grained Kubernetes RBAC and network policies that enforce true least-privilege access dramatically increases policy management overhead. Under-specified RBAC is the most common Kubernetes misconfiguration class, per the NSA/CISA Kubernetes Hardening Guidance — yet over-engineering RBAC creates operational friction that leads teams to grant cluster-admin bindings as a workaround.

Visibility versus performance. eBPF-based runtime security agents provide deep syscall-level visibility but consume CPU and memory resources at runtime. In latency-sensitive workloads, the overhead of kernel-level instrumentation creates pressure to reduce monitoring coverage, producing blind spots in the detection layer.

Immutability versus incident response. Immutable containers are destroyed on incident detection rather than forensically examined in place. This preserves infrastructure integrity but destroys ephemeral evidence. Forensic-capable incident response in cloud-native environments requires pre-configured log streaming to durable external storage — an architectural requirement that must be designed in, not retrofitted.

Common misconceptions

Misconception: Containers provide security isolation equivalent to virtual machines.
Containers share the host kernel. A container escape vulnerability — such as CVE-2019-5736 (runc breakout) — can allow a process inside a container to gain root access on the host. VM-level isolation requires hardware virtualization boundaries that containers do not provide. NIST SP 800-190 explicitly states that containers offer weaker isolation than hypervisor-based VMs.

Misconception: Kubernetes RBAC controls protect against all lateral movement.
RBAC controls API server access but does not govern network traffic between pods. Without Kubernetes NetworkPolicy objects (or a service mesh enforcing mTLS), pods within the same namespace can communicate freely regardless of RBAC configuration. Lateral movement through the pod network is independent of the RBAC authorization model.

Misconception: Using a private container registry eliminates supply chain risk.
Mirroring a public image to a private registry does not remediate CVEs embedded in that image. The vulnerability travels with the image layer. Private registry controls address access management and provenance tracking, not the vulnerability content of the layers themselves.

Misconception: Managed Kubernetes services (EKS, GKE, AKS) are secure by default.
Managed services handle control-plane availability and underlying infrastructure patching. Node configuration, pod security admission policies, RBAC bindings, network policies, and secrets management remain the customer's responsibility. The shared responsibility model for managed Kubernetes is documented in each major cloud provider's security documentation and audited under SOC 2 and ISO 27001 frameworks.

Checklist or steps (non-advisory)

The following sequence describes the standard control implementation phases in cloud-native application security programs, as reflected in NSA/CISA Kubernetes Hardening Guidance and NIST SP 800-190:

1. Inventory all container images and base layers — catalog registry sources, base image versions, and active deployment tags across all environments.
2. Integrate image scanning into the CI pipeline — configure scanning against the NVD CVE database at build time with defined severity thresholds for pipeline gates.
3. Generate and sign SBOMs — produce machine-readable SBOMs (SPDX or CycloneDX format) for each build artifact and store them alongside the image digest.
4. Enforce pod security standards — apply Kubernetes Pod Security Admission at the restricted or baseline profile per namespace classification.
5. Define and enforce RBAC policies — audit all ClusterRoleBindings and RoleBindings; remove wildcard resource permissions and cluster-admin grants not required by system components.
6. Implement network policies — define default-deny ingress and egress policies per namespace; specify explicit allow rules for required service-to-service paths.
7. Enable and export audit logging — configure the Kubernetes API server audit policy to log at RequestResponse level for sensitive resource types; ship logs to a durable external SIEM.
8. Deploy runtime threat detection — instrument the node layer with an eBPF-based detection engine; define behavioral baselines per workload.
9. Harden the IaC layer — scan Terraform, Helm charts, and Kubernetes manifests with policy-as-code tools against CIS Benchmark rules for the target cloud platform.
10. Conduct periodic adversarial assessment — perform cloud-native penetration tests against the control plane, service mesh, and pipeline attack surface on a defined recurrence schedule.

Further context on integrating these phases into delivery workflows is available through the how to use this application security resource reference page.

Reference table or matrix