Verificación en el consumo

La guía de verificación de SLSA v1.0 se resume en tres pasos. Primero, comprobar la atestación: la firma del sobre con las claves de confianza, que el sujeto coincida con la huella del artefacto y que el predicateType sea el esperado. Segundo, comparar con lo esperado: el constructor, el repositorio de origen canónico, el buildType y los externalParameters, rechazando los campos que no se reconocen. Tercero, opcional, verificar las dependencias resueltas.

El orden importa: sin el primer paso, el segundo compara un papel que no se sabe de dónde viene.

Abre consumo/resultado-de-verificacion.txt. Una firma válida solo asegura que alguien con la clave firmó esa procedencia. Si el sujeto de la procedencia no coincide con la huella del artefacto del almacén, la procedencia habla de otra cosa: el artefacto que tienes puede no ser el que se construyó.

La política dice que externalParameters solo puede contener cuatro campos y que cualquier otro se rechaza. La razón: un parámetro externo desconocido es una entrada que alguien pasó a la construcción y que nadie previó. Aunque todo lo demás esté bien, una versión que lo trae no se despliega hasta entender qué hace.

Aplica la política completa a las cinco versiones: firma, sujeto, constructor, repositorio y parámetros. Una versión se despliega solo si pasa todo. Una sola falla basta para rechazarla.

Abre consumo/donde-se-verifica.txt. Higuerilla Software solo verifica dentro del flujo de construcción, antes de publicar. Una prueba interna dejó en el almacén un artefacto que no pasó por el flujo y se desplegó sin que nada lo comprobara. La verificación en el flujo protege el camino habitual, pero no cubre lo que llega al almacén por otro lado.