Principios de procedencia y atestación

Una huella dice si dos archivos son iguales; una firma dice quién respalda algo. Una atestación junta las dos ideas: es una afirmación firmada sobre uno o varios artefactos, que los identifica por su huella. El formato abierto más usado para escribirlas, el de in-toto, la arma en tres piezas: el sujeto (cada artefacto con su nombre y su huella), el tipo de afirmación y el contenido de esa afirmación.

La procedencia es un tipo concreto de atestación: cuenta cómo se produjo el artefacto, qué sistema lo construyó, con qué parámetros y a partir de qué entradas. SLSA, el marco abierto de integridad de la cadena de suministro que mantiene la OpenSSF, define un formato de procedencia que viaja dentro de ese mismo sobre. Lo importante para quien audita es qué ata la afirmación al archivo: no es el nombre, que cualquiera puede reutilizar, sino la huella.

Un modelo ajustado tiene, como mínimo, tres entradas: el modelo base del que parte, los datos con los que se ajusta y el código de la receta. En la procedencia que define SLSA se anotan en la lista de dependencias resueltas, cada una con su dirección y, si se hace bien, con su huella. Esa lista es lo que permite responder después a la pregunta que toda investigación termina haciendo: si mañana se descubre que un lote de datos estaba contaminado, ¿qué modelos se entrenaron con él?

Una entrada declarada por versión y huella se puede rastrear; una declarada por un nombre que cambia, no. Lee la procedencia y localiza la entrada de datos.

Una atestación solo responde por sus sujetos. Si el despliegue carga un archivo que no figura entre ellos, ese archivo viaja sin procedencia aunque el resto esté impecable, y nadie puede decir de dónde salió. En un modelo esto no es un detalle: además de los pesos, hay piezas pequeñas que cambian cómo se comporta el sistema, y son justo las que se olvidan al armar la lista.

Cruza los sujetos de la atestación con los archivos que el registro publicó y que el despliegue carga.

La procedencia contesta «cómo se hizo»: qué plataforma lo construyó, cuándo, con qué receta y con qué entradas. No contesta «si es bueno». Un modelo con una procedencia perfecta puede haberse ajustado con datos mal etiquetados, puede responder cosas que no debe y puede fallar en la evaluación de seguridad. La procedencia sirve para confiar en el proceso y para rastrear, no para saltarse la evaluación del resultado.