SLSA tornou a segurança da cadeia de suprimentos adotável ao transformá-la em níveis

Após os ataques à cadeia de build do SolarWinds, do Codecov e de outros, os consumidores de software precisavam saber se um artefato veio da origem e do processo de build esperados. Um binário sozinho não conseguia responder a essa pergunta.

A jogada do SLSA não foi exigir perfeição imediatamente. A proposta do Google de 2021 descrevia quatro níveis adotáveis de forma incremental, começando com builds automatizados que geram proveniência e subindo em direção a isolamento de build, revisão e reprodutibilidade mais fortes.

A especificação v1.0 refinou isso em trilhas e níveis: um vocabulário compartilhado, uma lista de verificação e um modelo de evidências para produtores, consumidores e provedores de infraestrutura. O formato venceu por tornar o progresso parcial legível, em vez de tratar a segurança como tudo ou nada.

Fazer da integridade uma escada, não um interruptor

Os níveis permitiram que as organizações declarassem uma postura de integridade específica sem fingir que todas as dependências eram perfeitas.

A proveniência tornou o processo de build verificável por mecanismos de política e consumidores.

O framework mapeou o risco abstrato da cadeia de suprimentos para controles concretos de origem, build e distribuição.

Os níveis inferiores criaram um caminho de atualização para projetos que não conseguiam saltar direto para o patamar mais alto.

Quando o padrão ideal é caro demais para a maioria dos usuários, a adoção pode começar nomeando garantias parciais que ainda reduzem o risco.

O SLSA tornou-se uma linguagem comum para a integridade de artefatos de software. Seus níveis agora são usados ao lado de SBOMs, Sigstore e atestações in-toto para decidir se um pacote foi construído por um sistema esperado a partir da origem esperada.