SLSA: o que é, por que importa e como começar pelo nível 1

A segurança da cadeia de suprimentos de software deixou de ser um tema exclusivo de grandes empresas para se tornar uma preocupação estrutural de qualquer organização que produz ou consome software. Incidentes como SolarWinds, Codecov e comprometimentos em pacotes npm demonstraram que o risco não está apenas no código da aplicação, mas em todo o processo que transforma código em artefato executável.

SLSA (Supply-chain Levels for Software Artifacts, pronunciado "salsa") é um framework de segurança criado pelo Google e hoje mantido pela OpenSSF (Open Source Security Foundation) que endereça exatamente essa lacuna. Em vez de tratar segurança como uma inspeção pontual do binário final, SLSA estabelece critérios verificáveis para o processo de build, organizados em níveis progressivos de maturidade.

Este artigo foca no nível 1, o ponto de entrada do framework e o passo mais acessível para organizações que querem começar a tratar proveniência de artefatos com seriedade.

O problema

Quando uma equipe faz deploy de uma imagem de container ou publica um pacote, há uma cadeia de etapas entre o commit no repositório e o artefato em produção: checkout do código, resolução de dependências, compilação, empacotamento, publicação. Cada etapa é um ponto onde a adulteração pode ocorrer.

A pergunta fundamental que SLSA endereça é: como demonstrar que um artefato foi construído a partir do código esperado, pelo processo esperado, na infraestrutura esperada?

Sem um modelo formal para responder essa pergunta, a confiança no artefato é implícita. A organização confia que o pipeline não foi alterado, que ninguém fez um build manual fora do processo, que as dependências resolvidas são as mesmas que estavam no lock file. Essa confiança implícita é exatamente o que ataques de supply chain exploram.

SLSA transforma essa confiança implícita em confiança verificável, substituindo suposição por evidência documentada e, nos níveis mais altos, criptograficamente assinada.

Os três níveis de SLSA 

O framework SLSA é organizado em tracks, sendo o Build Track o mais maduro e amplamente adotado. Ele define três níveis de garantia, cada um construindo sobre o anterior.

Build L1 - Proveniência existe: o artefato possui um registro de proveniência que descreve como foi construído: qual plataforma de build, qual processo e quais foram os inputs. A proveniência pode ser incompleta ou não assinada. O objetivo é estabelecer rastreabilidade básica.

Build L2 - Plataforma de build hospedada: os builds rodam em uma plataforma hospedada (não na máquina pessoal de um desenvolvedor), e essa plataforma gera e assina a proveniência. A assinatura digital impede adulteração após o build e permite verificação de autenticidade por consumidores.

Build L3 - Builds hardened: a plataforma de build implementa controles rígidos: isolamento entre execuções (mesmo dentro do mesmo projeto), proteção do material criptográfico usado para assinar a proveniência, e garantias de que o processo de build não pode ser influenciado por agentes não autorizados.

Os níveis são cumulativos. L2 inclui todos os requisitos de L1, e L3 inclui todos os de L2. Essa estrutura permite adoção incremental sem exigir reestruturação completa dos pipelines existentes.

Este artigo concentra-se no nível 1. Os próximos artigos desta série abordarão L2 e L3 em profundidade.

Build L1 em detalhe: o que significa proveniência

Proveniência, no contexto de SLSA, é um documento que descreve a origem e o processo de construção de um artefato. Em termos práticos, é um registro estruturado que responde três perguntas:

1. Qual foi o input? 

   1. repositório de origem, branch, commit hash

2. Qual foi o processo?

   1. Exemplo: pipeline de CI/CD, build steps, configuração utilizada);

3. Qual foi o output?

   1.  digest criptográfico do artefato produzido.

No nível 1, os requisitos são intencionalmente acessíveis. A especificação exige três coisas:

O produtor de software segue um processo de build consistente, de forma que outros possam formar expectativas sobre como um build correto se parece. Existe proveniência descrevendo como o artefato foi construído, incluindo a plataforma de build, o processo e os inputs de alto nível. E o produtor distribui essa proveniência aos consumidores, preferencialmente usando uma convenção definida pelo ecossistema de pacotes.

É importante notar que, no L1, a proveniência pode ser incompleta e não precisa ser assinada. Essa é uma decisão deliberada do framework: reduzir a barreira de entrada para que organizações possam obter benefícios imediatos sem precisar implementar infraestrutura de assinatura criptográfica.

O que L1 resolve na prática

O valor do nível 1 é frequentemente subestimado porque parece simples. Mas a existência de proveniência, mesmo que básica, resolve problemas concretos.

Rastreabilidade de artefatos

Sem proveniência, quando um incidente ocorre em produção, a investigação começa com perguntas básicas que deveriam ter respostas triviais: de qual commit essa imagem foi construída? Qual pipeline gerou esse artefato? Qual configuração de build foi utilizada? Quais inputs de alto nível participaram da construção? Sem um registro formal, essas respostas dependem de busca manual em logs de CI, correlação de timestamps e, não raramente, da memória de quem fez o último deploy.

Com proveniência L1, essas informações são parte do artefato. A investigação parte de dados estruturados, não de reconstrução manual.

Prevenção de erros no processo de release

A proveniência permite verificação automatizada contra expectativas definidas. Um artefato que foi construído a partir de um commit que não pertence à branch principal, ou que foi gerado por um pipeline diferente do esperado, pode ser identificado e bloqueado antes de chegar à produção.

Esse tipo de verificação não impede ataques sofisticados (isso é responsabilidade dos níveis superiores), mas elimina uma categoria inteira de erros humanos no processo de release: builds feitos localmente e publicados manualmente, commits errados promovidos por engano, artefatos gerados por pipelines de desenvolvimento que chegam a ambientes de produção.

Inventário de plataformas e processos de build

Em organizações com múltiplas equipes, cada time tende a configurar seu próprio pipeline. A proveniência L1 cria visibilidade sobre quais plataformas de build estão sendo utilizadas, quais processos são seguidos e onde existem inconsistências. Essa visibilidade é pré-requisito para qualquer iniciativa de padronização ou hardening.

Como implementar L1

A implementação do nível 1 não exige mudanças na infraestrutura de build. Exige, fundamentalmente, que o processo de build produza e distribua um documento de proveniência.

Estrutura de um documento de proveniência

O formato recomendado segue o modelo in-toto, que define a proveniência como um predicate associado a um subject (o artefato). Um exemplo simplificado:

Esse documento vincula o digest do artefato ao repositório, commit, pipeline e timestamp do build. É uma declaração factual sobre como o artefato foi produzido.