O Packer 1.16 chega com geração e verificação nativas de proveniência SLSA

A HashiCorp lançou o Packer v1.16.0 com suporte nativo para gerar, assinar e verificar atestações de proveniência no padrão SLSA para toda imagem que a ferramenta constrói. Na prática, o Packer passa a produzir um registro à prova de adulteração de como uma imagem de máquina foi feita, sem exigir ferramentas adicionais de supply chain acopladas ao pipeline.

O problema que isso resolve é conhecido por qualquer equipe que opera frota em nuvem: uma imagem de máquina sustenta todos os workloads que rodam sobre ela. Se uma imagem for adulterada, ou simplesmente não puder ser verificada, o problema se propaga silenciosamente para cada instância criada a partir dela. Antes desta versão, rastrear a origem de uma imagem significava garimpar logs de build antigos, e o Packer não tinha como apontar qual commit, pipeline ou identidade produziu um artefato específico.

O post-processor de proveniência

O núcleo da novidade é um novo post-processor de provenance. Ele gera in-toto statements com um predicado SLSA Provenance v1, um formato vendor-neutral que já conversa com as ferramentas de segurança de supply chain existentes. A atestação captura o commit Git, o repositório, a ref, o pipeline de CI que disparou o build e os timestamps de construção.

A amarração ao artefato varia conforme o tipo:

• Artefatos locais ficam vinculados ao seu digest SHA-256.
• Artefatos em nuvem sem arquivo local (uma AMI, por exemplo) são atrelados a um registro de identidade canônico contendo os IDs do builder e do artefato.

Para assinatura, o Packer oferece quatro modos, cobrindo diferentes necessidades de gestão de chaves:

Como o Packer mapeia os níveis SLSA

A saída do Packer se encaixa diretamente na escala de build levels do SLSA:

• L1 exige apenas o post-processor de provenance, com assinatura opcional.
• L2 é atingido rodando o Packer em uma plataforma de CI com assinatura keyless, usando a identidade OIDC do job de CI como signatário. O upload ao Rekor fornece o log transparente para auditoria. A HashiCorp disponibiliza um workflow de referência do GitHub Actions para esse cenário.
• L3-compatível separa completamente a geração de proveniência do job de build, usando um job de assinatura distinto baseado no slsa-framework/slsa-github-generator.

Um ponto importante que a HashiCorp faz questão de registrar: o workflow sozinho não garante conformidade L3 plena. A conformidade depende também de hardening de plataforma e controles de isolamento de build. O workflow demonstra essas práticas, mas não as garante, o que é um recado honesto para quem for prometer isso internamente numa auditoria.

Os workflows de referência para os padrões L2 e L3-compatível ficam no diretório examples/ci do repositório do Packer.

Nada de criptografia nova

Vale entender o que o Packer não está inventando. A abordagem reaproveita um método já consolidado na camada de containers: in-toto statements, predicados SLSA Provenance, assinatura keyless via Sigstore e logs de transparência no Rekor. Esses elementos existiam para imagens de container, via buildx do Docker↳Docker46 conteúdosE o Docker Swarm? Contextos e motivadores diáriosDevSecOps · ago 2024Automatizando o ambiente de desenvolvimento e testes com DockerDevSecOps · mai 2019MySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Ver tudo em DevSecOps → e as artifact attestations do GitHub, mas faltavam na camada de imagem de máquina. O Packer traz o mesmo processo rigoroso de assinatura e verificação para artefatos AMI, QCOW2 e VHD, sem introduzir criptografia própria.

A HashiCorp posiciona o recurso para três usos concretos: gating de deployment, correlação de CVEs com commits e instâncias em execução e como evidência de apoio (não prova) para auditorias SOC 2 ou FedRAMP.

Onde isso se diferencia das ferramentas nativas da AWS

Para quem já usa tooling nativo da AWS para governança de AMIs, a distinção é relevante, porque essas ferramentas resolvem problemas adjacentes, mas diferentes:

• AMI Watermarks rastreiam metadados de identidade e linhagem, mas não garantem proveniência criptográfica de build.
• Atestação baseada em NitroTPM prova que uma instância em execução bate com uma medição de referência no boot, mas não explica como ou onde a imagem foi originalmente construída.

São camadas complementares: garantias de build-level do SLSA e verificações de integridade em tempo de boot cobrem partes distintas do processo de deployment. Organizações mirando evidências para FedRAMP ou SOC 2 provavelmente vão precisar de ambas, não de uma ou outra.

Melhorias menores no HCL2

A release também traz ajustes no HCL2 que interessam a quem escreve templates:

• meta-argumento continue_on_error para provisioners não-fatais;
• suporte a optional() em defaults por atributo para variáveis do tipo objeto;
• novas funções de template rfc3339_parse() e unix_timestamp_parse() para lidar com timestamps.

O que muda para quem constrói pipeline no Brasil

A boa notícia para quem já tem Packer em produção: tudo é opt-in. Templates existentes continuam buildando sob a v1.16.0 sem nenhuma alteração. Quem quiser proveniência só precisa adicionar o post-processor de provenance ao bloco de build; quem for além, para os padrões L2 ou L3-compatível, precisa também plugar os workflows de referência do GitHub Actions.

O ganho prático é reduzir a barreira para adotar rastreabilidade de supply chain em infraestrutura, um assunto que no Brasil tende a ficar restrito a times com maturidade alta em DevSecOps. Com o processo empacotado na própria ferramenta de build, deixa de ser necessário montar um pipeline caseiro de assinatura e verificação. Para times que atendem contratos com exigência de conformidade, ou que simplesmente querem poder responder "qual commit gerou essa AMI que está rodando em produção?", a resposta agora vem assinada e verificável, não garimpada em logs.

O que fica em aberto é o esforço de hardening de plataforma que separa um pipeline L2 de um genuinamente L3: a ferramenta entrega o mecanismo, mas o rigor operacional continua sendo responsabilidade do time.

Fonte: InfoQ