Secure Build Environment
devsecopsDéfinition
Un Secure Build Environment (environnement de build sécurisé) est une infrastructure de compilation et d'assemblage de logiciels configurée pour minimiser les risques de compromission du processus de build lui-même, garantissant que les artefacts produits correspondent exactement au code source voulu sans injection de code malveillant pendant la phase de build. C'est un composant fondamental du framework SLSA pour atteindre les niveaux L3 et L4 de garanties de supply chain. Les risques de sécurité spécifiques aux environnements de build incluent : la compromission du build server (si l'infrastructure CI est compromise, tous les artefacts buildés depuis cette date peuvent être malveillants), les dépendances de build malveillantes (outils de build, compilateurs, images de base des containers CI), l'injection de code pendant le build (via des scripts de post-installation de paquets, des hooks Maven/npm/pip), et les builds avec des dépendances non déclarées (connexions réseau à des ressources externes pendant le build qui ne sont pas dans le Gemfile/package.json). Un Secure Build Environment hermétique élimine la majorité de ces risques par design : un build hermétique n'a pas accès à Internet pendant l'exécution (toutes les dépendances sont préchargées dans un cache interne, aucune connexion externe n'est permise), utilise un worker éphémère pour chaque build (le worker est créé depuis une image connue et détruit après le build — pas de persistance d'état entre builds), et toutes les dépendances du build (bibliothèques, outils, compilateur) sont fixées à des versions et hashes spécifiques. Les implémentations d'environnements de build sécurisés incluent : Google Cloud Build (build hermétique natif avec isolation réseau), les GitHub Actions Runner avec les paramètres de hardening de StepSecurity, Tekton (pipeline Kubernetes natif avec isolation réseau configurable), et Bazel (outil de build hermétique de Google supportant des builds reproductibles et hermétiques par design).
Builds hermétiques : isolation réseau des workers
L'isolation réseau est la caractéristique centrale d'un build hermétique : pendant l'exécution du build, le worker n'a pas accès à Internet. Toutes les dépendances (packages npm, modules Go, JARs Maven) sont pré-téléchargées dans un cache interne (Nexus, Artifactory, ou un cache spécifique CI) avant le début du build, et le worker est démarré avec des règles réseau bloquant toute connexion externe. Si le build tente de télécharger une dépendance non prévue pendant l'exécution, il échoue — révélant une dépendance non déclarée potentiellement malveillante.
Hardening des GitHub Actions Runners
StepSecurity Harden-Runner est une GitHub Action qui hardene les runners GitHub Actions : il monitor et contrôle le trafic réseau des workflows (alertant ou bloquant les connexions vers des destinations non autorisées), audit les fichiers accédés pendant le build, et génère un profil de comportement baseline. L'utilisation de Harden-Runner avec --egress-policy=block (mode restrictif) bloque toute connexion réseau non autorisée, transformant un runner GitHub Actions standard en environnement de build proche de l'hermétique. L'adoption de ce level de contrôle est une étape vers la certification SLSA L3.
Workers éphémères et builds reproductibles
Les workers éphémères garantissent l'isolation des builds : chaque build démarre depuis une image de base connue (pinée par hash), s'exécute dans un container isolé, et le container est détruit après le build. Il ne peut pas y avoir d'état persistant entre les builds (un attaquant ne peut pas compromettre un worker pour que tous les builds suivants soient malveillants). Combinés avec les builds reproductibles (même code source + même build environment = même binaire bit-à-bit), les workers éphémères permettent une vérification indépendante des binaires publiés, éliminant les risques de backdoor dans le système de build.
Ce terme vous interpelle ?
Nos experts interviennent sur toutes les thématiques de ce glossaire — pentest, conformité NIS 2 / ISO 27001, forensics, sécurité IA. Réponse sous 24h, devis gratuit et sans engagement.