OWASP Cloud-Native Application Security Top 10

1�E�⃣ CNAS-1 - Configuração Insegura de Nuvem, Contêiner ou Orquestração

Visão Geral

Serviços de nuvem, contêineres e orquestradores mal configurados são a principal causa de violações nativas de nuvem. Isso inclui executar contêineres como root, usar configurações padrão, expor o servidor de API do Kubernetes publicamente e não habilitar o registro de auditoria em recursos de nuvem.

Exemplo de Código Vulnerável

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

Exemplo 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 Verificação de Mitigação

• Use imagens base mínimas e distroless e nunca execute contêineres como root
• Habilite e imponha Pod Security Standards (restrito) no Kubernetes
• Escaneie infraestrutura como código (Terraform, Helm) com ferramentas como Checkov ou tfsec
• Restrinja o acesso aos endpoints de metadados de nuvem (169.254.169.254) e ao servidor de API do Kubernetes

2�E�⃣ CNAS-2 - Falhas de Injeção (Camada de Aplicação, Eventos de Nuvem, Serviços de Nuvem)

Visão Geral

Aplicações nativas de nuvem recebem entrada não apenas de requisições HTTP tradicionais, mas também de eventos de nuvem (SQS, Pub/Sub, EventBridge), gatilhos serverless e comunicação entre serviços. Falhas de injeção em qualquer um desses vetores podem levar à execução de comandos, exfiltração de dados ou escalação de privilégios.

Exemplo de Código Vulnerável

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

Exemplo 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 Verificação de Mitigação

• Valide e sanitize todas as entradas de eventos de nuvem, filas e gatilhos
• Use chamadas de SDK/API em vez de comandos shell (evite os.system, subprocess com shell=True)
• Aplique esquemas de validação de entrada a cargas de evento (JSON Schema, protobuf)
• Implemente filtragem de saída para prevenir SSRF de funções serverless

3�E�⃣ CNAS-3 - Autenticação e Autorização Inadequadas

Visão Geral

Ambientes nativos de nuvem envolvem várias camadas de identidade: IAM de nuvem, RBAC do Kubernetes, mTLS de malha de serviço e autenticação em nível de aplicação. Políticas mal configuradas ou excessivamente permissivas em qualquer camada podem permitir movimento lateral, escalação de privilégios ou acesso não autorizado a recursos sensíveis.

Exemplo de Código Vulnerável

# 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

Exemplo 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 Verificação de Mitigação

• Use ServiceAccounts dedicadas por carga de trabalho com RBAC de privilégio mínimo
• Implemente IAM Roles for Service Accounts (IRSA/Workload Identity) em vez de credenciais em nível de nó
• Imponha TLS mútuo (mTLS) para toda comunicação serviço-a-serviço
• Audite vinculações RBAC regularmente e remova permissões não utilizadas

4�E�⃣ CNAS-4 - Falhas de Pipeline CI/CD e Cadeia de Suprimentos de Software

Visão Geral

Pipelines CI/CD são alvos de alto valor porque têm acesso de gravação aos ambientes de produção. Comprometer um pipeline de build permite ataques à cadeia de suprimentos, injeção de código malicioso e implantação de imagens com backdoor. Configurações inseguras de pipeline, imagens base envenenadas e artefatos não assinados contribuem para esse risco.

Exemplo de Código Vulnerável

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

Exemplo 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 Verificação de Mitigação

• Fixe ações e dependências de CI/CD em hashes SHA exatos, não em branches ou tags
• Assine imagens de contêiner com Cosign/Notary e imponha verificação de assinatura na admissão
• Escaneie imagens em busca de vulnerabilidades (Trivy, Grype) antes da implantação
• Use o framework SLSA para garantir proveniência e integridade de artefatos de build

5�E�⃣ CNAS-5 - Armazenamento Inseguro de Segredos

Visão Geral

Segredos como chaves de API, credenciais de banco de dados e certificados TLS são frequentemente codificados no código-fonte, armazenados em ConfigMaps de texto simples ou incorporados em imagens de contêiner. Secrets do Kubernetes são apenas codificados em base64 por padrão, não criptografados, fornecendo proteção mínima.

Exemplo de Código Vulnerável

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

Exemplo 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 Verificação de Mitigação

• Nunca armazene segredos em código-fonte, Dockerfiles ou ConfigMaps de texto simples
• Use um gerenciador de segredos (Vault, AWS Secrets Manager, GCP Secret Manager) com rotação automática
• Habilite criptografia em repouso para Secrets do Kubernetes (provedor KMS)
• Escaneie repositórios e imagens em busca de segredos vazados (git-secrets, TruffleHog, Trivy)

6�E�⃣ CNAS-6 - Políticas de Rede Excessivamente Permissivas ou Inseguras

Visão Geral

Por padrão, o Kubernetes permite que todos os pods se comuniquem entre si sem restrição. NetworkPolicies ausentes ou excessivamente permissivas, grupos de segurança e regras de firewall permitem movimento lateral dentro do cluster e entre serviços de nuvem.

Exemplo de Código Vulnerável

# 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

Exemplo 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 Verificação de Mitigação

• Implemente NetworkPolicies de negação padrão para todos os namespaces
• Permita apenas o tráfego necessário entre serviços usando seletores de rótulo
• Restrinja o tráfego de saída para prevenir exfiltração de dados e comunicação C2
• Use um plugin CNI que suporte imposição de NetworkPolicy (Calico, Cilium)

7�E�⃣ CNAS-7 - Uso de Componentes com Vulnerabilidades Conhecidas

Visão Geral

Aplicações nativas de nuvem dependem fortemente de imagens base de código aberto, bibliotecas e operadores do Kubernetes. Executar componentes desatualizados ou sem patches com CVEs conhecidos expõe a aplicação a explorações bem documentadas. Imagens de contêiner frequentemente incluem centenas de pacotes, cada um uma vulnerabilidade potencial.

Exemplo de Código Vulnerável

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

Exemplo 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 Verificação de Mitigação

• Escaneie continuamente imagens de contêiner em busca de CVEs em CI/CD e em tempo de execução
• Use imagens base mínimas (distroless, Alpine) para reduzir a superfície de ataque
• Automatize atualizações de dependências com Dependabot, Renovate ou ferramentas similares
• Mantenha um SBOM e rastreie versões de componentes em todas as implantações

8�E�⃣ CNAS-8 - Gerenciamento Inadequado de Ativos

Visão Geral

Ambientes nativos de nuvem facilitam a criação de recursos, mas dificultam seu rastreamento. Contêineres órfãos, namespaces esquecidos, recursos de nuvem obsoletos e implantações de TI sombra criam uma superfície de ataque não gerenciada. Sem inventário adequado de ativos, equipes de segurança não podem proteger o que não sabem que existe.

Exemplo de Código Vulnerável

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

Exemplo 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 Verificação de Mitigação

• Mantenha um inventário em tempo real de todos os recursos de nuvem, clusters e namespaces
• Imponha políticas de marcação obrigatórias (proprietário, ambiente, expiração) para todos os recursos
• Automatize a detecção e limpeza de recursos órfãos (AWS Config, GCP Asset Inventory)
• Implemente infraestrutura como código para prevenir criação manual de recursos não rastreados

9�E�⃣ CNAS-9 - Limites Inadequados de Quota de Recursos Computacionais

Visão Geral

Sem quotas e limites de recursos adequados, uma única carga de trabalho com mau funcionamento ou comprometida pode consumir toda a CPU, memória ou armazenamento disponível, causando negação de serviço para outras aplicações. Ataques de cryptojacking são particularmente comuns em ambientes sem limites de recursos.

Exemplo de Código Vulnerável

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

Exemplo 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 Verificação de Mitigação

• Defina solicitações e limites de CPU e memória em cada contêiner
• Imponha ResourceQuotas e LimitRanges no nível do namespace
• Monitore o uso de recursos e alerte sobre padrões de consumo anômalos
• Use cluster autoscaler com limites máximos de nós para prevenir escalonamento ilimitado

🔟 CNAS-10 - Registro e Monitoramento Ineficazes

Visão Geral

Ambientes nativos de nuvem geram logs em várias camadas: aplicação, tempo de execução de contêiner, orquestrador, malha de serviço e plataforma de nuvem. Sem registro centralizado, correlação entre essas camadas e detecção de ameaças em tempo de execução, incidentes de segurança passam despercebidos ou são descobertos tarde demais.

Exemplo de Código Vulnerável

# 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

Exemplo 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 Verificação de Mitigação

• Habilite registro de auditoria do Kubernetes e encaminhe para um SIEM centralizado
• Implante ferramentas de segurança em tempo de execução (Falco, Sysdig) para detecção de ameaças em tempo real
• Use agregação de logs (Fluent Bit, Loki) para persistir logs de contêiner além do ciclo de vida do pod
• Crie alertas para eventos críticos de segurança: acesso a segredos, alterações de RBAC, exec em pods

📊 Tabela Resumida