Reproductible bit à bit : pourquoi votre auditeur va aimer notre usine à images

Un auditeur qui examine un système durci doit pouvoir établir un fait simple : le binaire déployé provient exactement du code source qu’il a lu. OC2-Edge apporte une réponse mécanique : le build est reproductible bit à bit. Deux builds indépendants de la même révision produisent des artefacts identiques, octet pour octet, et l’intégration continue (CI) le vérifie à chaque build. Cet article décrit le principe, ce qu’il faut figer pour y parvenir, les artefacts d’audit produits en sortie et ce que l’état de l’art fait déjà.

Le principe : deux builds indépendants, un même artefact

Le projet Reproducible Builds définit un build reproductible ainsi : à partir des mêmes sources, du même environnement de build et des mêmes instructions, toute partie peut recréer des copies identiques bit à bit de tous les artefacts spécifiés [1].

OC2-Edge applique cette définition en CI sous la forme d’un double build comparé. La chaîne exécute deux builds complets et indépendants de la même révision, dans des environnements séparés, puis compare les empreintes cryptographiques des artefacts produits : l’image système, les modules et leurs archives. Une divergence d’un seul octet fait échouer la chaîne. Le dépôt public compte 9 chaînes CI ; le double build comparé en fait partie.

Cette propriété change la nature de la confiance. Sans reproductibilité, le binaire est un acte de foi : il faut croire que la machine de build n’était pas compromise au moment de la compilation. Avec elle, la confiance se distribue : un tiers qui reconstruit la même révision et obtient la même empreinte confirme le binaire ; un environnement de build compromis produit une divergence détectable au lieu d’une porte dérobée invisible.

Le double build n’est pas une vérification ponctuelle. Il s’exécute à chaque révision, comme les autres chaînes. Une régression de reproductibilité, par exemple une dépendance qui incruste une nouvelle source de variation ou un outil mis à jour qui change de comportement, est détectée au commit qui l’introduit, pas des mois plus tard lors d’un audit. La reproductibilité est traitée comme un test : elle casse le build dès qu’elle cesse d’être vraie.

Ce qu’il faut figer

Un build ordinaire absorbe de l’entropie ambiante. La reproductibilité exige d’identifier chaque source de variation et de la figer :

1. les horodatages : la plupart des outils incrustent l’heure du build dans les artefacts. La variable SOURCE_DATE_EPOCH, convention établie par le projet Reproducible Builds, impose une date unique dérivée de la révision, identique d’un build à l’autre [2] ;
2. les ordres d’itération de fichiers : les systèmes de fichiers ne garantissent pas l’ordre de parcours des répertoires. Deux machines peuvent archiver les mêmes fichiers dans un ordre différent. Le build trie explicitement toute liste de fichiers avant archivage ;
3. les chemins de build : les chemins absolus du répertoire de travail se retrouvent dans les binaires, par les informations de debug et certaines macros. Le build normalise ces chemins vers des valeurs fixes ;
4. les locales et fuseaux horaires : l’ordre de tri et le formatage des chaînes dépendent de la locale. Le build fixe la locale et le fuseau à des valeurs uniques ;
5. les uid/gid : les archives portent les identifiants du compte qui les a créées. Le build les normalise à des valeurs fixes.

Le point commun de ces cinq chantiers : chacune de ces valeurs est une entrée cachée du build. La reproductibilité consiste à transformer toutes les entrées cachées en entrées explicites et figées.

Cette liste n’est pas close. Chaque nouvelle dépendance peut introduire une source de variation inédite. Le double build comparé sert précisément de filet : une source oubliée se manifeste comme une divergence visible en CI, jamais comme un artefact silencieusement non reproductible.

Les artefacts d’audit produits à chaque build

Le build ne produit pas seulement une image. Il produit, dans le même passage, le dossier destiné à l’auditeur :

• un SBOM (Software Bill of Materials, inventaire des composants logiciels) au format SPDX, normalisé ISO/IEC 5962:2021 [3], couvrant les éléments minimaux définis par la NTIA [7] ;
• un rapport CVE (Common Vulnerabilities and Exposures) : le SBOM est confronté aux bases de vulnérabilités publiques. Le rapport n’est pas filtré : les correspondances sont publiées telles quelles, y compris quand elles sont défavorables ;
• un bilan de licences : l’inventaire des licences des dépendances et leur compatibilité avec la licence Apache-2.0 du projet ;
• un manifeste de provenance signé : la révision exacte, l’environnement de build et les entrées utilisées, dans l’esprit des cadres SLSA [5] et in-toto [6] qui formalisent la provenance dans la chaîne d’approvisionnement logicielle. Le manifeste accompagne l’image dans le dépôt de mise à jour TUF (The Update Framework) ;
• des binaires Rust auditables : cargo-auditable incruste la liste des dépendances dans le binaire lui-même [4]. Un auditeur interroge le binaire déployé sur le terrain, sans accès à la CI ni au dépôt de sources.

L’ensemble est produit par le build, à chaque build, pour chaque révision. Il n’existe pas de version « préparée pour l’audit » distincte de la version courante.

Le lien avec l’homologation

Un dossier d’homologation exige de relier chaque exigence de sécurité au mécanisme qui la satisfait et à la preuve que le mécanisme fonctionne. Dans OC2-Edge, cette matrice exigence-mécanisme-preuve est générée par le build, pas rédigée après coup : le SBOM, le rapport CVE, le bilan de licences et le manifeste de provenance sont datés, signés et attachés à une révision précise. Quand l’image change, les preuves changent avec elle, dans le même passage de CI. La démarche complète est traitée dans un article dédié de la série : homologuer en continu.

Pour l’auditeur, la conséquence est concrète. Il ne reçoit pas un document figé qui décrit un système ayant déjà changé depuis sa rédaction. Il reçoit un procédé qui régénère les preuves à chaque build, et qu’il peut rejouer lui-même sur la révision de son choix.

Ce que l’état de l’art fait déjà, ce que nous en reprenons

La reproductibilité bit à bit n’est pas une invention d’OC2-Edge. Le projet Reproducible Builds, porté notamment par Debian, a défini la notion, construit l’outillage, dont SOURCE_DATE_EPOCH et diffoscope pour comparer les artefacts divergents, et démontré la faisabilité à l’échelle d’une distribution entière [1] [2]. OC2-Edge reprend ces conventions et les applique à un périmètre plus étroit et plus contraint : une image système immuable, ses modules signés et leurs artefacts d’audit.

Ce que le projet fait aujourd’hui : le double build comparé en CI, les artefacts d’audit générés à chaque build, les binaires auditables.

Ce qui reste ouvert, et que nous marquons comme tel :

1. la reconstruction par des tiers réellement indépendants : le double build tourne dans la CI du projet. Des rebuilders externes, sur le modèle de ceux de l’écosystème Debian, apporteraient une indépendance supérieure ; point ouvert ;
2. la reproductibilité de la chaîne de compilation elle-même : le compilateur et les outils de build sont épinglés par version et par empreinte, mais leur propre bootstrap reproductible est hors du périmètre actuel ;
3. la couverture : la reproductibilité est vérifiée sur les artefacts publiés de l’image et des modules. L’étendre à tout artefact secondaire est un chantier en cours.

Vérifier le build

La vérification ne demande pas de nous croire. Cloner le dépôt, construire deux fois la même révision en suivant la documentation de build, comparer les empreintes : l’égalité s’observe, elle ne s’affirme pas. Le dépôt public, sous licence Apache-2.0, compte ~930 tests automatisés au vert, et le double build comparé fait partie des 9 chaînes CI publiées.

Sources

1. Reproducible Builds, « Definition », consulté en 2026, https://reproducible-builds.org/docs/definition/
2. Reproducible Builds, « SOURCE_DATE_EPOCH », consulté en 2026, https://reproducible-builds.org/docs/source-date-epoch/
3. SPDX, Linux Foundation, « The Software Package Data Exchange (SPDX) Specification », ISO/IEC 5962:2021, https://spdx.dev/
4. rust-secure-code, « cargo-auditable », consulté en 2026, https://github.com/rust-secure-code/cargo-auditable
5. OpenSSF, « SLSA : Supply-chain Levels for Software Artifacts », consulté en 2026, https://slsa.dev/
6. in-toto, « A framework to secure the integrity of software supply chains », consulté en 2026, https://in-toto.io/
7. NTIA, « The Minimum Elements For a Software Bill of Materials (SBOM) », 2021, https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom