SLSA aplicado a pipelines de ML

La especificación de SLSA (la versión vigente es la 1.2) organiza su vía de construcción en cuatro niveles. En el L0 no hay garantías. En el L1 existe procedencia: el proceso de construcción es consistente y la plataforma genera un documento que dice quién construyó, cómo y con qué entradas; sirve contra errores, pero es fácil de falsificar. En el L2 la construcción corre en una plataforma alojada que genera y firma la procedencia, y quien consume la verifica: protege contra cambios hechos después de construir. En el L3 esa plataforma está endurecida: una ejecución no puede influir en otra, ni siquiera dentro del mismo proyecto, y los pasos que escribe el equipo no tienen a su alcance la llave con la que se firma la procedencia.

En un pipeline de ML la «construcción» es el entrenamiento o el ajuste: la receta es el código, y las entradas son el modelo base y los datos.

Para el nivel más alto no basta con que la plataforma firme. Hacen falta las dos condiciones de endurecimiento a la vez: ejecuciones aisladas entre sí y la llave de firma fuera del alcance de la receta. Si la llave es una variable que la receta puede leer, una receta modificada podría firmar una procedencia inventada; si los ejecutores se comparten y se reutilizan, una ejecución puede dejar algo que contamine la siguiente.

Un pipeline que genera procedencia pero no la firma está en L1, aunque corra en la plataforma alojada: su documento dice cosas ciertas, pero nadie puede comprobar que no se cambió después. Uno que no genera procedencia en absoluto se queda en L0.

Los niveles de construcción miden el sistema que entrena, no si las entradas están bien fijadas. Un pipeline puede estar en un nivel alto y aun así entrenar con «lo que haya hoy» en una etiqueta que otro equipo mueve. La procedencia lo anotará con honestidad, pero quien investigue después no sabrá qué contenía esa etiqueta el día del entrenamiento. Por eso, junto al nivel, se revisa cómo entra cada dato.

En software, a veces se puede reconstruir un paquete y comparar los bytes para comprobar que la procedencia dice la verdad. En ML eso casi nunca funciona: repetir un entrenamiento en otro hardware, con otro orden de lotes o con operaciones no deterministas da pesos distintos aunque todo sea legítimo. Esa es la razón práctica por la que en un pipeline de ML la confianza descansa sobre todo en la procedencia firmada por una plataforma endurecida, y en que sus entradas estén fijadas por huella.