Supply Chain Security: Assinatura com Sigstore e SBOM Real em CI/CD

Quando o backdoor do XZ Utils (CVE-2024-3094) quase entrou em distribuicoes Linux estaveis em marco de 2024, ficou claro que assinar tag no GitHub nao e mais suficiente. A cadeia de suprimentos de software virou alvo prioritario porque um unico maintainer comprometido propaga codigo malicioso para milhoes de hosts em horas. Na Basilisk OffSec trabalhamos os dois lados: simulamos ataques contra pipelines de clientes e ajudamos times a fechar as portas que encontramos. Este post consolida o que aplicamos em CI/CD real usando Sigstore cosign, SLSA nivel 3 e SBOMs CycloneDX, com foco em pragmatismo, nao em compliance teatral.

O primeiro passo e abandonar a ideia de chave privada longa-data armazenada em secret manager. O cosign keyless usa OIDC do GitHub Actions, GitLab CI ou Buildkite para emitir um certificado efemero via Fulcio, valido por 10 minutos, e registra a assinatura no Rekor (log transparente append-only). Isso elimina a categoria inteira de vazamento de chave de assinatura, que foi o pivot do incidente CodeCov de 2021. Um workflow tipico tem tres jobs: build reproducivel, sign com cosign sign --yes e attest com predicado SLSA Provenance v1.0. Em projetos de cliente vimos reducao de 90% no tempo de rotacao de credenciais ao migrar de chaves PGP para keyless, e isso conversa diretamente com o que discutimos em AppSec Shift-Left: SAST, SCA e Secrets Scanning sem Travar o Time.

SBOM nao e XML que ninguem le. Geramos CycloneDX 1.6 com Syft no momento do build, incluindo hashes SHA-256 de cada componente, licenca SPDX e fornecedor. O arquivo vai junto da imagem OCI como artefato referenciado, nao perdido em um S3. Para validar, rodamos Grype no pull request e tambem em background contra o registry, porque CVE nova aparece depois do merge. Combinamos isso com policy-as-code via Kyverno ou Conftest, bloqueando deploy se a SBOM tiver dependencia com CVSS acima de 7.0 sem excecao documentada. Esse mesmo modelo de policy aparece quando discutimos Hardening de Linux Servidor: CIS Benchmark Aplicado sem Quebrar Producao em servidores de producao.

SLSA (Supply-chain Levels for Software Artifacts) virou framework de referencia depois que Google e OpenSSF padronizaram a v1.0 em 2023. Nivel 1 e so ter build script versionado. Nivel 2 exige builder hospedado com proveniencia assinada. Nivel 3, que e onde queremos chegar em projetos sensiveis, exige isolamento do build, proveniencia nao falsificavel e hermetic builds. Na pratica usamos GitHub Actions com o reusable workflow slsa-framework/slsa-github-generator, que produz attestation in-toto assinada pelo proprio runner via OIDC. Um atacante que comprometa um maintainer ainda precisa quebrar o builder do GitHub, o que aumenta o custo do ataque em ordens de magnitude. Para times que tambem cuidam de Dependency Confusion e Typosquatting: Defesa Pratica para Times Dev, SLSA fecha o lado do publisher.

Verificacao no consumidor e tao importante quanto assinatura no produtor. Em clusters Kubernetes usamos o admission controller policy-controller do Sigstore com ClusterImagePolicy exigindo que toda imagem em namespace producao tenha assinatura cosign valida, identidade OIDC do dominio basilisk.example e attestation SLSA do builder esperado. Configuramos fallback de soft-fail em staging para evitar quebrar deploy emergencial, e hard-fail em prod. Tambem rodamos cosign verify-blob nos artefatos de cli baixados em estacoes de analista, integrado ao fluxo descrito em OPSEC para Pesquisadores de Seguranca: Modelo de Ameaca Pessoal, porque time de OffSec baixa muita ferramenta de origem incerta e isso vira vetor obvio.

Onde a coisa quebra na pratica: builds nao-reproduciveis, timestamps embutidos em binarios Go, dependencias transitivas que mudam entre git pull e CI, e maintainers que recusam adotar 2FA. Pre-2.0 do XZ ja tinha sinais de takeover social do projeto que nenhuma assinatura captura. Por isso recomendamos combinar cosign+SLSA+SBOM com revisao periodica de maintainers criticos, scorecard do OpenSSF rodando semanalmente nas top 50 dependencias, e exercicios de red team que simulem comprometimento de maintainer, similar ao que fazemos em engajamentos descritos em Adversary Emulation com Caldera e MITRE ATT&CK em Lab Corporativo e Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue. Tecnologia sem processo de manutencao vira teatro caro.

Takeaway pratico: comece pequeno e mensuravel. Esta semana, adicione cosign sign keyless em um unico pipeline, gere SBOM CycloneDX com Syft e publique como artefato OCI ao lado da imagem. Proxima sprint, ative cosign verify obrigatorio em um namespace de staging. Em 30 dias voce tem base para exigir SLSA L2 de fornecedores e responder com evidencia quando um proximo XZ acontecer, porque ele vai acontecer. O custo de implementacao em um pipeline existente fica em torno de 2 a 4 horas de engenheiro; o custo de nao implementar e perguntar para clientes em call de domingo se voce assinou aquele container que esta minerando Monero em producao.