Atestaciones de procedencia de build: qué registra la procedencia SLSA y cómo se verifica

Qué es

La procedencia, en la especificación SLSA, es información verificable sobre cómo se produjo un artefacto: qué entidad lo construyó, qué proceso usó y cuáles fueron las entradas. El track Build define niveles. Build L1: existe procedencia, posiblemente sin firmar; previene errores, pero resulta "trivial de eludir o falsificar". Build L2: una plataforma de build alojada genera y firma la procedencia, lo cual protege contra la manipulación posterior al build. Build L3: una plataforma reforzada cuyas ejecuciones no pueden influirse entre sí y cuyo material de firma de la procedencia no es accesible a los pasos de build definidos por el usuario, lo cual protege contra la manipulación durante el build. El formato recomendado es una atestación in-toto con predicateType https://slsa.dev/provenance/v1. Su subject enumera los artefactos de salida por digest. buildDefinition contiene el buildType (una plantilla que identifica el proceso), externalParameters (las entradas no confiables, que deben registrarse y verificarse más adelante), internalParameters opcionales, y resolvedDependencies (a qué se resolvieron las entradas, por ejemplo el commit exacto al que apuntaba la URL de un repositorio). runDetails nombra el builder.id y los metadatos de la ejecución. La plataforma de build firma el envelope.

Por qué importa

Un SBOM dice qué hay dentro de un artefacto; la procedencia dice quién lo construyó y a partir de qué. Con procedencia verificada, quien consume puede rechazar un paquete construido a partir de un commit que no está en el repositorio upstream, construido por un workflow inesperado, o construido con parámetros que difieren del proceso de release documentado. La procedencia no verificada es solo documentación.

Cómo aplicarlo

• Quien produce: construir en una plataforma que genere y firme la procedencia, publicar la atestación junto al artefacto, y mantener el proceso de build consistente para que quien consume pueda formarse expectativas sobre él.
• Quien consume: seguir los pasos de la especificación. Verificar la firma del envelope contra raíces de confianza configuradas (un mapa desde la identidad de quien construye hasta el nivel para el que se confía en ella); comprobar que el digest del subject coincide con el artefacto y que predicateType es el tipo de procedencia de SLSA; luego comparar buildType y externalParameters con los valores esperados. La especificación indica que los parámetros externos no reconocidos deberían hacer fallar la verificación.
• Decidir la acción ante un fallo (bloquear, advertir, registrar) antes de habilitar la verificación, y comenzar con artefactos donde se controlan ambos extremos.

Trampas

La procedencia L1 es falsificable; detecta errores, no atacantes. Confiar en un builder.id sin fijar su clave o la identidad de su certificado vuelve la firma carente de sentido. La procedencia cubre el build, no la revisión del código fuente ni los propios builds de las dependencias; la comprobación recursiva opcional de dependencias de la especificación y su track Source separado abordan esos aspectos.