Hermetic Build

devsecops

Définition

Un Hermetic Build (build hermétique) est un processus de compilation logicielle dans lequel l'environnement de build est complètement isolé de toute influence externe non déclarée : pas d'accès à Internet pendant le build, pas de dépendances non déclarées dans le manifeste, pas d'accès aux fichiers du système hôte au-delà du code source. Tout ce dont le build a besoin (compilateurs, bibliothèques, outils) doit être explicitement déclaré et versionné dans le système de build. L'objectif des builds hermétiques est de garantir la reproductibilité et la confiance : un même code source avec les mêmes inputs doit produire exactement le même artefact, quelles que soient les circonstances. De plus, l'isolation rend extrêmement difficile pour un attaquant d'injecter des dépendances malveillantes ou du code pendant le process de build — une contre-mesure directe aux attaques de type SolarWinds où des builds compromis ont introduit du code malveillant dans les artefacts. Les builds hermétiques sont une exigence du framework SLSA pour atteindre les niveaux de maturité les plus élevés (SLSA Level 3+). Google Bazel est l'outil de build le plus avancé pour garantir l'herméticité : il déclare explicitement toutes les dépendances dans des fichiers BUILD, sandboxe chaque action de build, et peut fonctionner sans accès réseau grâce à des caches de dépendances distantes. La mise en place de builds hermétiques dans des environnements existants nécessite plusieurs transformations. Les dépendances réseau (téléchargements de packages npm, Maven, pip) doivent être remplacées par des sources locales (Artifactory, Nexus, Dependabot lockfiles) ou des mirroirs. Les outils de build doivent être versionés et validés (images Docker de build pinées par SHA). Les variables d'environnement non déterministes (timestamps, PIDs, hostnames) doivent être fixées ou éliminées. Des solutions comme Google Remote Build Execution (RBE), BuildBuddy, et Earthly facilitent la mise en œuvre de builds hermétiques dans les organisations DevSecOps sans adopter Bazel intégralement.

Caractéristiques d'un build hermétique

Un build hermétique garantit : 1) Isolation réseau (aucun téléchargement de dépendance pendant le build — tout est pré-déclaré). 2) Isolation du système de fichiers (accès uniquement aux inputs déclarés). 3) Determinisme (mêmes inputs → même output bit-for-bit). 4) Sandboxing des actions (chaque étape de build s'exécute dans un environnement isolé). 5) Vérification des hashes (toutes les dépendances sont identifiées par leur hash cryptographique, pas par leur version seule).

Bazel et les outils de build hermétiques

Google Bazel est le standard pour les builds hermétiques à grande échelle. Il force la déclaration explicite de toutes les dépendances dans les fichiers BUILD.bazel, sandboxe chaque action via des namespaces Linux, et maintient un cache d'artefacts (local et distant) pour éviter la recalculation d'étapes déjà computées. L'adoption de Bazel est significative mais représente un investissement important. Earthly offre une alternative plus accessible en combinant Docker (isolation) et Makefile (simplicité).

Builds hermétiques et SLSA Level 3

SLSA Level 3 exige un "isolated build" (isolation de l'environnement de build) et un "parameterless build" (le build ne prend pas de paramètres non déclarés). Les Hermetic Builds vont au-delà en garantissant l'absence totale d'influence externe. Les GitHub Actions Reusable Workflows fournis par le projet SLSA garantissent ces propriétés pour les workflows standard. La combinaison build hermétique + attestation de provenance SLSA signée constitue une défense robuste contre les compromissions de pipeline.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis