Security Researcher
Heitor Gouvêa
A segurança de containers amadureceu significativamente nos últimos anos. A introdução de SBOM consolidou a noção de que não é possível proteger aquilo que não se conhece estruturalmente. Inventário deixou de ser um artefato burocrático e passou a ser elemento central da engenharia moderna.
Entretanto, a composição não equivale a confiança. Um artefato pode ter sua lista de dependências perfeitamente documentada e ainda assim ter sido construído em um ambiente comprometido, fora de processo ou por uma identidade não autorizada.
O desafio atual da segurança de supply chain não é apenas saber o que compõe um container, mas demonstrar, com evidência verificável, que ele foi produzido de forma íntegra, rastreável e sob controles adequados. Confiança, nesse contexto, não pode ser implícita. Ela precisa ser criptograficamente demonstrável. É nesse ponto que entram os atestados, a noção de proveniência, o papel do VEX e os níveis de maturidade definidos pelo SLSA.
SBOM como ponto de partida, não como destino
O SBOM estabelece uma representação estruturada da composição de um artefato. Ele descreve bibliotecas, pacotes de sistema operacional, frameworks, relações de dependência, versões e licenças. Ao ser gerado durante o build e armazenado como artefato versionado, ele permite correlação posterior com bases de vulnerabilidade sem necessidade de reanalisar o binário.
Contudo, um SBOM isolado é apenas um documento declarativo. Nada impede que alguém gere um SBOM que não corresponda ao artefato distribuído. Nada impede que a imagem tenha sido modificada após a geração do inventário. Para que o SBOM participe de um modelo de confiança, ela precisa estar vinculada ao digest da imagem e assinado. Essa vinculação transforma a SBOM em um atestado de composição.
Suponha uma imagem publicada em um registry:
O primeiro passo é identificar seu digest imutável:
O resultado será algo como:
Esse digest é a âncora criptográfica sobre a qual as atestações serão construídas. Se o SBOM foi gerada em formato CycloneDX, por exemplo sbom.json, ele pode ser associada ao artefato usando cosign:
Esse comando cria uma atestação cujo subject é o digest da imagem e cujo predicate contém o SBOM. A atestação é assinada com a chave configurada no ambiente. A partir desse momento, o SBOM deixa de ser apenas inventário e passa a ser evidência vinculada criptograficamente ao artefato.
Atestados como modelo de evidência
Um atestado é uma declaração assinada sobre um artefato específico. Ela associa três elementos fundamentais:
o digest do artefato;
um tipo de declaração;
o conteúdo dessa declaração.
O padrão amplamente utilizado no ecossistema cloud native deriva do modelo in-toto, que define como representar esses vínculos de maneira estruturada e verificável. A vantagem desse modelo é a separação entre binário e metadados. Uma imagem pode ter múltiplas atestações independentes. Uma pode descrever sua composição, outra pode descrever sua proveniência, outra pode declarar nível SLSA alcançado e outra pode conter informação VEX. Essa modularidade permite evoluir a arquitetura de confiança sem modificar o artefato executável.
Newsletter Quor
Proveniência de build
A proveniência documenta como o artefato foi produzido. Ela responde a perguntas como qual repositório foi utilizado, qual commit foi compilado, qual pipeline executou o build e qual identidade estava associada ao processo.
Um exemplo simplificado de documento de proveniência poderia conter:
Esse arquivo pode ser salvo como provenance.json e associado à imagem com cosign:
Esse atestado permite verificar posteriormente se a imagem em produção foi construída por um pipeline autorizado e a partir do commit esperado. Em ambientes maduros, políticas de admissão em Kubernetes podem exigir a presença de um atestado de proveniência válido antes de permitir o deploy da imagem. A consequência prática é que builds manuais ou artefatos produzidos fora do processo formal deixam de ser aceitos automaticamente.
SLSA e maturidade do processo
SLSA (Supply-chain Levels for Software Artifacts) introduz níveis progressivos de garantia na cadeia de build. Ele não é apenas um documento, mas um modelo de maturidade. Um atestado SLSA declara evidências sobre isolamento do build, autenticidade do builder e controle do processo. Em termos práticos, uma organização pode estabelecer que somente artefatos que atinjam determinado nível SLSA podem ser promovidos para produção. Isso cria um vínculo entre engenharia de plataforma e segurança.
Para que o atestado SLSA não seja apenas um metadado passivo, o Kubernetes utiliza recursos como Validating Admission Policy (VAP): permite declarar regras nativas usando a linguagem CEL. Em termos práticos, o time de Ops pode definir uma política que rejeita qualquer imagem que não contenha um atestado de proveniência SLSA L3 verificado via signature no momento da admissão. Isso transforma a conformidade em um controle preventivo em tempo real, garantindo que o que foi definido no papel seja rigorosamente aplicado no cluster.
O pipeline deixa de ser apenas mecanismo de automação e passa a ser parte integrante do modelo de confiança. O atestado SLSA também pode ser anexado via cosign, utilizando um predicate compatível com o formato esperado.
VEX e a dimensão contextual da vulnerabilidade
Quando uma nova CVE é divulgada, a simples presença da biblioteca afetada na SBOM não determina necessariamente uma exposição real. Muitas dependências são transitivas e nem sempre o componente vulnerável é efetivamente carregado em runtime ou exposto externamente. O VEX formaliza essa análise contextual. Ele permite declarar que uma vulnerabilidade específica não é explorável naquele artefato, está mitigada por configuração ou não é aplicável ao contexto de uso.
Um exemplo simplificado de declaração VEX poderia indicar:
Esse documento pode ser associado à imagem como mais uma atestação:
Esse modelo permite que a equipe de AppSec diferencie vulnerabilidades sintáticas de vulnerabilidades efetivamente exploráveis. A gestão de risco deixa de ser binária e passa a refletir o contexto operacional.
Assinatura da imagem
Além das atestações, a própria imagem deve ser assinada. A assinatura garante que o digest corresponde exatamente ao conteúdo publicado e que a identidade responsável pelo processo é conhecida.
A assinatura direta da imagem pode ser feita com:
Ou, de forma explícita pelo digest:
A verificação posterior ocorre com:
Para verificar atestações associadas:
Esses comandos permitem que qualquer parte interessada valide a assinatura e as evidências associadas ao artefato sem depender de confiança implícita.
Integração operacional
Quando SBOM, VEX, proveniência e SLSA são combinados, a organização passa a operar sobre um modelo de evidência contínua. Ao surgir uma nova vulnerabilidade crítica, a equipe consulta a SBOM já vinculada às imagens. O VEX indica se há exposição real. O atestado de proveniência identifica o commit exato e o pipeline responsável. A assinatura confirma a integridade. Se necessário, é possível rastrear rapidamente quais artefatos precisam ser reconstruídos e redistribuídos. Esse encadeamento reduz o tempo de resposta a incidentes, elimina ambiguidade e fortalece a governança da cadeia de suprimentos.
Conclusão
A segurança de containers evoluiu além do scanning tradicional. Inventário é apenas a base. Confiança moderna exige proveniência verificável, contexto de vulnerabilidade formalizado, maturidade de processo e garantias criptográficas de integridade. SBOM responde o que compõe o artefato. VEX responde se a vulnerabilidade é relevante naquele contexto. Proveniência responde como ele foi produzido. SLSA qualifica a robustez do processo. A assinatura permite verificar tudo isso de maneira independente.
Quando essas camadas são integradas, containers deixam de ser artefatos cuja confiança é presumida e passam a ser entidades cuja confiança é demonstrável. Esse deslocamento representa uma mudança estrutural na forma como tratamos segurança de software. A confiança não é mais declarada. Ela é verificada.
Referências
Com o Quor, segurança vira vantagem competitiva. Descubra como em uma demo personalizada.