Saber o que compõe um container não é suficiente para confiar nele. Neste artigo, Heitor explora como SBOM, VEX, SLSA e atestados criptográficos trabalham juntos para transformar confiança implícita em confiança verificável, e como aplicar isso na prática com ferramentas como cosign e políticas de admissão no Kubernetes.
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.
Há mais de 13 anos operando Kubernetes em produção. Com o Quor, essa experiência alcança também a segurança da cadeia de software.
