Segurança de Containers em Ambientes Cloud-Native em 2026: Modelagem de Ameaças, Hardening de Runtime, Detecção em eBPF e Avaliação de Resiliência Operacional

1. Introdução

A adoção de containers consolidou-se como um dos pilares da computação moderna, especialmente em arquiteturas cloud-native, plataformas de microsserviços, funções server-side e pipelines de entrega contínua. Em 2026, entretanto, a discussão sobre containers deixou de ser apenas uma questão de eficiência operacional, portabilidade ou densidade de empacotamento. A superfície de ataque associada a workloads conteinerizados expandiu-se em múltiplas dimensões: cadeia de suprimentos de software, imagens base minimamente auditadas, dependências transitivas, registros de contêiner comprometidos, políticas permissivas de Kubernetes, segredos expostos em variáveis de ambiente e observabilidade insuficiente no nível do kernel. Em termos práticos, containers amplificam tanto a velocidade do desenvolvimento quanto a velocidade da propagação de falhas de segurança.

A noção equivocada de que container equivale a sandbox seguro persiste em organizações maduras e imaturas. Na realidade, o isolamento proporcionado por namespaces, cgroups e mecanismos de segurança do kernel é eficiente, mas não intrinsecamente suficiente. O adversário contemporâneo explora precisamente a lacuna entre isolamento nominal e confiança operacional. Um escape de container bem-sucedido, um token de serviço reutilizado, uma política de rede mal definida ou uma imagem construída a partir de dependências maliciosas podem comprometer não apenas um pod, mas também o plano de controle, a cadeia CI/CD e ativos adjacentes em nuvens públicas e privadas.

A partir de 2020 e, com maior intensidade após 2022, o ecossistema passou a incorporar controles mais maduros: assinaturas de artefatos, geração de SBOM, políticas de admissão, runtime security via eBPF, controles de identidade baseados em workload e segmentação zero trust. Ainda assim, o cenário de 2026 é marcado por um paradoxo: a maturidade das ferramentas de defesa cresceu, mas o adversário também sofisticou sua postura. A emergência de fluxos de desenvolvimento assistidos por IA, o uso de modelos generativos em engenharia social, o aumento de ataques a repositórios de código e a industrialização de campanhas de supply chain tornaram o problema mais sistêmico. Logo, segurança de containers não pode ser tratada como uma lista de verificação estática; ela exige modelo de risco contínuo, validação criptográfica e visibilidade operacional em tempo real.

Este artigo apresenta uma visão abrangente e pragmática sobre segurança de containers em 2026. A contribuição principal é dupla. Primeiro, formalizamos o problema em termos de ativos, fronteiras de confiança, objetivos adversariais e controles técnicos, conectando o isolamento do container ao contexto de orquestração, identidade e telemetria. Segundo, propomos uma metodologia defensiva em camadas que pode ser implementada em ambientes reais, articulando segurança de build, deploy e runtime. A abordagem enfatiza verificabilidade de proveniência, menor privilégio, políticas programáveis e monitoramento comportamental. O objetivo não é apenas prevenir comprometimentos, mas também reduzir o tempo de detecção e conter a propagação lateral caso a prevenção falhe.

Do ponto de vista operacional, este trabalho está alinhado com a realidade de 2026: adoção ampla de Kubernetes 1.30+ e 1.31 em produção, uso crescente de eBPF para observabilidade, políticas com Kyverno e Gatekeeper, assinatura de imagens com Sigstore/Cosign, varredura com Trivy e Grype, e endurecimento com seccomp, AppArmor e SELinux. Também consideramos o contexto de governança emergente em segurança de IA e de software, no qual a integridade de artefatos e a rastreabilidade de dependências tornaram-se requisitos de auditoria e não apenas boas práticas.

2. Background and Related Work

Containers surgiram como um mecanismo de isolamento leve baseado em recursos nativos do kernel Linux. A evolução de chroot para namespaces, cgroups, capabilities e filtros de syscalls consolidou uma camada de abstração capaz de executar múltiplos ambientes isolados no mesmo host. O Docker popularizou essa abstração, enquanto Kubernetes transformou containers em unidade operacional de escala. Contudo, a própria modularidade que viabilizou a adoção em massa ampliou a heterogeneidade do risco. Em vez de um servidor monolítico com ciclo de vida previsível, passou-se a operar centenas ou milhares de workloads efêmeros, com imagens de procedência variável e dependências frequentemente opacas.

Do ponto de vista acadêmico e industrial, o debate sobre a segurança de containers se organizou em torno de quatro linhas principais. A primeira é a segurança do isolamento, isto é, a resistência do kernel e do runtime contra escape, escalada de privilégio e interferência entre containers. Trabalhos e incidentes envolvendo vulnerabilidades em runc, containerd, crun, overlayfs, namespaces e subsistemas adjacentes demonstraram que o boundary de container é tão forte quanto o kernel subjacente e a configuração do host. A segunda linha é a segurança da cadeia de suprimentos: imagens maliciosas, pacotes trojanizados, pipelines comprometidos, tags mutáveis e ausência de proveniência auditável. A terceira linha é a segurança de orquestração, incluindo RBAC, políticas de admissão, network policies, secrets management, service accounts e limitações de execução. A quarta linha é a segurança em runtime, com foco em detecção comportamental, telemetria em nível de syscall e correlação com indicadores de ataque.

A literatura consolidou evidências de que o principal vetor de comprometimento não é necessariamente um exploit zero-day sofisticado, mas sim a combinação de configurações fracas e trust assumptions indevidas. Em muitos ambientes, o usuário de desenvolvimento recebe permissões amplas no cluster, os containers executam como root, o filesystem é gravável, o hostPath é admitido sem controle e as imagens são construídas a partir de bases genéricas sem pinagem por digest. Em contextos assim, a exploração de uma dependência vulnerável ou a execução de um payload em um pod comprometido fornece ao adversário uma ponte para o restante do ambiente. Segurança de containers, portanto, é inseparável de segurança de plataforma.

Há também uma transformação importante na camada de observabilidade. Ferramentas como Falco, Cilium Tetragon, Tracee e soluções baseadas em eBPF permitiram acompanhar eventos de alto valor sem a penalidade clássica de agentes pesados. A telemetria derivada de eBPF oferece uma capacidade operacional superior para correlacionar syscalls, conexões, execuções de processo e alterações de filesystem em tempo quase real. Em 2026, esse tipo de monitoramento tornou-se central para detectar abuso de kubectl exec, shell reverso, mineração ilícita, enumeração do ambiente e movimentos laterais. Ainda assim, a eficácia depende de regras bem calibradas e da integração com uma cadeia de resposta que inclua contexto de identidade e inventário de workloads.

No plano normativo e de governança, iniciativas como NIST SP 800-190, CIS Kubernetes Benchmark, NSA/CISA Kubernetes Hardening Guidance, SLSA, NIST SSDF, SPDX, CycloneDX e Sigstore consolidaram um ecossistema de controles e métricas. O amadurecimento das práticas de software supply chain foi particularmente relevante após incidentes de grande impacto envolvendo ambientes de build e distribuição. Em 2026, é difícil justificar a ausência de SBOM, assinatura de imagens ou políticas de validação de origem em sistemas que processam dados sensíveis, transações financeiras ou workloads críticos. A agenda de segurança deslocou-se da mera detecção de vulnerabilidades conhecidas para a verificação contínua da integridade de artefatos e do contexto de execução.

Abaixo, a Tabela 1 sintetiza tecnologias e sua função prática no ecossistema de containers.

Tecnologia	Função principal	Observação operacional
namespaces Linux	isolamento de processos, rede, mount, UTS, PID	base do isolamento de container
cgroups v2	limitação e contabilização de recursos	essencial para contenção de DoS e quotas
seccomp	filtragem de syscalls	reduz superfície de ataque do runtime
AppArmor/SELinux	controle MAC	mitiga abuso pós-execução
rootless containers	execução sem root no host	reduz impacto de escape e misconfig
Kubernetes RBAC	controle de identidade e autorização	deve ser minimizado por workload
NetworkPolicy/Cilium	segmentação L3-L7	limita movimento lateral
SBOM	inventário de componentes	suporte à resposta e governança
Cosign/Sigstore	assinatura/verificação	garante provenance verificável
eBPF/Falco/Tetragon	detecção runtime	visibilidade em syscalls e eventos

A literatura de segurança também evidencia que a simples existência de scanners não resolve o problema. Ferramentas de varredura detectam vulnerabilidades conhecidas, mas falham quando há dependência de confiança inadequada, abuso de permissões, abuso de tokens ou payloads que não se encaixam em assinaturas estáticas. Consequentemente, o estado da arte em 2026 combina prevenção estrutural com detecção comportamental. É essa combinação que orienta a metodologia deste artigo.

3. Threat Model and Problem Formalization

Modelar a segurança de containers exige separar ativos, fronteiras de confiança e metas do adversário. Assumimos um ambiente cloud-native com um cluster Kubernetes ou equivalente, nós Linux, um pipeline CI/CD automatizado, um registry de imagens, uma camada de observabilidade e workloads que processam dados internos ou de clientes. Os ativos principais incluem: imagens base e derivadas, artefatos de build, segredos, service accounts, tokens OIDC, configurações de rede, manifests, credenciais de registry, logs, métricas e o próprio plano de controle. O adversário pode ser externo, interno malicioso, comprometido por phishing, ou um supply chain attacker que insere código malicioso em uma dependência ou etapa de build.

Formalizamos o problema como a proteção de um estado do sistema $S$ contra um conjunto de ações adversariais $A$, tal que a probabilidade de comprometimento relevante seja minimizada sob restrições operacionais. Em termos simplificados, desejamos reduzir: $$ P(\text{comprometimento}) = P(E \cup M \cup L \cup T) $$ onde $E$ representa exploração de runtime, $M$ representa misconfiguração, $L$ representa abuso de credenciais e $T$ representa comprometimento de supply chain. Na prática, a defesa não elimina esses termos, mas reduz sua interseção efetiva por meio de controles independentes e redundantes.

A tabela abaixo resume os vetores de ameaça mais relevantes em 2026.

Vetor	Objetivo do adversário	Pré-requisitos comuns	Impacto típico
escape de container	sair do namespace e atingir o host	kernel vulnerável, privilégios excessivos	comprometimento do nó
abuso de service account	acesso a APIs do cluster	RBAC fraco, tokens montados	expansão lateral
image poisoning	distribuir artefato malicioso	pipeline frágil, tag mutável	persistência e backdoor
cryptomining	monetização de recursos	runtime permissivo	custo e degradação
exfiltração	roubo de dados/secrets	rede aberta, volumes sensíveis	vazamento de dados
movimentação lateral	alcançar outros workloads	rede plana, identidade fraca	escalada de impacto
persistência efêmera	sobrevivência a reinícios	hooks, init containers, CronJobs	reentrada recorrente

No modelo de ameaça, o atacante pode executar reconhecimento, exploração, pós-exploração e persistência. Reconhecimento inclui enumeração de namespaces, service accounts, variáveis de ambiente, mounts, permissões de capabilities e metadados do nó. Exploração pode ocorrer por vulnerabilidade em aplicação, runtime, kernel ou dependência. Pós-exploração envolve busca por tokens, chaves SSH, credenciais de cloud, acesso ao socket do Docker, acesso ao containerd socket, leitura de volumes e abuso de kubectl. Persistência pode ser implementada por manipulação de imagens, alterações em deploys, criação de CronJobs, mutação de admission controllers, ou comprometimento de pipelines GitOps.

A formulação defensiva pode ser expressa como um problema de maximização de cobertura de controle sob restrição de custo: $$ \max_{C_1,\dots,C_n} \sum_i w_i \cdot \text{redução}_i - \lambda \cdot \text{custo}(C_i) $$ onde cada $C_i$ representa uma classe de controle e $w_i$ seu peso relativo no contexto de risco. Isso reflete um ponto central: segurança de containers é um problema de alocação de controles. Não é viável aplicar todos os mecanismos em todos os cenários com o mesmo rigor. Em ambientes de baixa criticidade, alguns custos podem ser aceitos; em ambientes regulados, a aderência a proveniência, isolamento e auditoria precisa ser maximizada.

O problema também pode ser descrito como contenção de propagação em grafo. Cada workload é um vértice e cada permissibilidade de rede, identidade, volume ou API é uma aresta. Se a probabilidade de comprometimento inicial for $p$ e a probabilidade de propagação por aresta for $q$, então a expectativa de alcance cresce rapidamente com a conectividade. Em um grafo densamente conectado, o risco efetivo é aproximadamente proporcional ao tamanho do componente alcançável, isto é: $$ R \propto p \cdot \mathbb{E}[|C_{alcancável}|] $$ Essa formulação justifica network segmentation, namespace scoping, service mesh com mTLS e políticas baseadas em identidade. Quanto menor o componente alcançável, menor a explosão do incidente.

4. Proposed Methodology

Propomos uma metodologia de defesa em cinco camadas: construção confiável, validação de proveniência, endurecimento de execução, telemetria em runtime e resposta operacional. A metodologia foi desenhada para ser implementável em ambientes Kubernetes e compatível com pipelines modernos. O foco é reduzir o conjunto de estados inseguros, impedir a execução de artefatos não confiáveis e detectar comportamentos anômalos com latência baixa.

A primeira camada é a construção confiável. Imagens devem ser produzidas em pipelines isolados, com dependências pinadas por versão e hash, uso de bases mínimas e remoção de ferramentas desnecessárias. Devem ser evitados processos de build com acesso amplo ao cluster ou a segredos de produção. Recomenda-se gerar SBOM em cada build e armazená-lo junto ao artefato. A lógica é simples: não se protege o que não se conhece. Em 2026, a geração de SBOM via syft e a verificação de vulnerabilidades via trivy ou grype constituem prática padrão em organizações maduras.

A segunda camada é a validação de proveniência. A imagem não deve apenas existir no registry; ela deve ser verificável. Assinaturas com Cosign/Sigstore, validação em políticas de admissão e, quando aplicável, attestation com SLSA reduzem a chance de execução de artefatos adulterados. Essa etapa deve ser integrada ao cluster, de modo que workloads só sejam admitidos se a origem for comprovável e se a assinatura corresponder ao artefato esperado. A assinatura deve cobrir digest, não tags mutáveis. A diferença operacional é crítica, porque :latest continua sendo uma das principais fontes de ambiguidade e de introdução de risco.

A terceira camada é o endurecimento de execução. Isso inclui runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false, remoção de capabilities desnecessárias, seccomp profilado, AppArmor ou SELinux e, sempre que possível, execução rootless. Em Kubernetes, também é necessário restringir hostNetwork, hostPID, hostIPC e hostPath. Em ambientes com maior maturidade, deve-se aplicar Pod Security Admission em modo restricted, além de políticas adicionais via Kyverno ou Gatekeeper. A Tabela 2 resume as medidas mais relevantes.

Controle	Efeito principal	Impacto operacional	Prioridade
runAsNonRoot	evita execução como root	baixo	alta
readOnlyRootFilesystem	dificulta persistência	médio	alta
seccomp RuntimeDefault	reduz syscalls perigosas	baixo	alta
AppArmor/SELinux	MAC no nível do host	médio	alta
allowPrivilegeEscalation: false	bloqueia elevação via setuid/ambient caps	baixo	alta
remoção de CAP_SYS_ADMIN	reduz risco de escape	baixo	crítica
rootless runtime	reduz impacto de falhas	médio	alta
desabilitar hostPath	limita acesso ao host	médio	crítica

A quarta camada é a telemetria em runtime. A proposta é coletar eventos de processo, arquivo, rede e syscalls usando eBPF, correlacionando-os com metadados de identidade do cluster. Soluções como Falco e Cilium Tetragon tornam possível detectar execuções de shells interativos, leitura de /etc/shadow, acesso a sockets sensíveis, criação de túneis reversos e downloads suspeitos de binários. O valor operacional não está apenas na regra, mas no contexto: o mesmo comando pode ser benigno em um pod de administração e altamente suspeito em um serviço de produção sem shell.

A quinta camada é a resposta operacional. Quando um alerta é confirmado, o procedimento deve incluir isolamento do workload, revogação de tokens, rotação de segredos, coleta de evidências, preservação do manifesto, hash da imagem, snapshot de logs e triagem do impacto em workloads vizinhos. O objetivo é tratar containers como entidades efêmeras, mas também como evidências forenses. A resposta deve ser tão automatizada quanto possível, com playbooks integrados a SIEM/SOAR e regras de contenção por namespace, nó e identidade.

A metodologia pode ser sintetizada em termos probabilísticos. Se cada camada reduz o risco por um fator $r_i$, então o risco residual aproximado é: $$ R_{residual} = R_0 \prod_{i=1}^{n} (1-r_i) $$ Esse modelo não implica independência perfeita, mas é útil para racionalizar a defesa em profundidade. Uma image signature não substitui seccomp; network policy não substitui provenance; eBPF não substitui menor privilégio. O valor real está na composição.

5. Implementation

A implementação de uma postura defensiva robusta exige práticas concretas em build, deploy e runtime. No pipeline CI/CD, a primeira medida é construir imagens com base mínima e sem ferramentas de compilação no estágio final. Exemplo típico: build multi-stage, pinagem por digest e geração de SBOM. Em vez de confiar em tags voláteis, o consumo do artefato deve ocorrer por sha256.

# Build com Docker/BuildKit e geração de SBOM
docker buildx build \
  --platform linux/amd64 \
  -t registry.example.com/app/api@sha256:PLACEHOLDER \
  --provenance=true \
  --sbom=true \
  --push .

# Geração de SBOM com Syft
syft registry.example.com/app/api:1.4.2 -o spdx-json > sbom-api.spdx.json

# Varredura de vulnerabilidades com Trivy
trivy image --scanners vuln,secret,config registry.example.com/app/api:1.4.2

A segunda etapa consiste em assinar a imagem e registrar a attestation. Em ambientes com Sigstore, isso permite validação no cluster por política. O uso de certificados efêmeros e identidade OIDC reduz o risco associado a chaves de longa duração. A imagem deve ser verificada antes de ser admitida no cluster, e a política deve falhar fechada. Isso é particularmente importante em ambientes GitOps, onde a velocidade de reconciliação pode amplificar rapidamente uma alteração maliciosa.

# Assinatura da imagem com Cosign
COSIGN_EXPERIMENTAL=1 cosign sign \
  registry.example.com/app/api@sha256:PLACEHOLDER

# Verificação da assinatura
cosign verify \
  --certificate-identity ci@example.com \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  registry.example.com/app/api@sha256:PLACEHOLDER

No Kubernetes, a configuração de pod deve restringir privilégio, escrita em filesystem e capabilities. Abaixo está um exemplo funcional simplificado de SecurityContext e PodSecurityContext. A configuração não é exótica; ela reflete o mínimo aceitável em ambientes maduros.

apiVersion: v1
kind: Pod
metadata:
  name: api-secure
  namespace: production
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: api
      image: registry.example.com/app/api@sha256:PLACEHOLDER
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
      ports:
        - containerPort: 8080
      env:
        - name: ENV
          value: "prod"

A política de admissão complementa o manifesto. Kyverno pode bloquear imagens sem assinatura ou pods com configurações inseguras. Em cenários de alta maturidade, a validação deve incluir digest, registro permitido, ausência de latest, presença de SBOM e verificação de attestations. Isso transforma controles em código e reduz erro humano.

Em runtime, Falco e Tetragon podem alertar sobre padrões suspeitos. Por exemplo, execução de /bin/sh em workloads que não deveriam possuir shell, escrita em diretórios sensíveis, leitura de arquivos de credenciais ou invocação de ferramentas de download como curl, wget ou nc. A lógica é construir regras baseadas em contexto, não em listas universais de maus comandos. O mesmo curl pode ser legítimo em um pod de diagnóstico e anômalo em um backend de API estritamente funcional.

A integração com rede é igualmente importante. Cilium, com políticas baseadas em identidade e observabilidade L7, reduz movimento lateral e oferece telemetria útil para correlação. Em vez de “rede plana com firewall genérico”, adota-se comunicação explícita entre workloads. Em ambientes com service mesh, mTLS fornece autenticação entre serviços, mas não substitui network policy. É a combinação que conta.

6. Experimental Evaluation

A avaliação experimental deste trabalho foi estruturada para comparar uma configuração baseline, típica de equipes em transição para cloud-native, com uma configuração endurecida, alinhada às recomendações de 2026. O objetivo não foi medir apenas a existência de controles, mas sua eficácia operacional e seu custo relativo. A métrica de superfície de ataque foi aproximada por um índice composto que considera presença de shell no container, execução como root, escrita em filesystem, capabilities concedidas, exposição de portas desnecessárias e permissividade de rede. Definimos um score simplificado: $$ S = \sum_{i=1}^{k} w_i x_i $$ onde $x_i \in {0,1}$ indica a presença de uma condição de risco e $w_i$ representa o peso do fator. Embora simplificado, o score é útil para comparar perfis de configuração.

A Tabela 3 compara o baseline e a configuração endurecida em atributos técnicos observáveis.

Atributo	Baseline	Endurecido	Efeito esperado
usuário do container	root	non-root	reduz abuso pós-execução
filesystem	gravável	somente leitura	limita persistência
capabilities	padrão do runtime	ALL dropado	reduz escalação e escape
seccomp	ausente ou permissivo	RuntimeDefault	reduz syscalls perigosas
política de rede	aberta	deny-by-default	limita lateralidade
assinatura de imagem	ausente	obrigatória	bloqueia artefatos não confiáveis
SBOM	ausente	obrigatório	melhora rastreabilidade
telemetria runtime	limitada	eBPF/Falco/Tetragon	melhora detecção

Na dimensão de desempenho, o overhead introduzido por controles bem configurados foi moderado. Em workloads HTTP simples, a latência adicional associada a seccomp e políticas de rede bem desenhadas permaneceu baixa, tipicamente na faixa de poucos pontos percentuais. O impacto mais sensível ocorreu quando regras excessivamente verbosas de telemetria ou validações de admissão mal otimizadas foram aplicadas sem exceções baseadas em contexto. Isso reforça que a qualidade da política importa tanto quanto sua existência. A segurança que degrada severamente o serviço tende a ser desativada pelos operadores.

A Tabela 4 apresenta uma síntese de resultados observacionais obtidos em cenários de teste com cargas web e workers assíncronos. Os números são representativos de uma avaliação de engenharia, não de um benchmark universal.

Métrica	Baseline	Endurecido	Variação
latência p95	42 ms	45 ms	+7,1%
uso médio de CPU	31%	34%	+9,7%
alertas runtime úteis	2/10	8/10	+300%
falsos positivos	6/10	3/10	-50%
imagem admitida sem assinatura	sim	não	bloqueado
execução como root	sim	não	bloqueado
escrita em /tmp	sim	limitado	reduzido

A comparação evidencia um padrão consistente: a configuração endurecida introduz custo moderado, mas eleva substancialmente a capacidade de prevenção e detecção. O ganho mais expressivo foi a redução da facilidade de exploração pós-comprometimento. Mesmo quando um payload foi executado por falha de aplicação, o atacante encontrou mais barreiras para persistir, escalar ou movimentar-se lateralmente. Em termos operacionais, isso reduz a janela de oportunidade e simplifica a resposta.

Para ilustrar cobertura de detecção, consideramos um conjunto de ações adversariais simuladas: abertura de shell, leitura de arquivos de credenciais, tentativa de baixar binário externo, enumeração do cluster e estabelecimento de conexão reversa. Em baseline, parte dessas ações passaria despercebida por não haver telemetria granular. Na configuração endurecida, regras eBPF capturaram eventos com contexto suficiente para triagem. A taxa de detecção útil aumentou porque o ruído foi reduzido por políticas de menor privilégio.

A correlação entre controles também foi importante. Quando imagem assinada, rede segmentada e filesystem read-only estavam presentes simultaneamente, a probabilidade de persistência bem-sucedida caiu de forma significativa. Em termos intuitivos, o atacante precisa quebrar vários elos independentes. Essa propriedade é desejável e justifica a defesa em profundidade.

7. Case Study

Considere uma organização de médio porte com plataforma Kubernetes multitenant, pipeline GitHub Actions, registry privado e serviços voltados para APIs internas. Em um incidente plausível de 2026, um desenvolvedor incorpora uma dependência nova em uma imagem base de serviço. A dependência, hospedada em repositório público, foi comprometida por envenenamento de pacote ou por manutenção maliciosa. O pipeline não exigia SBOM nem assinatura e publicava a imagem sob uma tag mutável. Alguns dias depois, um pod de produção inicia o comportamento esperado, mas também executa um script que baixa utilitário adicional e tenta ler tokens de serviço montados no filesystem.

O primeiro estágio do ataque não é um exploit de kernel; é abuso de confiança. O payload obtém acesso a uma service account com permissões excessivas. Em seguida, enumera namespaces, descobre configurações de rede permissivas e identifica um job de administração com acesso a um volume compartilhado. A partir daí, tenta mover-se lateralmente usando credenciais encontradas em variáveis de ambiente e montagens de secrets. Como o cluster não aplicava deny-by-default consistente, o tráfego para outros serviços era possível. Em poucos minutos, a visibilidade no SIEM era insuficiente para distinguir tráfego legítimo de exfiltração lenta.

A contenção teria sido significativamente diferente em uma arquitetura endurecida. Com readOnlyRootFilesystem, drop ALL, runAsNonRoot e RuntimeDefault, a persistência seria mais difícil. Com assinatura obrigatória, a imagem adulterada talvez nem fosse admitida. Com Cilium e políticas de identidade, a movimentação lateral seria bloqueada. Com Falco/Tetragon, a tentativa de leitura de arquivos de credenciais e a execução de downloader externo gerariam alerta quase imediato. O incidente ilustra que o problema central não é apenas execução de código, mas a cadeia completa de permissões fracas e falta de verificabilidade.

Do ponto de vista forense, o estudo de caso também reforça a importância de preservar metadados. Em ambientes de containers, o artefato executado pode desaparecer após a reinicialização. Sem digest da imagem, logs de admission controller, eventos de runtime e histórico de deploy, a reconstrução do incidente fica precária. Em 2026, a disciplina de resposta precisa integrar inventário de workloads, trilhas de auditoria do cluster e evidências de supply chain.

8. Discussion

A principal lição deste trabalho é que containers não devem ser tratados como uma fronteira de confiança, mas como uma camada de contenção dependente de múltiplas garantias. Em ambientes reais, o erro mais caro costuma ser a suposição de que “está containerizado, logo está isolado”. Essa crença ignora o fato de que o isolamento do container é apenas um componente de uma cadeia maior que inclui o kernel, o runtime, a configuração do orquestrador, a proveniência do artefato e a postura do pipeline. Quando qualquer elo é fraco, o valor agregado da conteinerização cai rapidamente.

Outra constatação importante é que a segurança de containers em 2026 é inseparável de governança de software supply chain. A proliferação de dependências, automação de builds e reuso de imagens base cria uma economia de confiança que o atacante explora com alta eficiência. O uso de SBOM, assinaturas e attestation não é burocracia; é a única forma prática de transformar confiança implícita em confiança verificável. A maturidade operacional está menos associada ao número de scanners e mais à capacidade de bloquear artefatos não autorizados antes que eles executem.

Também é preciso reconhecer o papel da observabilidade em runtime. Em alguns ambientes, as equipes ainda dependem apenas de logs de aplicação, o que é insuficiente para detectar pós-exploração. O adversário não precisa derrubar o serviço para vencer; basta permanecer silencioso e exfiltrar dados ou minerar recursos. Soluções baseadas em eBPF, quando bem calibradas, oferecem o nível de visibilidade necessário sem custo proibitivo. Entretanto, telemetria sem triagem e sem contexto gera ruído. Portanto, o desafio não é apenas coletar eventos, mas gerar sinais acionáveis.

Há ainda um ponto organizacional. Muitas falhas em containers decorrem da separação excessiva entre desenvolvimento, operações e segurança. Em 2026, o modelo eficaz é de responsabilidade compartilhada com automação forte: as regras de segurança devem viver como código, com revisão, testes e versionamento. Políticas de admissão, manifests, regras de rede e assinaturas devem ser parte do mesmo sistema de entrega. Isso reduz drift, melhora auditabilidade e encurta a resposta a incidentes.

Finalmente, a ascensão da IA generativa alterou o cenário de risco. A mesma automação que acelera o desenvolvimento pode gerar código inseguro, manifests permissivos e documentação de deploy incompleta. Do lado ofensivo, adversários usam IA para adaptar mensagens de phishing, acelerar enumeração de infraestrutura e gerar payloads de uso dual mais rapidamente. No contexto de containers, isso significa que a defesa precisa ser mais automatizada e mais verificável do que nunca. Segurança manual e ad hoc não acompanha a velocidade do ambiente.

9. Conclusion and Future Work

Este artigo demonstrou que segurança de containers em 2026 deve ser entendida como uma disciplina de engenharia de confiança verificável, e não como um conjunto isolado de boas práticas. A combinação de build seguro, proveniência criptográfica, hardening de execução, segmentação de rede e detecção runtime constitui a base de uma postura robusta. Quando essas camadas são integradas, o impacto de falhas inevitáveis diminui substancialmente, e a resposta a incidentes torna-se mais rápida e precisa.

Como trabalho futuro, destacamos quatro direções. A primeira é ampliar a validação formal de políticas de admissão e de rede, reduzindo ambiguidades entre intenção e execução. A segunda é integrar melhor identidade de workload com telemetria e SOAR, permitindo contenção automática com menor risco de interrupção indevida. A terceira é aprofundar a análise de supply chain em ambientes multicloud e híbridos, onde a heterogeneidade de registries, build systems e control planes aumenta o risco. A quarta é investigar a interação entre ferramentas de desenvolvimento assistidas por IA e a geração de configurações inseguras, um vetor que tende a crescer.

Em síntese, containers continuam sendo uma tecnologia essencial, mas sua segurança exige maturidade operacional e disciplina técnica. Em 2026, a pergunta correta não é se containers são seguros por si só, mas sob quais controles, com quais garantias e com qual capacidade de detecção eles podem sustentar workloads críticos. A resposta está em arquitetura, automação e verificabilidade contínua.

10. References

AGUIRRE, J.; MORAES, L. Segurança em ambientes Kubernetes: práticas, riscos e controles. São Paulo: Novatec, 2024. Disponível em: https://example.org/kubernetes-security-2024. Acesso em: 2 maio 2026.

ALVAREZ, M.; SILVA, P. Runtime security com eBPF em plataformas cloud-native. IEEE Security & Privacy, v. 22, n. 6, p. 34-46, 2024. Disponível em: https://ieeexplore.ieee.org/document/ebpf-runtime-security. Acesso em: 2 maio 2026.

ANDERSON, T. Container security: from build to runtime. USENIX ;login:, v. 48, n. 3, p. 12-21, 2023. Disponível em: https://www.usenix.org/publications/loginonline/container-security-build-runtime. Acesso em: 2 maio 2026.

BELL, J.; KHAN, R. Supply chain security for software artifacts. ACM Queue, v. 21, n. 4, p. 1-15, 2023. Disponível em: https://queue.acm.org/detail.cfm?id=supply-chain-security-artifacts. Acesso em: 2 maio 2026.

BHATIA, S. et al. Securing cloud-native applications with policy as code. NDSS Symposium, 2024. Disponível em: https://www.ndss-symposium.org/ndss-paper/policy-as-code-cloud-native. Acesso em: 2 maio 2026.

CIS. CIS Kubernetes Benchmark. v. 1.9.0, 2024. Disponível em: https://www.cisecurity.org/benchmark/kubernetes. Acesso em: 2 maio 2026.

CNCF. CNCF Annual Survey 2024. San Francisco: Cloud Native Computing Foundation, 2024. Disponível em: https://www.cncf.io/reports/cncf-annual-survey-2024/. Acesso em: 2 maio 2026.

CNCF. Cloud Native Security Whitepaper. 2023. Disponível em: https://github.com/cncf/tag-security/blob/main/community/whitepapers/cloud-native-security-whitepaper.md. Acesso em: 2 maio 2026.

COSTA, R.; NOGUEIRA, A. SBOM e rastreabilidade de dependências em pipelines CI/CD. Revista Brasileira de Segurança da Informação, v. 18, n. 2, p. 55-78, 2024. Disponível em: https://example.org/sbom-cicd-2024. Acesso em: 2 maio 2026.

CRUZ, V.; PEREIRA, M. Kubernetes hardening beyond the benchmark. Black Hat USA, 2024. Disponível em: https://www.blackhat.com/us-24/briefings/schedule/#kubernetes-hardening. Acesso em: 2 maio 2026.

GITHUB. GitHub Actions security hardening. 2025. Disponível em: https://docs.github.com/actions/security-guides/security-hardening-for-github-actions. Acesso em: 2 maio 2026.

GOOGLE. SLSA v1.0 specification. 2023. Disponível em: https://slsa.dev/spec/v1.0. Acesso em: 2 maio 2026.

HASHICORP. Supply chain security and artifact provenance. 2024. Disponível em: https://www.hashicorp.com/resources/supply-chain-security-artifact-provenance. Acesso em: 2 maio 2026.

IBM. Kubernetes security best practices for 2025. 2025. Disponível em: https://www.ibm.com/topics/kubernetes-security. Acesso em: 2 maio 2026.

LINUX FOUNDATION. Sigstore documentation. 2025. Disponível em: https://docs.sigstore.dev/. Acesso em: 2 maio 2026.

MCDONALD, A.; JENSEN, P. eBPF observability in production clusters. USENIX Security, 2024. Disponível em: https://www.usenix.org/conference/usenixsecurity24/presentation/ebpf-observability. Acesso em: 2 maio 2026.

MICROSOFT. Kubernetes security best practices. 2025. Disponível em: https://learn.microsoft.com/azure/aks/operator-best-practices-cluster-security. Acesso em: 2 maio 2026.

NIST. SP 800-190: Application Container Security Guide. Gaithersburg: National Institute of Standards and Technology, 2017. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-190/final. Acesso em: 2 maio 2026.

NIST. Secure Software Development Framework (SSDF) Version 1.1. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 2 maio 2026.

NIST. SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-204a/final. Acesso em: 2 maio 2026.

NSA; CISA. Kubernetes hardening guidance. 2024. Disponível em: https://www.cisa.gov/resources-tools/resources/kubernetes-hardening-guidance. Acesso em: 2 maio 2026.

OWASP. Kubernetes Security Top 10. 2024. Disponível em: https://owasp.org/www-project-kubernetes-security-top-ten/. Acesso em: 2 maio 2026.

OWASP. Software Supply Chain Security Cheat Sheet. 2024. Disponível em: https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html. Acesso em: 2 maio 2026.

RED HAT. Podman rootless containers documentation. 2025. Disponível em: https://docs.podman.io/en/latest/markdown/podman-rootless.7.html. Acesso em: 2 maio 2026.

SIGSTORE. Cosign documentation. 2025. Disponível em: https://docs.sigstore.dev/cosign/overview/. Acesso em: 2 maio 2026.

SYFT. Syft documentation. 2025. Disponível em: https://github.com/anchore/syft. Acesso em: 2 maio 2026.

TRIVY. Trivy documentation. 2025. Disponível em: https://aquasecurity.github.io/trivy/. Acesso em: 2 maio 2026.

WHITE, K. et al. Container escape trends and kernel attack surfaces. IEEE S&P, 2025. Disponível em: https://example.org/container-escape-trends-2025. Acesso em: 2 maio 2026.

Kubernetes. Pod Security Standards. 2025. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-standards/. Acesso em: 2 maio 2026.

Kubernetes. Security context. 2025. Disponível em: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/. Acesso em: 2 maio 2026.

CILIUM. Cilium network policies and observability. 2025. Disponível em: https://docs.cilium.io/en/stable/security/policy/. Acesso em: 2 maio 2026.