Verificando a Proveniência de Builds com SLSA e Sigstore

Visão Geral

A verificação de proveniência de builds responde a uma pergunta que derrota muitos ataques à cadeia de suprimentos: este artefato foi realmente construído a partir do código-fonte que eu penso que foi, pelo construtor em que confio, sem adulteração? Atacantes que comprometem um sistema de build, trocam uma versão compilada ou injetam uma etapa maliciosa (como nos incidentes SolarWinds e 3CX) produzem artefatos que parecem legítimos, mas carecem de proveniência verificável. SLSA (Supply-chain Levels for Software Artifacts, https://slsa.dev) define Níveis de Build (L1–L3) descrevendo integridade crescente de proveniência, e Sigstore (https://www.sigstore.dev) fornece a infraestrutura de assinatura e transparência: cosign para assinar/verificar artefatos e atestações, Fulcio para certificados sem chave de curta duração vinculados a uma identidade OIDC, e Rekor como um log de transparência à prova de adulteração.

Esta habilidade abrange a verificação de assinaturas e proveniência SLSA com cosign (cosign verify, cosign verify-attestation, cosign verify-blob-attestation) e slsa-verifier (slsa-verifier verify-artifact), aplicando a identidade do construtor (o fluxo de trabalho do GitHub Actions que produziu o artefato) e o repositório de origem esperado. A verificação sem chave vincula a confiança a um emissor OIDC (por exemplo, https://token.actions.githubusercontent.com) e a uma identidade de certificado em vez de uma chave privada de longa duração.

Isso se mapeia para o MITRE ATT&CK T1195 — Supply Chain Compromise (a verificação de proveniência detecta/bloqueia artefatos adulterados) e o NIST CSF PR.DS-01 (a confidencialidade, integridade e disponibilidade dos dados em repouso são protegidas; o CSF 2.0 absorveu o resultado de verificação de integridade PR.DS-06, agora aposentado, aqui).

Quando Usar

• Em CI/CD antes de implantar ou promover qualquer imagem de contêiner ou binário de release.
• Ao consumir artefatos de terceiros (imagens base, releases Go/npm) que publicam atestações.
• Ao estabelecer um pipeline SLSA Build L3 producer e aplicá-lo no lado do consumidor.
• Durante a resposta a incidentes para confirmar se a proveniência de um artefato implantado está intacta.
• Em controle de admissão (por exemplo, Kubernetes via policy-controller / Kyverno) para admitir apenas imagens verificadas.

Pré-requisitos

• cosign (Sigstore CLI):

  go install github.com/sigstore/cosign/v2/cmd/cosign@latest
  # or download a release binary from https://github.com/sigstore/cosign/releases
  

• slsa-verifier:

  go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@latest
  # or:
  curl -sSL https://github.com/slsa-framework/slsa-verifier/releases/latest/download/slsa-verifier-linux-amd64 \
    -o /usr/local/bin/slsa-verifier && chmod +x /usr/local/bin/slsa-verifier
  

• Acesso à rede ao Rekor (https://rekor.sigstore.dev) e Fulcio para verificação do log de transparência.
• O artefato mais seu pacote de proveniência/atestação (.sigstore, .intoto.jsonl, ou atestação OCI anexada).

Objetivos

• Verificar uma assinatura cosign sem chave em uma imagem de contêiner, fixando o emissor OIDC e a identidade do certificado.
• Verificar uma atestação de proveniência SLSA em uma imagem com cosign verify-attestation --type slsaprovenance.
• Verificar a proveniência de um binário de release com slsa-verifier verify-artifact, fixando o repositório de origem e a tag.
• Verificar atestações de artefatos do GitHub / pacotes de blob com cosign verify-blob-attestation.
• Controlar CI e controle de admissão com base em verificação bem-sucedida; entender SLSA Build L1–L3.

Mapeamento MITRE ATT&CK

Fluxo de Trabalho

Etapa 1: Verificar uma assinatura cosign sem chave em uma imagem

Fixe tanto o emissor OIDC quanto a identidade do certificado (o fluxo de trabalho exato que assinou). Um cosign verify simples sem fixação de identidade é sem sentido — qualquer um pode assinar.

cosign verify \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp "^https://github.com/myorg/myrepo/.github/workflows/.*@refs/tags/v.*" \
  ghcr.io/myorg/myrepo:v1.2.3

Uma saída diferente de zero ou um resultado vazio significa que a verificação falhou — não implante.

Etapa 2: Verificar a atestação de proveniência SLSA na imagem

…