O que é o SLSA? Supply-chain Levels for Software Artifacts

Que problema resolve o SLSA?

Pode rever cada linha de código-fonte e ainda assim distribuir outra coisa, porque o que os utilizadores executam é o resultado de um build. Se o build for comprometido, como aconteceu na SolarWinds, um código-fonte limpo produz uma versão envenenada. O SLSA concentra-se nessa lacuna: alguém consegue verificar que este artefacto veio deste código-fonte, através deste processo?

Níveis do SLSA

O SLSA organiza os seus requisitos em tracks. A versão atual, 1.2, tem um Build track e um Source track. O Build track tem quatro níveis.

Nível	Nome	O que exige	O que oferece
Build L0	Sem garantias	Nada	L0 é a ausência de SLSA
Build L1	Existe proveniência	Um processo de build coerente e proveniência gerada pela plataforma de build e fornecida aos consumidores	Ajuda a evitar erros, mas é trivial de contornar ou falsificar
Build L2	Plataforma de build alojada	Os builds são executados numa plataforma alojada que gera e assina a proveniência, e os consumidores verificam-na	Falsificar a proveniência passa a exigir um ataque explícito
Build L3	Builds reforçados	As execuções estão isoladas umas das outras, e o segredo de assinatura está fora do alcance dos passos de build definidos pelo utilizador	Falsificar a proveniência exige explorar uma vulnerabilidade, o que está fora do alcance da maioria dos adversários

Os níveis não são uma nota que tenha de maximizar. Cada um protege contra ameaças específicas, por isso escolha o nível adequado ao seu risco. Os responsáveis por projetos open source com um serviço de CI alojado conseguem muitas vezes chegar ao L2 sem grande trabalho.

O que é a proveniência?

A proveniência é um registo de como um artefacto foi produzido. No SLSA, indica que plataforma o compilou, a partir de que código-fonte, através de que processo e com que entradas de nível superior. A proveniência a partir do L2 é assinada, pelo que um consumidor pode verificar que veio da plataforma de build e que não foi alterada.

Pense numa SBOM como os ingredientes e na proveniência como o local e a forma como o prato foi cozinhado. Respondem a perguntas diferentes e funcionam bem em conjunto: uma SBOM lista o que está lá dentro, enquanto a proveniência diz de onde veio o artefacto.

Como adotar o SLSA

Compile na CI, sempre da mesma forma. Deixe de lançar versões a partir de portáteis. Isto é a maior parte do trabalho para chegar ao L1.
Gere a proveniência. No GitHub, as atestações de artefactos produzem proveniência assinada. Consulte como funcionam as atestações com SBOM no GitHub Actions.
Verifique-a onde importa. Uma proveniência assinada que ninguém verifica não protege ninguém. Acrescente a verificação ao passo de implementação ou ao seu admission controller.
Reforce o build. Isole as execuções e mantenha as chaves de assinatura longe dos passos de build. Consulte segurança dos runners comparada.
Questione as suas dependências. Dê preferência a pacotes que publiquem proveniência, algo que registos como o npm já suportam.

O que o SLSA não cobre

Vulnerabilidades. Um artefacto perfeitamente compilado pode conter uma falha. O SLSA não diz nada sobre se o código é seguro.
Código-fonte malicioso. Se um atacante fizer commit no repositório, a proveniência regista fielmente um build desse código. O Source track aborda parte deste problema.
O que o build trouxe. A proveniência lista as entradas de nível superior. Nada no Build track exige uma lista completa das dependências, e é para isso que serve uma SBOM.
Pessoas internas de confiança. A backdoor do xz entrou através de um responsável pela manutenção de confiança, e o SLSA, por si só, não a teria travado.

O SLSA e outros referenciais

O SLSA aprofunda a integridade do build. O NIST SSDF é muito mais amplo: cobre o desenvolvimento seguro como um todo, incluindo uma prática sobre proteção e arquivo de versões que a proveniência do SLSA apoia. O SLSA é um projeto da OpenSSF, e muitas equipas usam os dois em conjunto. Para uma visão de conjunto, consulte o que é a segurança da cadeia de abastecimento de software.

Onde se enquadra o CRACI

O CRACI não produz proveniência assinada nem reivindica nenhum nível SLSA, pelo que deve usar as atestações de artefactos do GitHub ou um serviço semelhante se precisar de um. O que o CRACI acrescenta é o que o SLSA deixa de fora: um registo completo do que cada job de GitHub Actions trouxe. Cada job é executado na sua própria máquina virtual isolada, cada pacote que obtém entra numa SBOM e uma política de egress bloqueia as ligações de que o build não precisa. Consulte geração de SBOM durante o build.

SLSA: perguntas frequentes

O que significa SLSA?

Supply-chain Levels for Software Artifacts. Pronuncia-se «salsa».

Quais são os níveis do SLSA?

O Build track tem quatro: L0, sem garantias; L1, existe proveniência; L2, uma plataforma de build alojada que assina a proveniência; e L3, builds reforçados com execuções isoladas e segredos de assinatura protegidos. A versão 1.2 acrescenta também um Source track.

O que é a proveniência SLSA?

Um registo de como um artefacto foi compilado: que plataforma, a partir de que código-fonte, através de que processo e com que entradas de nível superior. A partir do Build L2 é assinada, pelo que os consumidores a podem verificar.

Qual é a diferença entre o SLSA e uma SBOM?

Uma SBOM lista o que está dentro de um software. A proveniência SLSA descreve como e onde foi compilado. De modo geral, convém ter ambas.

O SLSA é obrigatório?

Não. É um referencial voluntário da comunidade OpenSSF. Alguns clientes e organizações podem pedir um nível, mas não é uma lei.

Que nível do SLSA devo procurar atingir?

Comece pelo Build L1, compilando na CI e gerando proveniência, e passe depois ao L2 numa plataforma alojada, que muitas equipas conseguem atingir rapidamente. O L3 é adequado a versões de que muitos outros dependem ou que comportam um risco elevado.