Containers — imagens e cadeia de suprimentos

Imagens baseadas em camadas herdam privilégios: varredura de CVE, signing e runtime rootless reduzem a superfície que o container entrega ao host.

DockerFalcoTrivyCosign

O que é

Container é processo Linux isolado por namespaces e cgroups, executando um sistema de arquivos empilhado em camadas (layers). Cada camada é uma decisão: a base que você puxa, o apt install que roda, o usuário que abre o shell, o binário que entra. Cada uma vira parte da superfície que o atacante encontra.

Dois princípios resolvem 80% da defesa: imagens mínimas (menos coisa, menos bug) e runtime endurecido (menos privilégio, menos caminho). O resto é processo: varredura, signing, política.

Imagem base mínima

Imagem base é a fundação de tudo o que vier depois. ubuntu:latest ou python:latest trazem um shell, um gerenciador de pacotes, e um conjunto de CVEs que cresce toda semana. Para produção, escolha uma base que tenha só o que o binário precisa para rodar.

distroless (gcr.io/distroless/*): sem shell, sem apt, sem gerenciador de pacote. Para aplicações Go, Java, Node, Python estáticos
alpine: busybox + musl, ~5MB, ainda tem shell mas é muito menor que Debian
scratch: nada, só o binário. Válido para binários Go/C/Rust compilados estaticamente
wolfi/chainguard: distroless com cadeia de supply chain auditada e rebuild diário de CVEs

Registry confiável e signing

Saber de onde veio vale mais do que saber o que tem dentro. Registries privados (ECR, GCR, Harbor) dão controle sobre quem publica, com SSO e audit. Signing prova integridade: a imagem que está rodando é exatamente a que o CI construiu.

Cosign (do projeto Sigstore) assina e verifica imagens OCI. O par de chaves pode vir do próprio time, de um (chave fica em HSM), ou de Fulcio, que emite um certificado efêmero baseado em login OIDC (útil para CI sem segredo).

verificar imagem no deploybash

# assina no push
cosign sign --key cosign.key ghcr.io/loja/checkout@sha256:abc123

# verifica antes de subir (admission controller ou job de pré-deploy)
cosign verify \
  --key cosign.pub \
  --certificate-identity-regexp 'https://github.com/loja/checkout/.github/workflows/release.yml@refs/tags/.*' \
  ghcr.io/loja/checkout@sha256:abc123

Image scanning: achar CVE antes de subir

Scanners comparam a da imagem (ou cada layer) com bases de vulnerabilidades (, GHSA, OSV). A saída é a lista de pacotes e CVEs, com severidade e versão corrigida. Roda em três momentos: no build (bloqueia PR com crítico), no registry (acha CVE novo contra imagem já publicada) e no admission (rejeita pod com imagem não escaneada).

Trivy: scanner único (FS, image, , SBOM), roda offline, sem banco central
Grype (Anchore): foco em imagem e SBOM CycloneDX
Docker Scout: integrado ao Docker Hub, usa a SBOM que o Docker constrói nativamente
Snyk Container: comercial, bom para times que já usam Snyk para

Rodar como non-root e endurecer o runtime

Um container rodando como UID 0 dentro do host é um processo root no host. Se o atacante escapa do container, já está com privilégios administrativos no nó. Mesma coisa com sistemas de arquivo graváveis: anota ali onde o atacante vai tentar persistir. Endurecer o runtime é cortar caminhos antes que eles existam.

Dockerfile insegurodockerfile

FROM python:latest
RUN apt-get update && apt-get install -y curl netcat
COPY . /app
WORKDIR /app
EXPOSE 8080
CMD ["python", "app.py"]    # roda como root (UID 0)

Dockerfile corrigidodockerfile

# base mínima, sem shell, multi-stage para não herdar dev deps
FROM python:3.12-slim AS builder
WORKDIR /build
RUN pip install --no-cache-dir -r requirements.txt

FROM gcr.io/distroless/python3-debian12
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
COPY . /app
USER 65532                       # UID não-root fixo
EXPOSE 8080
ENTRYPOINT ["python", "/app/app.py"]

Onde entra

Containers tocam build, deploy e runtime. No build, o scan fecha o PR. No registry, o signing autentica a origem. No admission, o cluster rejeita imagem não assinada ou com policy violation. No runtime, o vigia o comportamento (próximo tópico). Pular qualquer um desses elos é abrir uma janela.

Pontos fortes

imutabilidade: a mesma imagem que foi testada é a que sobe, sem 'funciona na minha máquina'
imagens mínimas reduzem CVE em uma ordem de grandeza: distroless Python tem ~20 pacotes, Debian tem ~600
assinatura e SBOM dão rastreabilidade real, peça por peça, até o pacote instalado

Limitações

scan acha CVE conhecida: em dependência passa, e o signing não ajuda nisso
distroless e scratch dificultam debug (sem shell). É o trade-off entre segurança e ergonomia, não um bug
políticas de runtime (non-root, read-only fs) precisam ser aceitas pela aplicação: nem todo binário sobe sem root, e reescrever leva tempo

KMSkey management serviceServiço gerenciado que cria, armazena e controla o uso de chaves criptográficas. A aplicação raramente toca a chave mestra: ela pede ao KMS para criptografar ou descriptografar, e o provedor registra cada uso em log auditável. Sem KMS, a chave acaba em disco e vira alvo.ver no glossário →SBOMA lista de ingredientes do software: dependências, versões, licenças e hashes, em formato padrão.ver no glossário →NVDnational vulnerability databaseO banco do NIST que enriquece cada CVE com score CVSS e CWE associada. É de onde a maioria das ferramentas de SCA bebe.ver no glossário →CVEcommon vulnerabilities and exposuresO identificador único de UMA vulnerabilidade pública específica, no formato CVE-ANO-NÚMERO. Ex.: CVE-2021-44228 é o Log4Shell. É a instância real, não a classe do problema.ver no glossário →IaCinfrastructure as codeDescrever infraestrutura em arquivos versionados (Terraform, Ansible). Dá revisão, histórico e testes à configuração, mas replica erros em escala se não for escaneada.ver no glossário →SCAAnálise de composição: inventaria dependências de terceiros e cruza com CVEs conhecidas.ver no glossário →CWPPcloud workload protection platformProteção monitora para workloads em execução: VM, container, função serverless. Combina visibilidade do que roda (processos, syscalls, rede) com prevenção (bloquear execução, isolar anomalia). É o endpoint security reformulado para a realidade efêmera da cloud.ver no glossário →Zero-dayVulnerabilidade explorada antes de existir correção pública. Contra zero-day, só defesa em profundidade e detecção ajudam na hora.ver no glossário →

conexões no mapa

CWPP — proteção de workloadmonitora o runtimeContainers — imagens e cadeia de suprimentos
Network - segmentação e zero-trustisola a redeContainers — imagens e cadeia de suprimentos

atualizado em 14/10/2026 · fontes para aprofundar · reportar erro

em outros domínios

Contêineres e imagensdevopsa imagem boa e o cluster seguro: duas metades do mesmo problema
Fundamentos de Kubernetesdevopso mesmo cluster visto como plataforma e como superfície de ataque
SCAappsecalimenta: a imagem herda as dependências
SBOMappsecinventaria o que vai dentro da imagem