Build reproductible

Un build reproductible produit une sortie identique bit à bit chaque fois que quelqu'un construit le même code source avec le même environnement de build et les mêmes instructions de build. C'est la définition du projet Reproducible Builds. La sortie désigne ici les artefacts que le build doit produire : exécutables, paquets de distribution, images de conteneur ou de système de fichiers. Les journaux ne comptent pas. « Ça compile encore » n'est pas la même chose ; reproductible signifie que les octets sont identiques.

Pourquoi la plupart des builds ne sont pas reproductibles

• Résolution des dépendances au moment du build. Sans lockfile, un gestionnaire de paquets choisit les versions pendant le build. La résolution PyPI peut aboutir différemment selon l'ordre d'arrivée des réponses, une plage de versions bouge dès qu'une nouvelle version sort, et une étiquette mutable comme latest pointe ailleurs.
• L'environnement. Horodatages, chemins de fichiers, locale et outils propres à l'hôte se retrouvent dans les artefacts.
• L'aléatoire. Des étapes de build peuvent générer des identifiants, trier des fichiers par hash ou exécuter des tâches en parallèle dans un ordre différent à chaque fois.

Construire deux fois de suite le même commit ne garantit donc ni le même résultat ni la même SBOM. Un build qui télécharge du code que son lockfile ne liste pas, une dépendance cachée, aggrave encore la situation.

Comment les équipes rendent leurs builds reproductibles

• Épinglez et verrouillez chaque entrée, y compris les images de base par digest et les outils par version (voir lockfile).
• Utilisez une heure fixe au lieu de l'horloge : SOURCE_DATE_EPOCH est une variable d'environnement standard contenant un horodatage Unix que les outils de build utilisent à la place de l'heure courante.
• Supprimez ou normalisez les chemins de build, triez les listes de fichiers et fixez la locale.
• Construisez dans un environnement hermétique dont la chaîne d'outils est elle-même épinglée. Nix est une façon de le faire.
• Vérifiez-le : construisez deux fois le même commit, de façon indépendante (sur une autre machine, dans un autre chemin, un autre jour), et comparez les sorties. Là où les empreintes diffèrent, diffoscope montre précisément ce qui a changé.

Le Yocto Project montre pourquoi la reproductibilité est une propriété à vérifier plutôt qu'à supposer. Sa documentation indique que les builds du projet sont reproductibles « jusqu'au niveau binaire, horodatages compris » depuis la version 3.1, que seuls BitBake et OpenEmbedded-Core garantissent une reproductibilité complète, et que « dès que vous ajoutez une autre couche, cette garantie est annulée ». Le projet le teste avec oe-selftest.

Builds reproductibles et SBOM

Si chaque build était reproductible, vous pourriez reconstruire plus tard une ancienne version et générer sa SBOM. La plupart ne le sont pas : une reconstruction, ou un scan du code source aujourd'hui, décrit un build similaire, pas celui que vous avez livré. La SBOM qui montre ce qui est en production est celle enregistrée lors du build CI qui a produit la version.

Même un build reproductible ne dispense pas de cet enregistrement. Des hash identiques prouvent que deux builds ont produit la même sortie ; ils ne listent pas ce qui y est entré. Il vous faut toujours l'inventaire, et une déclaration honnête de sa complétude de la SBOM. Pourquoi la CI est l'endroit de la sécurité de la chaîne d'approvisionnement et les bonnes pratiques SBOM développent l'argument.

SLSA considère la reproductibilité comme l'un des moyens de vérifier qu'un build a fait ce qu'il prétend.

La reproductibilité s'obtient dans le système de build, avec des outils comme Nix, Yocto ou l'outillage de Debian. CRACI ne rend pas les builds reproductibles : il enregistre la SBOM de chaque build pendant son exécution, de sorte que la trace de ce qui a été livré ne dépend pas d'une reconstruction. Voir SBOM au moment du build.