Build reproducible

Un build reproducible produce una salida idéntica bit a bit cada vez que alguien construye el mismo código fuente con el mismo entorno de build y las mismas instrucciones de build. Es la definición del proyecto Reproducible Builds. La salida son aquí los artefactos que el build debe producir: ejecutables, paquetes de distribución, imágenes de contenedor o de sistema de archivos. Los registros no cuentan. «Vuelve a compilar» no es lo mismo; reproducible significa que los bytes coinciden.

Por qué la mayoría de los builds no son reproducibles

• Resolución de dependencias durante el build. Sin lockfile, un gestor de paquetes elige las versiones mientras se ejecuta el build. La resolución en PyPI puede acabar de forma distinta según el orden en que lleguen las respuestas, un rango de versiones se desplaza cuando sale una nueva versión y una etiqueta mutable como latest apunta a otro sitio.
• El entorno. Marcas de tiempo, rutas de archivo, la configuración regional y las herramientas del propio host acaban dentro de los artefactos.
• El azar. Los pasos de build pueden generar identificadores, ordenar archivos por hash o ejecutar tareas en paralelo en un orden distinto cada vez.

Construir el mismo commit dos veces seguidas no garantiza, por tanto, el mismo resultado ni la misma SBOM. Un build que descarga código que su lockfile no enumera, una dependencia oculta, lo empeora.

Cómo hacen los equipos que sus builds sean reproducibles

• Fije y bloquee cada entrada, incluidas las imágenes base por digest y las herramientas por versión (vea lockfile).
• Use una hora fija en lugar del reloj: SOURCE_DATE_EPOCH es una variable de entorno estándar con una marca de tiempo Unix que las herramientas de build usan en lugar de la hora actual.
• Elimine o normalice las rutas de build, ordene las listas de archivos y fije la configuración regional.
• Construya en un entorno hermético cuya cadena de herramientas también esté fijada. Nix es una forma de hacerlo.
• Verifíquelo: construya el mismo commit dos veces, de forma independiente (en otra máquina, en otra ruta, otro día), y compare las salidas. Donde los hashes difieran, diffoscope muestra exactamente qué cambió.

El Yocto Project muestra por qué la reproducibilidad es una propiedad que hay que verificar y no suponer. Su documentación dice que los builds del proyecto son reproducibles «hasta el nivel binario, incluidas las marcas de tiempo» desde la versión 3.1, que solo BitBake y OpenEmbedded-Core garantizan una reproducibilidad completa y que «en cuanto añade otra capa, esta garantía queda anulada». El proyecto lo prueba con oe-selftest.

Builds reproducibles y SBOM

Si todos los builds fueran reproducibles, podría reconstruir más tarde una versión antigua y generar su SBOM. La mayoría no lo son, así que una reconstrucción, o un escaneo del código fuente hoy, describe un build parecido, no el que distribuyó. La SBOM que muestra lo que hay en producción es la registrada en el build de CI que produjo la versión.

Ni siquiera un build reproducible hace innecesario ese registro. Que los hashes coincidan prueba que dos builds produjeron la misma salida; no enumera lo que entró. Sigue necesitando el inventario y una declaración honesta de su completitud de la SBOM. Por qué la CI es el lugar de la seguridad de la cadena de suministro y buenas prácticas de SBOM desarrollan el argumento.

SLSA trata la reproducibilidad como una forma de verificar que un build hizo lo que dice.

La reproducibilidad la logran los equipos en su sistema de build, con herramientas como Nix, Yocto o las de Debian. CRACI no hace reproducibles los builds: registra la SBOM de cada build mientras se ejecuta, para que la constancia de lo que se distribuyó no dependa de reconstruirlo. Vea SBOM en tiempo de build.