Resumo

  • SLSA v1.2 trata proveniência como evidência que precisa ser inspecionada diante de expectativas; a atestação não toma uma decisão sozinha.
  • A especificação separa a declaração ligada ao artefato, a raiz de confiança, as expectativas ligadas ao nome do pacote e a aceitação feita por ecossistema, consumidor ou monitor.
  • Um recibo de expectativas e resposta impede que uma atestação válida seja lida como aprovação geral de uma release.

Uma declaração sobre um artefato, não sobre tudo

O modelo de proveniência de build da SLSA afirma que uma plataforma de build determinada produziu artefatos por meio de uma buildDefinition. A declaração pode ligar o subject a um digest, identificar o builder e registrar tipo de build, parâmetros e dependências. Isso permite comparar a construção ocorrida com a construção esperada e, quando necessário, investigar ou reproduzir o processo.

A documentação de distribuição fixa o mesmo limite: atestações devem estar ligadas a artefatos, e não a releases. Uma release pode reunir arquivos para arquiteturas e ambientes diferentes, construídos em momentos diferentes; o conjunto de artefatos e atestações pode crescer depois. Por isso o nome de uma release não substitui a relação exata entre um binário e sua evidência.

Essa precisão não torna a atestação menos importante. Ela evita que um registro verificável seja convertido em selo genérico. A SLSA diz que a proveniência não faz nada até alguém inspecioná-la. Há uma sequência: gerar evidência, compará-la e decidir a consequência. Uma frase que chama tudo de “aprovado” apaga essa sequência e dificulta qualquer revisão posterior.

A expectativa pertence ao verificador

Para verificar, a SLSA manda configurar raízes de confiança: identidades de builders reconhecidos e o nível SLSA até o qual cada identidade é aceita. O verificador confere a assinatura, relaciona o subject ao digest do artefato e verifica se buildType e externalParameters correspondem ao que era esperado.

Uma assinatura correta não escolhe esse conjunto esperado. Verificadores diferentes podem manter raízes de confiança diferentes. A SLSA também separa expectativas ligadas ao nome de um pacote da proveniência ligada ao artefato. Um ecossistema pode ligar um nome a um repositório canônico; o consumidor pode impor regra própria; o produtor pode comunicar expectativas por um canal autenticado; confiança no primeiro uso pode transformar um estado inicial em referência. Tudo isso responde a uma pergunta que a atestação não responde: quais valores são permitidos para este pacote neste contexto?

externalParameters deixa a fronteira visível. São valores sob controle externo, devem aparecer na proveniência e precisam ser conferidos depois. Estarem presentes não os torna autorizados. A recomendação é falhar diante de parâmetros não reconhecidos. Da mesma forma, ver um builder.id não obriga toda organização a tratá-lo como confiável. Autenticidade liga uma declaração ao emissor; confiança continua sendo política.

A aceitação ocorre em um lugar escolhido

SLSA admite verificação no upload ao ecossistema, no download ou uso pelo consumidor e em um monitor. As três podem coexistir. O registro pode recusar uma carga; o consumidor pode recusar instalar ou implantar; o monitor pode divulgar uma discrepância. A própria especificação avisa que detectar falha tem benefício limitado se ninguém, humano ou automatizado, agir em seguida.

Logo o mesmo artefato pode passar por uma política, falhar em outra ou ficar sob alerta sem resposta final. Não é incoerência da proveniência; são decisões com proprietários diferentes. A orientação de distribuição descreve a proveniência como o que um repositório precisa para verificar uma política potencial que exija determinado nível SLSA. Ela não é a política, sua execução nem o registro de que a admissão aconteceu.

Um recibo para expectativa e resposta

Não é preciso inventar outro formato SLSA. O mecanismo mínimo é um recibo guardado por quem verifica. Ele deve registrar digest e referência da atestação, verificador e versão da política, raiz realmente usada, fonte canônica esperada, buildType, limite de parâmetros externos permitidos, data da avaliação e resultado.

Se houver falha, o recibo deve dizer se houve rejeição, quarentena, alerta, exceção temporária ou pendência, e quem pode mudar o estado. Se a expectativa mudar, deve apontar a mudança autorizada, em vez de reescrever o resultado antigo. Isso não promete segurança universal, dependências completas ou remediação rápida. Apenas separa evidência autêntica, artefato aceito, mudança de política, alerta e resposta concluída.

Coordenação sem apropriar autoridade

A lição de Heng Lu importa como método: um registro de coordenação deve declarar o alcance que tem, não fabricar uma realidade que ninguém adotou. A SLSA descreve geração, distribuição e verificação de proveniência, mas preserva escolhas independentes sobre confiança, expectativa e consequência.

O atalho caro junta numa mesma frase build autêntico, pacote aprovado, release acabada e resposta eficaz. Quando a raiz muda, uma arquitetura nova é incluída, uma exceção expira ou o monitor encontra diferença, a frase não permite reconstituir a decisão. O recibo mantém as partes legíveis e ainda permite que trabalhem juntas.

Fontes

  1. SLSA v1.2 — Build: Verifying artifacts
  2. SLSA v1.2 — Build: Provenance
  3. SLSA v1.2 — Build: Distributing provenance