Resumen

  • SLSA v1.2 trata la procedencia como evidencia que alguien debe inspeccionar frente a expectativas: la atestación no decide nada por sí misma.
  • La especificación diferencia la declaración ligada a un artefacto, la raíz de confianza, las expectativas ligadas al nombre de un paquete y la aceptación decidida por ecosistema, consumidor o monitor.
  • Un recibo de expectativas y respuesta evita que una atestación legítima se convierta retóricamente en aprobación universal de una versión.

La declaración está ligada al artefacto

El modelo SLSA de procedencia de construcción hace una afirmación delimitada: una plataforma concreta produjo determinados artefactos al ejecutar una buildDefinition. Puede relacionar el sujeto con un digest, identificar al constructor, declarar el tipo de construcción y registrar parámetros y dependencias. Sirve para comparar una construcción real con lo que el verificador esperaba, y también para investigar o reproducir una construcción si hace falta.

La guía de distribución insiste en el mismo límite: las atestaciones deberían estar ligadas a artefactos, no a releases. Una release puede abarcar binarios para varias arquitecturas, entornos y momentos; pueden agregarse después otros artefactos con sus propias atestaciones. Por eso la etiqueta de una release no sustituye la relación precisa entre un archivo y la evidencia que lo acompaña.

La precisión no es una carencia. Impide que una declaración verificable se convierta en un distintivo vacío. SLSA dice que la procedencia no hace nada hasta que alguien la inspecciona. Hay tres actos, no uno: se emite la evidencia, un verificador la compara y una parte autorizada decide qué hacer con el resultado.

Las expectativas no aparecen dentro del sobre

SLSA pide configurar raíces de confianza: identidades de constructores reconocidas y el nivel SLSA hasta el cual cada una merece confianza. Después pide validar la firma, relacionar el subject con el digest del artefacto y comprobar que buildType y externalParameters coincidan con los valores esperados.

Una atestación firmada correctamente no escoge esos valores. SLSA admite que distintos verificadores empleen raíces de confianza distintas y explica que las expectativas se vinculan al nombre de un paquete, mientras la procedencia se vincula al artefacto. Un ecosistema puede fijar un repositorio canónico; un consumidor puede imponer su propia política; un productor puede publicar expectativas por un canal autenticado; la confianza en el primer uso puede convertir el estado inicial en referencia. Todas responden a una pregunta que la atestación no resuelve: qué está permitido para este paquete en este contexto.

Los parámetros externos son el ejemplo más claro. Están bajo control externo, deben quedar registrados y deben verificarse después. Que figuren en el documento no los vuelve aceptables. SLSA recomienda rechazar parámetros no reconocidos. Del mismo modo, que una identidad de constructor aparezca en una atestación no obliga a todos los verificadores a confiar en ella. La autenticidad acredita una declaración y su emisor; la confianza es una decisión de política.

La aceptación tiene un punto y un responsable

SLSA reconoce varios lugares de verificación: un ecosistema puede hacerlo al recibir una carga, un consumidor al descargar o utilizar, y un monitor sobre el conjunto que vigila. Pueden coexistir. El registro decide admisión; el consumidor decide instalación o despliegue; el monitor publica un hallazgo. La propia guía advierte que detectar un fallo ayuda poco si ninguna persona o sistema actúa después.

Un artefacto puede, por tanto, pasar una política, no pasar otra o quedar señalado a la espera de respuesta. No es una contradicción de la procedencia; son consecuencias de decisiones con propietarios diferentes. El texto de distribución explica que la procedencia entrega a un repositorio lo necesario para comprobar una política potencial que exija cierto nivel SLSA. No es esa política, ni su ejecución, ni el acta de aceptación.

Decir «hay procedencia SLSA» es una afirmación útil y limitada. No significa que toda la release esté aceptada por todos, que todos los consumidores compartan una raíz de confianza ni que una discrepancia active una remediación concreta.

Un recibo de expectativas y respuesta

El control más pequeño no es una nueva extensión de SLSA. Es un recibo junto a la decisión de verificación. Debe incluir el digest del artefacto y referencia de la atestación, el verificador y versión de política, la entrada de raíz utilizada, repositorio canónico esperado, buildType, límites permitidos para parámetros externos, momento de la evaluación y resultado.

Si hay fallo, el recibo debe indicar si hubo rechazo, cuarentena, alerta, excepción temporal o espera, además de quién puede cambiar ese estado. Si una expectativa se modifica, debe enlazar la decisión autorizada, no reescribir el resultado previo como si nunca hubiera existido.

No promete seguridad absoluta, dependencia completa ni respuesta rápida. Sí permite separar una atestación auténtica de un artefacto aceptado, un cambio de política de una rotación de firma, una admisión de registro de una decisión de despliegue y una alerta de una remediación terminada.

Mantener la frontera conserva la elección

La enseñanza de Heng Lu sirve como método y no como prueba sobre SLSA: un registro de coordinación debe mostrar la autoridad que posee, no decretar realidad no adoptada. SLSA describe producción, distribución y verificación de procedencia; no borra las decisiones independientes sobre confianza, expectativas o consecuencias.

El atajo costoso funde en una sola frase construcción auténtica, paquete aprobado, release terminada y respuesta eficaz. Ese relato se vuelve imposible de reconstruir cuando cambia una raíz, se añade una arquitectura, vence una excepción o un monitor encuentra una diferencia. El recibo mantiene legibles evidencia, expectativa y decisión sin impedir que cooperen.

Fuentes

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