O framework SLSA, mantido pela Open Source Security Foundation (OpenSSF), publicou a versão 1.2 de sua especificação em 24 de novembro de 2025 com a primeira trilha dedicada ao código-fonte: a Source Track. A mudança afeta dois públicos ao mesmo tempo — equipes que produzem software e precisam provar como cada revisão do código nasceu, e equipes que consomem dependências de terceiros e querem evidência verificável antes de aceitar um artefato em produção. A ação prioritária é mapear em que nível os repositórios da organização estão hoje e fechar as lacunas de controle de acesso e de histórico antes de declarar qualquer nível a clientes ou auditores.

O que muda no SLSA

A novidade central da versão é a introdução da Source Track: uma escada de níveis que cobre as ameaças ligadas à autoria, à revisão e à gestão do código-fonte — tudo o que acontece antes de qualquer build existir. Até a versão anterior, o SLSA se concentrava na construção: a trilha Build atesta que um artefato não foi adulterado entre a compilação e o consumo. A Source Track empurra a garantia para trás, até o momento em que o commit é criado, revisado e gravado no repositório.

Essa fronteira importa porque parte dos ataques recentes à cadeia de suprimentos começou ali: no repositório, com um mantenedor comprometido, uma credencial roubada ou um tag reposicionado — não no servidor de build. Um pipeline blindado não protege contra código malicioso que entra pela porta da frente do controle de versão.

O anúncio oficial do SLSA v1.2 destaca que a versão é retrocompatível com a 1.1 e que o desenvolvimento segue com as trilhas de ambiente de build e de dependências. Para quem já gera proveniência de build, nada quebra: a Source Track é uma camada nova de avaliação, não uma substituição.

Como a trilha funciona

A Source Track avalia o sistema de controle de código — a plataforma, hospedada ou não, que guarda o repositório e impõe políticas de autenticação, autorização e gestão de mudanças, como revisão obrigatória e checagens de status. A trilha define papéis explícitos: administrador, pessoa confiável, robô confiável e pessoa não confiável. Quem é confiável pode propor e aprovar mudanças; quem não é pode ler e comentar, mas nunca aprovar sozinho uma alteração que chega a um branch protegido.

Um detalhe operacional decisivo: o ingresso em um nível vale a partir daquela revisão em diante, e a organização não pode prometer retroativamente que revisões antigas seguiram o processo. Isso cria uma data de corte honesta — quem começa a adoção agora não pode vender histórico antigo como se tivesse os mesmos controles.

A página oficial da Source Track traz os requisitos completos de cada nível, os papéis aceitos e exemplos de controles adicionais que a organização pode adotar além do mínimo.

Níveis exigidos pela trilha

A trilha tem quatro níveis, do uso básico de controle de versão até a revisão por pares imposta pela plataforma. O resumo:

Nível Exigência O que entrega ao consumidor
Source L1 Usar um sistema de controle de versão Revisões discretas e identificáveis
Source L2 Preservar o histórico de mudanças e gerar proveniência de código Evidência de quando e quem mudou, resistente a adulteração
Source L3 Impor continuamente os controles técnicos da organização Verificação de que a revisão seguiu o processo declarado
Source L4 Exigir revisão por duas pessoas confiáveis Resistência a mudanças unilaterais e a ameaças internas

O nível de histórico e proveniência é o ponto de equilíbrio para a maioria das organizações: ele exige um histórico contínuo e imutável — sem buracos nem reescritas — e que a plataforma emita uma atestação de proveniência de código para cada nova revisão, registrando de forma contemporânea e resistente a adulteração quando a mudança foi feita, quem a fez e quais controles técnicos foram aplicados.

No topo, a trilha chega à revisão obrigatória de código com dupla aprovação: a plataforma exige que duas pessoas confiáveis revisem todas as alterações em branches protegidas. O objetivo é impedir que um único ator — inclusive alguém de dentro — introduza uma mudança maliciosa sem um segundo par de olhos.

Controles práticos por nível

Para transformar a especificação em configuração de repositório, o caminho mais curto é:

  • P1 — proteja branches por regra, não por hábito: proíba force push e exclusão nos branches de release; sem isso, não existe histórico confiável.
  • P1 — congele tags: a trilha exige controles que impeçam uma tag de release de ser movida para outra revisão; tag reposicionado é uma forma silenciosa de servir um binário diferente com o mesmo nome.
  • P1 — reduza administradores: quem administra pode reescrever histórico e mudar políticas globais; quanto menor o grupo, mais forte a alegação de continuidade.
  • P2 — imponha revisão e CODEOWNERS: aprovação obrigatória dos donos de código nas áreas sensíveis, com automações restritas a contextos explícitos.
  • P2 — gere evidência de cada merge: registre revisão, checagens e identidade dos autores em formato consultável para sustentar a proveniência de código.

O esforço no repositório se completa olhando o outro lado da cadeia: as dependências open source que você mesmo consome. O OpenSSF Scorecard ajuda a auditar a saúde de projetos externos antes de adotá-los.

Do lado de quem consome

Quem consome software não precisa aceitar autodeclaração. A especificação define a VSA (Verification Summary Attestation), um resumo assinado por um verificador que indica o nível confirmado de uma revisão — o exemplo oficial mostra uma VSA com o campo verifiedLevels igual a SLSA_SOURCE_LEVEL_3. A verificação cruza as atestações emitidas pela plataforma e o resumo do verificador: se o repositório promete um nível que a VSA não confirma, a promessa não vale nada.

No ecossistema GitHub, as artifact attestations já operam nesse modelo. Geradas com o Sigstore, elas criam alegações assinadas que ligam o artefato ao repositório, ao commit e ao workflow que o produziu; em repositórios públicos, a atestação também é gravada em um log de transparência público e imutável. Por si só, elas entregam o Build Level 2 do SLSA v1.0, e o uso de workflows reutilizáveis permite alcançar o Build Level 3. Do lado do consumidor, a verificação é um comando: gh attestation verify, seguido do repositório esperado.

A própria documentação do GitHub faz o aviso que qualquer política interna precisa repetir: atestação não é garantia de que o artefato é seguro. Ela liga o binário ao código e às instruções de build — decidir se esse código atende à política da sua organização continua sendo responsabilidade sua, apoiada em análise de conteúdo.

Para quem presta contas a regulador, a Source Track também serve como linguagem de contrato com fornecedores: em vez de aceitar “práticas seguras de desenvolvimento” genéricas, o comprador pode exigir nível declarado, data de ingresso e verificação consultável — o mesmo espírito de registro auditável que o DORA já cobra do setor financeiro.

Plano de adoção imediato

  • P1: inventariar os repositórios que sustentam produção e classificar o nível atual de cada um — há controle de versão, histórico protegido, revisão imposta?
  • P1: aplicar proteção de branch e congelamento de tags nos repositórios críticos ainda nesta sprint.
  • P1: reduzir o grupo de administradores e revisar automações com permissão de escrita.
  • P2: ativar artifact attestations nos pipelines de release e verificar a saída com gh attestation verify antes do deploy.
  • P2: padronizar a dupla revisão nos repositórios que alimentam artefatos assinados.
  • P2: documentar a data de ingresso por branch e publicar a política interna de níveis por criticidade.

Sinais de que o repositório ainda não sustenta nem o nível de histórico: force push permitido no branch principal, tags que já foram movidos, merges sem revisão registrada e administradores sem revisão periódica. Cada um desses pontos derruba a evidência que a trilha exige.

Fontes