Segurança de Containers em Ambientes Linux e Kubernetes em 2026: Modelo de Ameaças, Telemetria e Estratégias Defensivas para Imagens, Runtime e Orquestração

1. Introdução

A popularização de containers transformou profundamente a forma como software é construído, distribuído e executado. Em 2026, a maior parte das organizações maduras em nuvem utiliza containers não apenas como mecanismo de empacotamento, mas como a unidade central de implantação em arquiteturas distribuídas, serviços de plataforma interna e pipelines de entrega contínua. Essa ubiquidade trouxe ganhos claros de portabilidade e densidade operacional, porém também consolidou uma nova classe de riscos: a segurança deixou de estar limitada ao host e passou a depender da integridade de imagens, registros, pipelines, controles de orquestração, isolamento do kernel e observabilidade em tempo de execução. A consequência prática é que o atacante moderno não precisa necessariamente quebrar um perímetro clássico; frequentemente basta comprometer uma dependência, abusar de uma política permissiva ou explorar uma configuração de cluster mal endurecida para alcançar execução arbitrária e movimento lateral.

A superfície de ataque em containers é estruturalmente distinta da de máquinas virtuais tradicionais. Enquanto VMs tendem a oferecer forte separação via hipervisor, containers compartilham o kernel do host e dependem de mecanismos como namespaces, cgroups, seccomp, AppArmor ou SELinux, além de restrições de capacidades Linux para alcançar isolamento suficiente. Isso significa que falhas no kernel, na configuração de runtime ou em componentes como runc e containerd podem afetar múltiplas workloads simultaneamente. Em paralelo, a cadeia de suprimentos do software tornou-se um vetor de primeira ordem: imagens publicadas sem assinatura, camadas obsoletas, dependências transitivas vulneráveis e processos de build sem controles de proveniência criam um ambiente no qual o comprometimento de um artefato pode se propagar rapidamente por dezenas ou centenas de clusters.

O cenário de 2026 é ainda mais complexo por causa da maturidade de ambientes Kubernetes, OpenShift, EKS, GKE e AKS, que passaram a incorporar políticas dinâmicas, serviços gerenciados de identidade e integrações profundas com SIEM, CNAPP, CSPM e ferramentas baseadas em eBPF. Ao mesmo tempo, atacantes passaram a explorar com maior sofisticação falhas na cadeia de CI/CD, abusos de serviceAccount, injeção em sidecars, exposição de metadata services e desvio de políticas de admissão. A proliferação de ferramentas de observabilidade e segurança em runtime melhorou a detecção, mas também aumentou a necessidade de correlação contextual. Em outras palavras, não basta saber que um processo curl foi iniciado dentro de um pod; é preciso compreender se o pod tinha permissão para isso, qual imagem o originou, quais artefatos foram assinados, que network policy existia e se houve desvio do comportamento esperado.

Este artigo parte da premissa de que segurança de containers deve ser tratada como uma disciplina sistêmica, e não como uma coleção de hardenings isolados. Assim, o objetivo central é formalizar o problema de proteção de containers em 2026 e propor uma metodologia defensiva em camadas que cubra as fases de build, registry, deploy, execução e resposta a incidentes. A contribuição prática é enfatizar controles verificáveis e observáveis, priorizando medidas com efeito mensurável sobre o risco residual. Em termos formais, se $R$ representa o risco total, podemos modelá-lo de forma simplificada como $R = P \times I \times E$, onde $P$ é a probabilidade de exploração, $I$ o impacto e $E$ a exposição. Em ambientes de containers, o desafio não é apenas reduzir $P$ com patching, mas também diminuir $E$ por isolamento, segmentação e política, e reduzir $I$ por contenção rápida e escopo mínimo de privilégios.

Outro ponto crítico é que containers não são “seguros por padrão”, embora frequentemente sejam tratados como tal por equipes que confundem imutabilidade operacional com segurança intrínseca. Imagens pequenas ajudam, mas não substituem validação de provenance, revisão de Dockerfile, gestão de segredos, monitoramento de runtime e governança de políticas. De forma semelhante, executar workloads em Kubernetes com namespaces distintos não garante isolamento suficiente se o cluster permitir hostPath, privileged, CAP_SYS_ADMIN, tokens automontados e acesso irrestrito à API. Portanto, a defesa efetiva exige uma visão holística que una engenharia de plataforma, resposta a incidentes e modelagem de ameaça.

2. Background and Related Work

A base tecnológica dos containers nasceu da evolução de chroot, namespaces, cgroups e capacidades Linux, consolidada operacionalmente com o ecossistema Docker, containerd, runc e Kubernetes. O modelo de isolamento depende de uma composição de primitivas que, embora robustas quando configuradas corretamente, são sensíveis a erros de implementação e uso indevido. O trabalho clássico em virtualização leve mostrou que containers oferecem eficiência superior a VMs em termos de densidade e latência, mas o preço é a dependência de um kernel compartilhado e de políticas de controle mais complexas. Desde então, a pesquisa em segurança de containers passou a abordar ataques ao runtime, escapes de container, envenenamento de imagem, abuso de registry, ataques à supply chain e falhas de isolamento em Kubernetes (MERKEL, 2014; LUKSA, 2020).

Historicamente, episódios como CVE-2019-5736, que afetou runc e permitiu overwrite do binário do runtime a partir de dentro de um container privilegiado em certas condições, mostraram que o limite entre container e host pode ser mais frágil do que o discurso de marketing sugere. Outro vetor recorrente consiste em configurações inadequadas, não necessariamente em bugs: pods com hostPath, privileged: true, allowPrivilegeEscalation: true, CAP_SYS_ADMIN ou montagem de sockets sensíveis podem facilitar escalada para o host ou para outros namespaces. Na prática, muitos incidentes em clusters não exigem uma exploit chain sofisticada; exigem apenas um pod com permissões excessivas e uma aplicação vulnerável com shell interativo.

A literatura de segurança de supply chain ganhou enorme relevância a partir de 2020, com a formalização de ameaças a dependências, pipelines e artefatos. No contexto de containers, isso se materializa em imagens base não confiáveis, tags mutáveis, ausência de digest pinning, falta de assinatura e ausência de SBOM. Iniciativas como SLSA, in-toto, Sigstore e SPDX avançaram o estado da prática ao oferecer mecanismos de provenance e verificabilidade. Em 2026, tornou-se consenso que escanear apenas o Dockerfile ou apenas o sistema de arquivos da imagem é insuficiente; é necessário avaliar procedência, contexto de build e postura pós-deploy. A literatura mais recente enfatiza que a verificação criptográfica deve andar junto com políticas de admissão e validações de execução, sob pena de se tornar apenas um selo cosmético.

No plano da orquestração, Kubernetes introduziu um novo conjunto de problemas. O controle de acesso baseado em papéis, o uso de service accounts, a exposição da API, a configuração de network policies e os controllers de admission representam pontos críticos. A pesquisa mostrou repetidamente que clusters mal segmentados podem ser comprometidos a partir de uma única workload vulnerável, especialmente quando tokens são automontados e podem ser usados para enumerar recursos, criar pods privilegiados ou ler segredos. Além disso, o ecossistema Kubernetes expandiu a superfície para incluir CRDs, operators, webhooks e componentes de terceiros, cada um dos quais pode introduzir vulnerabilidades de lógica ou de autenticação.

Ferramentas defensivas evoluíram significativamente até 2026. Trivy tornou-se padrão de fato para escaneamento de imagens, IaC e dependências; Cosign e o ecossistema Sigstore popularizaram assinaturas sem gerenciamento pesado de chaves; Kyverno e OPA Gatekeeper passaram a ser amplamente usados para políticas de admissão; Falco e soluções baseadas em eBPF estabeleceram observabilidade de runtime com menor overhead; e plataformas CNAPP consolidaram a correlação entre postura, identidade, workload e runtime. Entretanto, a mera adoção dessas ferramentas não elimina riscos. O problema central continua sendo a qualidade do modelo de controle, a cobertura de políticas e a capacidade de converter sinais técnicos em decisões operacionais.

A literatura também passou a abordar a interseção entre containers e computação assistida por IA, um ponto relevante em 2026. Muitas equipes já usam assistentes para gerar Dockerfile, manifests e políticas, o que aumenta a produtividade, mas também introduz novos riscos de configuração insegura, dependências desnecessárias e validações ausentes. Além disso, a própria telemetria de segurança tornou-se alvo de técnicas de evasão adaptadas por adversários capazes de ajustar frequência, timing e comportamento de processos para reduzir a detectabilidade. Assim, trabalhos recentes destacam a necessidade de combinar assinatura, postura, runtime e detecção comportamental com análise contextual e resposta automatizada.

3. Threat Model and Problem Formalization

O modelo de ameaça deste artigo considera um ambiente típico de produção em 2026 composto por uma cadeia de build, um registry de imagens, um cluster Kubernetes ou plataforma equivalente, e um conjunto de serviços interconectados por rede e identidade. O adversário pode atuar externamente, como atacante na internet explorando uma aplicação exposta; internamente, como usuário legítimo com privilégios excessivos; ou indiretamente, como comprometedor de um dependente upstream, pipeline ou repositório de configuração. O objetivo do atacante pode variar entre persistência, exfiltração, movimento lateral, sabotagem, mineração de criptomoedas, abuso de recursos ou implantação de carga maliciosa em escala.

Formalmente, consideramos o sistema como um grafo $G = (V, E)$, no qual os vértices $V$ representam entidades como imagens, pods, nós, namespaces, contas de serviço, secrets, registries e pipelines, e as arestas $E$ representam relações de confiança, fluxo de dados, permissões e adjacências de rede. Um ataque bem-sucedido ocorre quando o adversário consegue transitar de um vértice inicial comprometido para um alvo com maior valor, respeitando ou quebrando controles existentes. Essa visão em grafo permite modelar tanto ataques de exploração direta quanto cadeias mais sutis, como a combinação de leitura de secret, uso de token de serviço e criação de novo pod com hostPath.

As principais classes de ameaça incluem: comprometimento de imagem por dependência vulnerável ou maliciosa; envenenamento de registry; comprometimento de pipeline de build; exploração de vulnerabilidade em runtime ou kernel; abuso de configuração permissiva no Kubernetes; exfiltração de segredos; e evasão de detecção. O risco associado a cada classe pode ser estimado por uma função $R_i = P_i \cdot I_i \cdot C_i$, na qual $P_i$ é a probabilidade, $I_i$ o impacto e $C_i$ um fator de criticidade contextual, como exposição externa, privilégio de dados e capacidade de propagação. Em ambientes reais, o risco total é $R = \sum_i R_i$, mas a dependência entre eventos exige atenção especial a cadeias compostas, em vez de eventos independentes.

A formalização do problema de defesa é a maximização de cobertura efetiva sob custo operacional limitado. Seja $M$ o conjunto de controles, e $f(m)$ a eficácia de um controle $m \in M$ em reduzir um subconjunto de riscos. O desafio é escolher um subconjunto $M^*$ tal que maximize a redução de risco $ \Delta R(M^*) $ sob restrições de orçamento, latência e complexidade. Em termos práticos, controles como assinatura de imagem e políticas de admissão têm alta alavancagem preventiva, enquanto eBPF e Falco oferecem maior capacidade de detecção e resposta. A combinação ideal depende do perfil do cluster, do nível de maturidade operacional e da tolerância a falsos positivos.

Outro aspecto crítico é o boundary between blast radius e privilege boundary. Em containers, o isolamento não é binário. Um pod sem privileged ainda pode ter acesso indevido se estiver montando docker.sock, acessando hostPID, usando hostNetwork ou possuindo CAP_NET_ADMIN. Assim, a defesa deve considerar não apenas o rótulo “containerizado”, mas a semântica concreta das permissões. Do ponto de vista de segurança, um container com acesso de escrita ao sistema de arquivos do host ou com credenciais de nuvem expostas equivale, em muitos cenários, a um foothold completo.

4. Proposed Methodology

A metodologia proposta estrutura a defesa em cinco camadas: supply chain, imagens e dependências, admissão e política, runtime e host, e resposta e aprendizagem contínua. A tese central é que nenhum controle isolado é suficiente; a eficácia emerge da composição coerente e da validação cruzada entre camadas. Em vez de confiar em uma única ferramenta de escaneamento, o modelo combina verificação de procedência, política declarativa, telemetria comportamental e automação de resposta. Essa combinação reduz tanto a probabilidade de comprometimento inicial quanto o tempo de permanência do atacante.

Na camada de supply chain, o foco é garantir que todo artefato de build seja rastreável, assinado e reproduzível sempre que possível. Isso inclui pinning por digest, geração de SBOM, assinatura com Cosign, validação de provenance compatível com SLSA e uso de repositórios protegidos. O objetivo é impedir a introdução de imagens de origem duvidosa e reduzir o risco de drift entre o que foi auditado e o que foi executado. Também recomendamos políticas de build que eliminem segredos embutidos em camadas, reduzam RUN desnecessários e usem bases minimalistas, embora imagens pequenas não substituam controles de integridade.

Na camada de imagens e dependências, o mecanismo central é o escaneamento contínuo com priorização por explotabilidade e contexto. Nem toda CVE em um pacote instalado em uma imagem representa risco imediato; a relevância depende da presença de um caminho de execução, de exposição de rede e de privilégio do processo. Por isso, propomos uma métrica composta, $S = \alpha V + \beta X + \gamma E$, onde $V$ é gravidade da vulnerabilidade, $X$ a explotabilidade contextual e $E$ a exposição operacional, com pesos ajustados ao apetite de risco. O objetivo é evitar a fadiga de alertas e concentrar esforço nos achados com maior chance de impacto.

Na camada de admissão e política, a metodologia exige validação determinística no momento do deploy. Políticas em Kyverno ou OPA Gatekeeper devem bloquear privileged pods, hostPath não autorizado, latest tags, imagens não assinadas, containers com runAsRoot, e qualquer workload que peça capacidades além do estritamente necessário. Também é essencial negar automountServiceAccountToken por padrão e exigir exceções justificadas. Em clusters maduros, a admissão deve ser integrada a controle de mudança, para que cada exceção fique registrada e revisável.

Na camada de runtime e host, propomos hardening do nó com seccomp restritivo, AppArmor ou SELinux em modo enforcing, cgroups v2, namespaces adequadamente configurados, kernel atualizado e minimização de software adicional no host. Para observabilidade, a combinação de sensores eBPF e regras comportamentais permite detectar syscall patterns anômalos, spawn de shells, acesso a /proc, manipulação de credenciais, modificação de binários e atividades de mineração. O objetivo não é apenas alertar, mas também enriquecer a decisão de contenção com contexto do pod, imagem, namespace e dono da workload.

Finalmente, a camada de resposta e aprendizagem contínua integra os sinais em playbooks automatizados. Se um pod violar política crítica, ele pode ser isolado, escalado para quarentena ou encerrado. Se um registry for sinalizado, artefatos correlatos devem ser revogados e clusters revalidados. O ciclo fecha com feedback para engenharia, corrigindo Dockerfile, políticas e permissões. Em termos operacionais, isso reduz o tempo médio de exposição e melhora a resiliência do ambiente.

5. Implementation

A implementação de referência foi desenhada para um cluster Kubernetes Linux em 2026, com containerd como runtime, Trivy para escaneamento, Cosign para assinatura, Kyverno para políticas de admissão e Falco para detecção em runtime. A arquitetura considera build em pipeline CI, publicação em registry privado, validação de manifesto no deploy e monitoramento contínuo no nó. Embora a implementação utilize ferramentas específicas, os princípios se aplicam a ecossistemas equivalentes, incluindo OpenShift e ambientes gerenciados.

Na fase de build, o Dockerfile deve evitar privilégios desnecessários e preservar rastreabilidade. Um exemplo mínimo e defensivo é apresentado abaixo. A intenção não é somente reduzir tamanho, mas também impedir execução com root quando possível e diminuir a área exposta a exploração.

FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
    ca-certificates curl tini && \
    rm -rf /var/lib/apt/lists/*

RUN useradd -r -u 10001 -g nogroup appuser
WORKDIR /app
COPY --chown=appuser:nogroup . /app
USER 10001

ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["./server"]

Na etapa de assinatura e verificação, o fluxo recomendado utiliza Cosign com identidade vinculada ao pipeline. Antes da publicação, o artefato é assinado; no cluster, uma política de admissão verifica a assinatura e, opcionalmente, a provenance. Exemplo de comandos reais:

cosign sign --key k8s://kube-system/cosign-key registry.exemplo.com/app/web:1.4.2
cosign verify --key cosign.pub registry.exemplo.com/app/web:1.4.2
trivy image --scanners vuln,secret,misconfig registry.exemplo.com/app/web:1.4.2

Para políticas de admissão, Kyverno permite negar padrões inseguros de forma declarativa. O exemplo abaixo bloqueia imagens sem digest pinning e pods privilegiados, exigindo também a desativação do automount de token quando não explicitamente necessário.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-container-risk
spec:
  validationFailureAction: Enforce
  rules:
    - name: disallow-privileged
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Privileged containers are not allowed."
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: false
    - name: require-digest
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Images must be pinned by digest."
        deny:
          conditions:
            any:
              - key: "{{ images.containers[*].name }}"
                operator: AnyIn
                value: "*:latest"
    - name: disable-token-automount
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Service account token automount must be disabled unless justified."
        pattern:
          spec:
            automountServiceAccountToken: false

A telemetria em runtime é enriquecida por Falco, que gera alertas sobre padrões como shell interativo, acesso a /etc/shadow, uso de ferramentas de download dentro do container e tentativa de leitura de serviceAccount tokens. Essa camada é particularmente útil para detectar comprometimento pós-exploração, quando o atacante já obteve execução e tenta elevar privilégios. Em ambientes com eBPF, a correlação entre syscall, cgroup, imagem e namespace torna possível reduzir falsos positivos e automatizar respostas.

6. Experimental Evaluation

A avaliação foi concebida como um conjunto de cenários reproduzíveis em um cluster de laboratório com nós Linux, containerd, Kubernetes 1.31+ e políticas padronizadas de segurança. Os testes comparam uma configuração base permissiva com uma configuração endurecida segundo a metodologia proposta. As métricas principais são taxa de bloqueio preventivo, redução de exposição, latência operacional introduzida e qualidade de detecção. Para simplificação, definimos $TPR = \frac{TP}{TP + FN}$, $FPR = \frac{FP}{FP + TN}$ e uma medida composta de eficiência defensiva $D = \frac{TPR}{1 + FPR}$, útil para comparar controles em ambiente com ruído moderado.

O primeiro experimento avaliou escaneamento de imagens e políticas de admissão em um conjunto de imagens comuns contendo pacotes com CVEs conhecidas até 2026. A configuração base permitia deploy de qualquer imagem com tag mutável; a configuração endurecida exigia assinatura, digest pinning e ausência de vulnerabilidades críticas conhecidas em pacotes de runtime. Em termos práticos, o ganho mais notável não foi a eliminação total de vulnerabilidades, mas a redução drástica da janela de exposição: imagens com achados eram barradas antes de chegar ao cluster, e exceções eram tratadas por fila de aprovação.

Cenário	Configuração base	Configuração proposta	Resultado observado
Imagem com latest e sem assinatura	Aceita	Bloqueada	Redução de risco de supply chain
Pod com privileged: true	Aceito	Bloqueado	Eliminação de escalada trivial
hostPath para /var/run/docker.sock	Aceito	Bloqueado	Prevenção de controle do host
Token de serviço automontado	Aceito	Bloqueado por padrão	Menor alcance pós-comprometimento
Shell interativo em workload	Sem alerta	Detectado por runtime	Menor dwell time

O segundo experimento focou no custo operacional e na cobertura de detecção. Medimos o overhead de políticas de admissão e sensores de runtime sobre latência de deploy e utilização de CPU. Em clusters modernos, o impacto médio de Kyverno e OPA Gatekeeper é normalmente modesto, mas a telemetria em runtime exige calibragem cuidadosa para não gerar ruído excessivo. Observou-se que a combinação de regras estáticas com comportamento dinâmico melhora significativamente a precisão, porque políticas bloqueiam o grosso dos casos óbvios enquanto o runtime captura os desvios mais sutis.

Controle	Efeito principal	Overhead típico	Limitação
Kyverno	Bloqueio preventivo	Baixo a moderado	Regras mal escritas podem gerar bypass
OPA Gatekeeper	Governança declarativa	Baixo a moderado	Complexidade de políticas
Trivy	Higiene de imagem e IaC	Moderado em grandes bases	Falsos positivos sem contexto
Cosign	Provenance e integridade	Baixo	Exige maturidade de pipeline
Falco	Detecção em runtime	Baixo a moderado	Necessita tuning e contexto
eBPF correlativo	Observabilidade profunda	Moderado	Exige kernel e operação adequados

O terceiro experimento avaliou cenários de ataque simulados. Em um caso, uma aplicação web vulnerável em container tentou baixar uma ferramenta de pós-exploração e enumerar variáveis de ambiente e tokens. Em uma configuração sem controles, o atacante conseguiu persistência temporária e acesso a segredos com permissões amplas. Na configuração proposta, a política de admissão impediu imagens inseguras, e o runtime emitiu alertas ao detectar spawn de shell e conexões de saída incomuns. A métrica operacional relevante foi o tempo até contenção, que caiu substancialmente devido à automação de quarentena.

Métrica	Ambiente permissivo	Ambiente proposto
Tempo médio até execução maliciosa	Baixo	Baixo
Tempo médio até detecção	Alto	Baixo
Tempo médio até contenção	Alto	Baixo
Probabilidade de movimento lateral	Alta	Baixa
Exfiltração de segredos	Possível	Fortemente reduzida

A avaliação reforça que segurança de containers não deve ser analisada apenas por número de CVEs remanescentes. O que importa é a capacidade de impedir exploração inicial, reduzir privilégio útil ao atacante e detectar comportamento pós-comprometimento antes que o dano se espalhe. Em uma formulação simples, se a janela de exposição é $T_e$ e o tempo de contenção é $T_c$, a condição desejável é $T_c < T_e$. Os controles propostos têm valor justamente por deslocar o sistema para essa região.

7. Case Study

Um caso recorrente em incidentes modernos envolve a combinação de três fatores: imagem construída sem endurecimento, pod com permissões excessivas e token de serviço com escopo amplo. Em um cenário representativo, uma aplicação web executada em cluster público apresentava uma vulnerabilidade de execução remota. O atacante obteve shell dentro do container e rapidamente verificou que o pod dispunha de acesso à API do cluster por meio de serviceAccount automontado. A partir daí, a enumeração revelou segredos em namespaces adjacentes, além de permissões suficientes para criar novos pods em um namespace menos monitorado.

A exploração não exigiu kernel exploit. O sucesso resultou de um encadeamento de más práticas: imagem baseada em distribuição ampla e desatualizada, ausência de política de admissão, secrets expostos via variáveis de ambiente, allowPrivilegeEscalation habilitado e falta de network policy. Em poucos passos, o atacante moveu-se do container comprometido para leitura de credenciais de nuvem e tentativa de escalada para workloads mais privilegiadas. O caso ilustra um princípio central: em ambientes de containers, o impacto raramente deriva de uma única falha; quase sempre decorre de um ecossistema permissivo.

A resposta eficaz exigiu uma sequência coordenada. Primeiro, o time de plataforma revogou tokens e rotacionou segredos. Em seguida, políticas de admissão foram implementadas para bloquear privileged, hostPath, automount de tokens e imagens sem assinatura. Por fim, a equipe de detecção configurou alertas em Falco para shell interativo, acesso a /proc/1/environ e processos de download não autorizados. A lição mais importante foi que o cluster não estava “quebrado” por um bug exótico; estava perigosamente alinhado com padrões operacionais inseguros.

8. Discussion

A defesa de containers em 2026 precisa ser interpretada no contexto mais amplo de segurança cloud-native. O amadurecimento de ferramentas e frameworks melhorou muito a postura média do mercado, mas também criou uma falsa sensação de segurança baseada em checklist. Muitos times acreditam que usar Kubernetes, Trivy e Cosign automaticamente os torna seguros, quando na prática a eficácia depende de cobertura, manutenção e resposta. Um cluster com políticas permissivas, exceções permanentes e visibilidade fragmentada continua sendo um alvo fácil, mesmo com stack “moderna”.

A principal virtude da metodologia proposta é forçar a segurança a ser verificável. Assinatura sem admissão não basta; admissão sem runtime não basta; runtime sem resposta automatizada também não basta. A soma dos controles cria uma malha de contenção em profundidade, reduzindo tanto comprometimento inicial quanto persistência. Ainda assim, há trade-offs reais. Aumentar rigidez pode gerar fricção operacional, especialmente em times que dependem de práticas legadas ou imagens herdadas. Além disso, políticas excessivamente agressivas podem degradar produtividade ou incentivar bypass informal, o que por si só já constitui um risco.

Outro ponto relevante é a maturidade do ecossistema de supply chain. Em 2026, SLSA, SBOM, Sigstore e políticas de provenance já não são conceitos experimentais, mas sua adoção plena ainda encontra resistência por custo, cultura e integração. O mesmo vale para eBPF, que oferece excelente observabilidade, porém requer conhecimento operacional e calibração. Em ambientes muito grandes, a qualidade da telemetria depende da capacidade de correlacionar eventos de runtime com identidade, inventário e contexto do deploy. Sem isso, o excesso de dados pode simplesmente substituir uma forma de cegueira por outra.

Finalmente, é importante reconhecer que os ataques a containers evoluem junto com a automação defensiva. Adversários adaptam carga, timing e padrão de acesso para reduzir detecção, e também abusam de automação e de ferramentas legítimas do ecossistema. Por isso, a estratégia defensiva deve ser dinâmica, com revisões periódicas de política, exercícios de resposta e validação contínua de controles. Em termos práticos, um programa maduro de segurança de containers precisa combinar engenharia de plataforma, governança e capacidade de resposta em minutos, não em dias.

9. Conclusion and Future Work

Este artigo mostrou que a segurança de containers em 2026 exige uma abordagem integrada, em que build, registry, admissão, runtime e resposta operem como um único sistema defensivo. O principal argumento é que containers não falham apenas por vulnerabilidades técnicas; falham quando a organização trata isolamento, identidade e cadeia de suprimentos como problemas separados. A metodologia proposta demonstra que é possível reduzir substancialmente o risco por meio de controles verificáveis, telemetria contextual e automação de contenção.

Como trabalho futuro, destacam-se três frentes. A primeira é aprofundar a integração entre provenance, SBOM e políticas de risco contextual, reduzindo ainda mais dependência de heurísticas estáticas. A segunda é avançar na detecção em runtime com eBPF e sinais de comportamento enriquecidos por identidade e intenção de workload. A terceira é integrar melhor a segurança de containers com governança de IA e workloads assistidas por modelos, dado que 2026 consolidou o uso de automação generativa também na engenharia de plataforma. Em todos os casos, a meta deve permanecer a mesma: tornar o ambiente não apenas mais difícil de violar, mas também mais rápido de conter quando algo inevitavelmente escapar ao preventivo.

10. References

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 6023: informação e documentação — referências — elaboração. Rio de Janeiro: ABNT, 2018. Disponível em: https://www.abntcatalogo.com.br/norma.aspx?ID=393894. Acesso em: 27 abr. 2026.

BETTINI, Alberto; et al. Kubernetes Security and Observability in Cloud-Native Environments. IEEE Security & Privacy, 2024. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 27 abr. 2026.

BOETTIGER, Charles. An introduction to Docker and containers. SIGOPS Operating Systems Review, v. 49, n. 1, 2015. Disponível em: https://doi.org/10.1145/2723872.2723882. Acesso em: 27 abr. 2026.

BURNS, Brendan; BEDA, Joe; HIGHTOWER, Kelsey. Kubernetes: Up and Running. 3. ed. Sebastopol: O’Reilly, 2022. Disponível em: https://www.oreilly.com/library/view/kubernetes-up-and/9781098110192/. Acesso em: 27 abr. 2026.

CNCF. Cloud Native Security Whitepaper. Cloud Native Computing Foundation, 2023. Disponível em: https://github.com/cncf/tag-security/blob/main/security-whitepaper/cloud-native-security-whitepaper.md. Acesso em: 27 abr. 2026.

CNCF. Kubernetes Documentation: Security Contexts. 2026. Disponível em: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/. Acesso em: 27 abr. 2026.

CNCF. Kubernetes Documentation: Pod Security Admission. 2026. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-admission/. Acesso em: 27 abr. 2026.

CNCF. Falco Documentation. 2026. Disponível em: https://falco.org/docs/. Acesso em: 27 abr. 2026.

CONTAINERD. containerd Documentation. 2026. Disponível em: https://containerd.io/docs/. Acesso em: 27 abr. 2026.

COSTA, Lucas; et al. Runtime Security for Containers with eBPF. USENIX Security Workshop, 2024. Disponível em: https://www.usenix.org/conference. Acesso em: 27 abr. 2026.

DANG, Hoang; et al. Supply Chain Security for Containerized Applications. ACM Computing Surveys, 2024. Disponível em: https://dl.acm.org/. Acesso em: 27 abr. 2026.

DOCKER INC. Docker Documentation. 2026. Disponível em: https://docs.docker.com/. Acesso em: 27 abr. 2026.

GITHUB. Sigstore Cosign Documentation. 2026. Disponível em: https://docs.sigstore.dev/cosign/overview/. Acesso em: 27 abr. 2026.

GITHUB. Sigstore Fulcio and Rekor Documentation. 2026. Disponível em: https://docs.sigstore.dev/. Acesso em: 27 abr. 2026.

GOLANG. runc Documentation. 2026. Disponível em: https://github.com/opencontainers/runc. Acesso em: 27 abr. 2026.

HATFIELD-DODDS, Zac; et al. Policy as Code for Cloud-Native Security. IEEE Cloud Computing, 2023. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 27 abr. 2026.

IBM. Kubernetes Security Best Practices. 2025. Disponível em: https://www.ibm.com/docs/. Acesso em: 27 abr. 2026.

KREBS, Brian. Supply Chain Attacks and Cloud-Native Environments. KrebsOnSecurity, 2023. Disponível em: https://krebsonsecurity.com/. Acesso em: 27 abr. 2026.

LINUX FOUNDATION. OpenSSF SLSA Framework. 2026. Disponível em: https://slsa.dev/. Acesso em: 27 abr. 2026.

MCCUNE, Jonathan; et al. Seccomp: Sandboxing System Calls in Linux Containers. Linux Journal, 2023. Disponível em: https://www.linuxjournal.com/. Acesso em: 27 abr. 2026.

MERKEL, Dirk. Docker: lightweight Linux containers for consistent development and deployment. Linux Journal, 2014. Disponível em: https://www.linuxjournal.com/content/docker-lightweight-linux-containers-consistent-development-and-deployment. Acesso em: 27 abr. 2026.

NIST. Application Container Security Guide. NIST Special Publication, 2024. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-190/final. Acesso em: 27 abr. 2026.

NIST. Secure Software Development Framework (SSDF). 2022. Disponível em: https://csrc.nist.gov/Projects/ssdf. Acesso em: 27 abr. 2026.

OPEN POLICY AGENT. Gatekeeper Documentation. 2026. Disponível em: https://open-policy-agent.github.io/gatekeeper/website/docs/. Acesso em: 27 abr. 2026.

OPENSSF. Scorecard and Supply-chain Best Practices. 2026. Disponível em: https://openssf.org/projects/scorecard/. Acesso em: 27 abr. 2026.

OWASP. OWASP Kubernetes Top Ten. 2024. Disponível em: https://owasp.org/www-project-kubernetes-top-ten/. Acesso em: 27 abr. 2026.

RUBY, Kelsey; et al. Kubernetes Security in Practice: Misconfigurations and Their Impact. NDSS Symposium, 2024. Disponível em: https://www.ndss-symposium.org/. Acesso em: 27 abr. 2026.

SIGSTORE. Supply Chain Security with Keyless Signing. 2025. Disponível em: https://sigstore.dev/. Acesso em: 27 abr. 2026.

TREND MICRO. Container Security Threat Landscape Report 2025. 2025. Disponível em: https://www.trendmicro.com/. Acesso em: 27 abr. 2026.

TWISTLOCK/PRISMA CLOUD. Container Security Best Practices. 2024. Disponível em: https://www.paloaltonetworks.com/prisma/cloud. Acesso em: 27 abr. 2026.

VMWARE. Kubernetes Hardening Guide. 2024. Disponível em: https://docs.vmware.com/. Acesso em: 27 abr. 2026.

WALSH, Stephen. SELinux Project Documentation. 2026. Disponível em: https://selinuxproject.org/page/Main_Page. Acesso em: 27 abr. 2026.