Glossário da cadeia de software (Kubernetes, containers, SBOM, CVEs): Edição Quor
Reunimos em um único glossário os termos que mais aparecem nas conversas sobre segurança em Kubernetes.
Head of Product
Camila Bedretchuk
Introdução
Em tecnologia, é quase impossível fugir da conhecida “sopa de letrinhas”.
Quando o assunto é cadeia de software, surgem ainda mais termos, siglas e conceitos que aparecem nas discussões de segurança, gestão de risco, cloud e desenvolvimento de software.
Pensando nisso, montamos este glossário da security software supply chain versão QUOR: uma seleção dos termos mais utilizados no dia a dia ao falar de Kubernetes, imagens de contêiner, vulnerabilidades, proveniência, SBOM, registries e demais elementos desse universo.
O objetivo não é ser acadêmico, mas oferecer definições claras, e quando fizer sentido, conectadas à forma como o QUOR enxerga e endereça esses temas.
Em resumo, é uma referência rápida para apoiar reuniões ou para compartilhar com equipes e colegas sempre que surgir a pergunta: “o que isso quer dizer mesmo?”.
Índice
1. Fundamentos de Kubernetes e workloads
Kubernetes (cluster / multicluster)
Plataforma open source que orquestra contêineres, automatizando deploy, scaling e gerenciamento de workloads.
Um cluster Kubernetes é o conjunto de nós (máquinas) divididas em dois grupos principais, um para gerenciamento e outro para aplicações.
Multicluster é uma estratégia de operação em que mais de um cluster Kubernetes é administrado de forma coordenada, permitindo que aplicações sejam distribuídas entre eles de maneira transparente.
Workload
Aplicação ou serviço em execução no Kubernetes, descrito por objetos como Deployments, StatefulSets, Jobs etc.
É a unidade lógica de execução que consome recursos do cluster (CPU, memória, rede) para entregar uma capacidade de negócio. Quando falamos em “proteger o workload”, estamos falando de proteger essa aplicação em produção: imagem, configuração e runtime.
2. Imagens de contêiner e registries
Imagem de contêiner
Pacote imutável (no padrão OCI) que pode conter o filesystem, binários, bibliotecas e metadados necessários para a execução de um processo em contêiner.
É versionável (por tags ou digest) e portável entre registries, clusters e provedores de nuvem. Ao implantar um workload no Kubernetes, é essa imagem que será obtida do registry e executada como contêiner.
Leia mais: Nem Toda Herança É Boa: O Risco das Imagens de Containers
Baseline seguro de imagens
Conjunto padronizado, versionado e aprovado de imagens “oficiais” da organização.
Essas imagens servem como referência corporativa para novos serviços (por exemplo, imagens QUOR de linguagens e frameworks), reduzindo variação, risco e reincidência de CVEs, já que múltiplos workloads passam a compartilhar uma imagem base comum e segura.
Imagem hardenizada
Imagem de contêiner construída com foco em segurança, normalmente com as seguintes características:
Superfície mínima: ausência de shell, ferramentas de debug e runtimes desnecessários;
Conjunto reduzido de pacotes: apenas o estritamente necessário para a aplicação;
Correções de segurança aplicadas de forma recorrente;
Configurações alinhadas a boas práticas, como execução com usuário não-root e permissões mínimas.
O objetivo é reduzir a superfície de ataque e a probabilidade de vulnerabilidades exploráveis.
Pull de imagem
Operação de obtenção de uma imagem a partir de um registry, transferindo o manifesto e as camadas (layers) para o ambiente que executa o comando (máquina do desenvolvedor, nó do cluster, pipeline de automação ou outro registry em cenários de espelhamento).
O comando de pull referencia a imagem por tag ou digest.
Registry (público / privado)
Serviço responsável por armazenar e distribuir imagens de contêiner e outros artefatos OCI.
Registry público: mantido por terceiros e acessível via internet (por exemplo, Docker Hub, GHCR, ECR, Quay).
Registry privado: controlado pela organização (registry interno, Harbor, Artifact Registry etc.), com políticas próprias de acesso, auditoria e espelhamento.
Uma prática comum é definir um ou mais registries de confiança, ou seja, registries autorizados como fonte oficial de imagens para ambientes produtivos. Neles, a organização pode aplicar políticas como: “somente imagens provenientes do QUOR são aceitas no cluster”.
Em estratégias de segurança mais maduras, é comum restringir o uso de registries públicos diretamente em produção, privilegiando registries de confiança (controlados).
Runtime / shell na imagem
Componentes presentes na imagem, como bash, ferramentas de diagnóstico, interpretadores completos ou runtimes genéricos.
Em muitas bases tradicionais, esses componentes vêm embutidos por padrão. Quando não são necessários para a operação da aplicação, removê-los:
Reduz a superfície de ataque;
Diminui o tamanho da imagem;
Reduz a quantidade de pacotes sujeitos a vulnerabilidades (CVEs).
Tag latest
Rótulo mutável que, em geral, aponta para a versão mais recente publicada de uma imagem. É prático em ambientes de desenvolvimento, mas pouco adequado para produção, pois:
Não é determinístico (pode apontar para imagens diferentes ao longo do tempo);
Dificulta auditoria e rastreabilidade de incidentes;
Oculta a versão efetivamente utilizada.
Por isso, recomenda-se o uso de tags imutáveis (por exemplo, app:1.4.3) ou de digests (@sha256:...) em ambientes críticos.
3. Segurança da cadeia de software
Assinatura criptográfica de imagens
Processo de assinar digitalmente uma imagem (ou seu manifesto) para garantir:
Integridade: o conteúdo não foi alterado desde a assinatura;
Autoria: quem publicou aquela imagem (identidade ou sistema).
Ferramentas como Sigstore/Cosign permitem assinar e verificar imagens, integrando essa verificação em políticas de admissão e pipelines CI/CD.
Proveniência (software provenance)
Conjunto de informações verificáveis sobre como, onde, quando e com quais insumos um artefato de software foi construído.
Inclui, por exemplo:
Repositório de origem e commit de referência;
Pipeline e ambiente de build;
Dependências utilizadas;
Identidade de quem disparou ou aprovou o processo.
Proveniência é um pilar da segurança de cadeia de software: permite rastrear a confiabilidade de um artefato até a origem.
SLSA (Supply-chain Levels for Software Artifacts)
Framework de segurança para cadeia de software que define níveis de garantia para artefatos, com foco em proteger o processo de build, a proveniência e a integridade do software.
Estabelece requisitos progressivos (níveis SLSA) para reduzir risco de adulteração (tampering) em pipelines, fortalecer a rastreabilidade de origem e tornar os artefatos de software mais confiáveis ao longo de toda a cadeia.
SBOM (Software Bill of Materials) [és-bóm]
Inventário estruturado de todos os componentes de software (bibliotecas, frameworks, pacotes, versões, licenças) usados para construir uma aplicação ou imagem.
Funciona como um “rótulo de ingredientes” do software e é fundamental para:
Identificar rapidamente se um componente vulnerável está presente;
Avaliar impacto de novas CVEs;
Atender requisitos regulatórios e de auditoria;
Gerenciar riscos da cadeia de dependências.
Software supply chain security
Conjunto de práticas, controles e ferramentas voltados a proteger toda a cadeia de entrega de software, desde o código até o ambiente produtivo.
O foco é preservar integridade, confidencialidade e disponibilidade do software, evitando que vulnerabilidades ou código malicioso sejam introduzidos na cadeia e alcancem a produção.
Security by design
Princípio de projetar sistemas, aplicações e infraestrutura com segurança incorporada desde a concepção, não como um componente a ser adicionado posteriormente, mas como uma característica intrínseca do projeto.
No contexto de segurança da cadeia de software, envolve considerar ameaças, controles e requisitos de proteção já na definição de arquitetura, escolha de tecnologias, pipelines de build, imagens base e políticas de uso de dependências.
O uso de um catálogo de imagens base seguras, como o QUOR, é um exemplo de decisão alinhada ao princípio de security by design na software supply chain.
Shift-left (em segurança)
Prática de antecipar atividades de segurança para etapas mais iniciais do ciclo de desenvolvimento, em vez de concentrar a detecção apenas em produção.
Na segurança da cadeia de software, isso inclui validar dependências, imagens e configurações ainda nas fases de build e integração contínua (CI), reduzindo o custo e o tempo de correção de vulnerabilidades e apoiando abordagens de DevSecOps.
Leia mais: Shift-Left e Economia: Por Que Corrigir Antes É Mais Barato?
4. Vulnerabilidades e controles técnicos
CVE (Common Vulnerabilities and Exposures)
Identificador público padronizado para vulnerabilidades de software.
Cada CVE tem um ID único (ex.: CVE-2025-12345) e uma descrição que permite que a indústria fale “a mesma língua” sobre uma determinada falha. Bases de dados como NVD, entre outras, indexam CVEs e são utilizadas por scanners de vulnerabilidade.
Leia mais: O Desafio da Gestão de vulnerabilidades [CVEs]: Insights dos Clientes da Getup
Hardening por camadas
Abordagem incremental de fortalecimento de imagens e ambientes. Em vez de tentar “endurecer tudo de uma vez”, você aplica camadas sucessivas de proteção, por exemplo:
Escolher um baseline enxuto e mais seguro;
Remover pacotes e funcionalidades não utilizadas;
Ajustar configurações de runtime (usuário não-root, capabilities mínimas, filesystem read-only etc.);
Reforçar políticas de cluster (admission, network policies, quotas);
Monitorar continuamente vulnerabilidades e misconfigurations.
Cada camada reduz a superfície de ataque e aumenta a resiliência.
Pareto 80/20 (no contexto de CVEs)
Aplicação do princípio de Pareto à segurança de imagens: uma pequena fração de imagens (por exemplo, as bases mais populares) concentra a maior parte das vulnerabilidades, esforço e custo.
Ao tratar esse “núcleo 20%” com imagens QUOR hardenizadas, é possível capturar grande parte do benefício (redução significativa das CVEs) com foco em poucos artefatos.
Políticas de admissão (Admission Policies/Controllers)
Mecanismos do Kubernetes que interceptam requisições à API do cluster após autenticação/autorização, mas antes de o objeto ser persistido.
Servem como “porteiros” que podem:
Validar se o objeto segue as políticas (ex.: imagem precisa estar assinada e vir do QUOR);
Mutar o objeto (injetar configurações padrão, sidecars, labels etc.);
Ou bloquear o deploy se algo estiver fora do padrão.
São um ponto-chave para aplicar segurança de cadeia de software diretamente no cluster.
Reincidência de CVEs
Quando a mesma vulnerabilidade (mesmo ID CVE) reaparece em várias imagens e workloads.
Isso multiplica custo e risco porque:
Torna a triagem redundante (mesma análise repetida dezenas de vezes);
Espalha o impacto de uma única falha por todo o ambiente;
Aumenta o esforço de correção e coordenação entre times.
Atuar na imagem base (ex.: via QUOR) reduz drasticamente a reincidência, pois uma correção única beneficia diversos serviços.
Zero-day (vulnerabilidade zero-day)
Vulnerabilidade para a qual ainda não existe correção disponível ou que ainda não é conhecida pelo fornecedor do software, mas que já pode ser explorada por atacantes.
Zero CVE (no momento da implantação)
Estado em que, na hora do deploy, a imagem não possui vulnerabilidades conhecidas nas bases de referência consultadas pelo scanner (como NVD e afins).
Importante:
Não significa que a imagem está “para sempre sem falhas”;
Significa que, no momento da implantação, não há CVEs públicos conhecidos associados aos componentes daquela imagem.
Leia mais: Você sabe o que é um CVE? E o que ele pode fazer com a sua estratégia de produto?
5. Operação contínua e práticas de atualização
Builds diários (cadência de builds)
Rotina de gerar novas compilações e imagens em uma frequência fixa (por exemplo, diária), incorporando patches e atualizações de dependências com versionamento explícito.
Isso reduz a janela de exposição a vulnerabilidades recém-divulgadas e facilita automatizar o caminho: “nova CVE → correção aplicada na base → nova imagem → re-deploy”.
Compatibilidade regressiva (backward compatibility)
Propriedade de uma nova versão de software (ou imagem base) de manter o comportamento esperado pelas versões anteriores de aplicações que dependem dela.
No contexto do QUOR, significa que atualizar para uma imagem hardenizada mais recente não deve quebrar suas aplicações, desde que elas utilizem interfaces e contratos suportados. Isso aumenta a confiança para aplicar atualizações com mais frequência.
MTTR (Mean Time to Repair)
Tempo médio entre a identificação de uma vulnerabilidade e a eliminação do risco em produção (correção aplicada e versão corrigida implantada).
No contexto de cadeia de software, abrange as etapas de detecção, análise, priorização, implementação da correção e reimplantação.
O QUOR contribui para a redução do MTTR ao reduzir o volume e a reincidência de vulnerabilidades nas imagens base, o que simplifica a priorização e torna o processo de correção mais rápido.
Re-deploy
Nova implantação de um workload apontando para uma imagem atualizada (por tag de versão ou digest).
É o passo final da remediação: só depois do re-deploy bem-sucedido o risco associado àquela imagem vulnerável realmente diminui em produção.
6. Risco, impacto financeiro e compliance
Auditoria e conformidade regulatória
Capacidade de demonstrar, para auditores e reguladores (por exemplo, BACEN, LGPD, SOX, PCI DSS), que a organização:
Controla a origem e o ciclo de vida das imagens (proveniência, assinatura, baseline seguro);
Conhece os componentes utilizados (SBOM);
Monitora e trata vulnerabilidades em prazo compatível com a criticidade;
Mantém trilhas de evidência (logs, políticas, registros de deploy e correção).
O QUOR apoia essa governança ao padronizar imagens, expor proveniência/SBOM e facilitar a geração de evidências consistentes.
ARO (Annualized Rate of Occurrence)
Frequência anual esperada de um tipo de incidente (quantas vezes, em média, ocorre por ano).
Exemplos: 1 vez por ano → ARO = 1,0; 1 vez a cada 2 anos → ARO = 0,5.
SLE (Single Loss Expectancy)
Perda esperada em um único incidente daquele tipo, normalmente expressa em valor financeiro (custos diretos e indiretos).
ALE (Annualized Loss Expectancy)
Perda anual esperada associada a um tipo de incidente.
Fórmula: ALE = ARO × SLE.
SCF (Supply Chain Factor)
Fração do risco total (ALE) atribuída especificamente à cadeia de software.
Exemplo: SCF = 0,20 indica que 20% da perda anual esperada vêm de problemas de supply chain (imagens, dependências, builds, registries etc.).
7. Conceitos específicos do QUOR
Modelo reativo x QUOR (prevenção)
Modelo reativo
Abordagem em que as vulnerabilidades são tratadas após a detecção em produção, com grande volume de alertas, triagem recorrente e correções distribuídas em múltiplas aplicações e imagens.
Modelo QUOR (preventivo)
Abordagem em que o foco está em evitar que vulnerabilidades (CVEs) cheguem aos ambientes produtivos. Os workloads passam a ser construídos a partir de imagens base hardenizadas, com proveniência, SBOM e critério de Zero CVE no momento da implantação, o que reduz:
O volume de vulnerabilidades em produção;
A superfície de ataque (menor superfície, menor probabilidade de incidentes);
O custo operacional de análise e correção dos CVEs;
O esforço para comprovar aderência a requisitos regulatórios e de auditoria
QUOR
Catálogo de imagens de contêiner seguras operado pela Getup, voltado para empresas que utilizam Kubernetes e precisam reduzir a superfície de ataque sem aumentar a complexidade para seus times.
A arquitetura do QUOR é composta por dois componentes principais:
Catálogo (registry privado compatível com OCI)
Conjunto de imagens base hardenizadas, reconstruídas com frequência sempre que novas vulnerabilidades são detectadas. Cada imagem inclui, de forma padronizada:
Assinatura criptográfica (Cosign);
SBOM (CycloneDX ou SPDX);
Rastreabilidade de origem alinhada a boas práticas como SLSA.
O resultado são imagens Zero CVES, adequadas para ambientes críticos e regulados.
Console web (SaaS)
Interface para:
Navegar e filtrar o catálogo de imagens;
Consultar histórico de atualizações e metadados;
Gerenciar acessos e tokens;
Configurar integrações e notificações (por exemplo, alertar um time quando uma vulnerabilidade crítica for corrigida).
Conceitualmente, o QUOR atua como base segura da cadeia de software, padronizando o baseline de imagens e apoiando o atendimento a requisitos de segurança, governança e compliance.
Considerações finais
Este glossário nasce das conversas que temos com nossos clientes e times: dúvidas recorrentes, decisões de arquitetura e discussões sobre risco, governança e operação em Kubernetes.
Acreditamos que ele ajuda a criar uma linguagem comum sobre a cadeia de software e segurança e será continuamente enriquecido à medida que novas práticas, aprendizados e necessidades surgirem ao redor do QUOR.
With Quor, security becomes your competitive edge. See how in a personalized demo.