OWASP Cloud-Native Application Security Top 10

1�E�⃣ CNAS-1 - Configuración Insegura de Nube, Contenedores u Orquestación

Descripción General

Los servicios en la nube, contenedores y orquestadores mal configurados son la causa principal de brechas en entornos nativos de la nube. Esto incluye ejecutar contenedores como root, usar configuraciones predeterminadas, exponer públicamente el servidor API de Kubernetes y no habilitar el registro de auditoría en recursos de la nube.

Ejemplo de Código Vulnerable

# 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  Eruns as root!
CMD ["/app/server"]

Ejemplo de Código Seguro

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

Lista de Verificación de Mitigación

• Use imágenes base mínimas sin distribución y nunca ejecute contenedores como root
• Habilite y aplique Pod Security Standards (restricted) en Kubernetes
• Escanee infraestructura como código (Terraform, Helm) con herramientas como Checkov o tfsec
• Restrinja el acceso a endpoints de metadatos de la nube (169.254.169.254) y al servidor API de Kubernetes

2�E�⃣ CNAS-2 - Fallas de Inyección (Capa de Aplicación, Eventos de Nube, Servicios de Nube)

Descripción General

Las aplicaciones nativas de la nube reciben entrada no solo de solicitudes HTTP tradicionales sino también de eventos de la nube (SQS, Pub/Sub, EventBridge), disparadores serverless y comunicación entre servicios. Las fallas de inyección en cualquiera de estos vectores pueden llevar a la ejecución de comandos, exfiltración de datos o escalada de privilegios.

Ejemplo de Código Vulnerable

# 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}")

Ejemplo de Código Seguro

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]}')

Lista de Verificación de Mitigación

• Valide y sanitice todas las entradas de eventos de la nube, colas y disparadores
• Use llamadas SDK/API en lugar de comandos de shell (evite os.system, subprocess con shell=True)
• Aplique esquemas de validación de entrada a cargas de eventos (JSON Schema, protobuf)
• Implemente filtrado de salida para prevenir SSRF desde funciones serverless

3�E�⃣ CNAS-3 - Autenticación y Autorización Inadecuadas

Descripción General

Los entornos nativos de la nube involucran múltiples capas de identidad: IAM de la nube, RBAC de Kubernetes, mTLS de service mesh y autenticación a nivel de aplicación. Las políticas mal configuradas o excesivamente permisivas en cualquier capa pueden permitir movimiento lateral, escalada de privilegios o acceso no autorizado a recursos sensibles.

Ejemplo de Código Vulnerable

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

Ejemplo de Código Seguro

# 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"]

Lista de Verificación de Mitigación

• Use ServiceAccounts dedicadas por carga de trabajo con RBAC de mínimo privilegio
• Implemente IAM Roles for Service Accounts (IRSA/Workload Identity) en lugar de credenciales a nivel de nodo
• Aplique TLS mutuo (mTLS) para toda la comunicación de servicio a servicio
• Audite los enlaces RBAC regularmente y elimine los permisos no utilizados

4�E�⃣ CNAS-4 - Fallas en Pipeline CI/CD y Cadena de Suministro de Software

Descripción General

Los pipelines CI/CD son objetivos de alto valor porque tienen acceso de escritura a entornos de producción. Comprometer un pipeline de construcción permite ataques a la cadena de suministro, inyección de código malicioso y despliegue de imágenes con puertas traseras. Las configuraciones inseguras de pipelines, imágenes base envenenadas y artefactos sin firmar contribuyen a este riesgo.

Ejemplo de Código Vulnerable

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

Ejemplo de Código Seguro

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

Lista de Verificación de Mitigación

• Fije acciones y dependencias de CI/CD a hashes SHA exactos, no a ramas o etiquetas
• Firme imágenes de contenedores con Cosign/Notary y aplique verificación de firma en la admisión
• Escanee imágenes en busca de vulnerabilidades (Trivy, Grype) antes del despliegue
• Use el framework SLSA para garantizar la procedencia e integridad de los artefactos de construcción

5�E�⃣ CNAS-5 - Almacenamiento Inseguro de Secretos

Descripción General

Los secretos como claves API, credenciales de bases de datos y certificados TLS a menudo están codificados en el código fuente, almacenados en ConfigMaps de texto plano o integrados en imágenes de contenedores. Los Secrets de Kubernetes solo están codificados en base64 por defecto, no encriptados, proporcionando protección mínima.

Ejemplo de Código Vulnerable

# 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!

Ejemplo de Código Seguro

# 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

Lista de Verificación de Mitigación

• Nunca almacene secretos en código fuente, Dockerfiles o ConfigMaps de texto plano
• Use un gestor de secretos (Vault, AWS Secrets Manager, GCP Secret Manager) con rotación automática
• Habilite el cifrado en reposo para Secrets de Kubernetes (proveedor KMS)
• Escanee repositorios e imágenes en busca de secretos filtrados (git-secrets, TruffleHog, Trivy)

6�E�⃣ CNAS-6 - Políticas de Red Excesivamente Permisivas o Inseguras

Descripción General

Por defecto, Kubernetes permite que todos los pods se comuniquen entre sí sin restricción. Las NetworkPolicies faltantes o excesivamente permisivas, grupos de seguridad y reglas de firewall habilitan el movimiento lateral dentro del clúster y entre servicios de la nube.

Ejemplo de Código Vulnerable

# No NetworkPolicy  Eall 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

Ejemplo de Código Seguro

# 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

Lista de Verificación de Mitigación

• Implemente NetworkPolicies de denegación por defecto para todos los namespaces
• Permita solo el tráfico requerido entre servicios usando selectores de etiquetas
• Restrinja el tráfico de salida para prevenir la exfiltración de datos y comunicación C2
• Use un plugin CNI que soporte la aplicación de NetworkPolicy (Calico, Cilium)

7�E�⃣ CNAS-7 - Uso de Componentes con Vulnerabilidades Conocidas

Descripción General

Las aplicaciones nativas de la nube dependen en gran medida de imágenes base de código abierto, bibliotecas y operadores de Kubernetes. Ejecutar componentes desactualizados o sin parches con CVE conocidos expone la aplicación a exploits bien documentados. Las imágenes de contenedores a menudo incluyen cientos de paquetes, cada uno una vulnerabilidad potencial.

Ejemplo de Código Vulnerable

# 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"]

Ejemplo de Código Seguro

# 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"]

Lista de Verificación de Mitigación

• Escanee continuamente las imágenes de contenedores en busca de CVE en CI/CD y en tiempo de ejecución
• Use imágenes base mínimas (distroless, Alpine) para reducir la superficie de ataque
• Automatice las actualizaciones de dependencias con Dependabot, Renovate o herramientas similares
• Mantenga un SBOM y rastree las versiones de componentes en todos los despliegues

8�E�⃣ CNAS-8 - Gestión de Activos Inadecuada

Descripción General

Los entornos nativos de la nube facilitan la creación de recursos pero dificultan su seguimiento. Los contenedores huérfanos, namespaces olvidados, recursos de la nube obsoletos y despliegues de TI en la sombra crean una superficie de ataque no administrada. Sin un inventario adecuado de activos, los equipos de seguridad no pueden proteger lo que no saben que existe.

Ejemplo de Código Vulnerable

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

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

Ejemplo de Código Seguro

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 }
  }
}

Lista de Verificación de Mitigación

• Mantenga un inventario en tiempo real de todos los recursos de la nube, clústeres y namespaces
• Aplique políticas de etiquetado obligatorias (propietario, entorno, expiración) para todos los recursos
• Automatice la detección y limpieza de recursos huérfanos (AWS Config, GCP Asset Inventory)
• Implemente infraestructura como código para prevenir la creación manual de recursos no rastreados

9�E�⃣ CNAS-9 - Límites de Cuota de Recursos de Cómputo Inadecuados

Descripción General

Sin las cuotas y límites de recursos adecuados, una sola carga de trabajo mal comportada o comprometida puede consumir toda la CPU, memoria o almacenamiento disponible, causando denegación de servicio para otras aplicaciones. Los ataques de criptojacking son particularmente comunes en entornos sin límites de recursos.

Ejemplo de Código Vulnerable

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

Ejemplo de Código Seguro

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"

Lista de Verificación de Mitigación

• Establezca solicitudes/límites de CPU y memoria en cada contenedor
• Aplique ResourceQuotas y LimitRanges a nivel de namespace
• Monitoree el uso de recursos y alerte sobre patrones de consumo anómalos
• Use el cluster autoscaler con límites máximos de nodos para prevenir escalado ilimitado

🔟 CNAS-10 - Registro y Monitoreo Ineficaces

Descripción General

Los entornos nativos de la nube generan registros en múltiples capas: aplicación, runtime de contenedores, orquestador, service mesh y plataforma de la nube. Sin registro centralizado, correlación entre estas capas y detección de amenazas en tiempo de ejecución, los incidentes de seguridad pasan desapercibidos o se descubren demasiado tarde.

Ejemplo de Código Vulnerable

# 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  Elost when pod restarts
    # No audit logging configured on the cluster
    # No runtime security monitoring

Ejemplo de Código Seguro

# 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

Lista de Verificación de Mitigación

• Habilite el registro de auditoría de Kubernetes y reenvíe a un SIEM centralizado
• Despliegue herramientas de seguridad en tiempo de ejecución (Falco, Sysdig) para detección de amenazas en tiempo real
• Use agregación de registros (Fluent Bit, Loki) para persistir registros de contenedores más allá del ciclo de vida del pod
• Cree alertas para eventos críticos de seguridad: acceso a secretos, cambios RBAC, exec en pods

📊 Tabla de Resumen