Trusted Builder
devsecopsDéfinition
Un Trusted Builder est un système de build isolé, contrôlé et auditable dont la provenance et l'intégrité sont vérifiables cryptographiquement, permettant aux consommateurs d'artefacts de faire confiance non seulement au contenu de l'artefact mais aussi au processus qui l'a produit. Le concept de Trusted Builder est central dans le framework SLSA (Supply-chain Levels for Software Artifacts) où il représente l'infrastructure de build dont l'identité et les actions peuvent être attestées. La confiance dans un builder repose sur plusieurs piliers. L'isolation : le builder s'exécute dans un environnement hermétique sans accès à des ressources non déclarées, empêchant l'injection de dépendances non contrôlées pendant le build. L'identité vérifiable : le builder possède une identité cryptographique (clé privée HSM, OIDC token) permettant de signer les attestations de provenance en son nom, de manière vérifiable par des tiers. L'auditabilité : toutes les actions du builder sont journalisées de manière immuable, permettant la reconstruction du processus de build a posteriori. Dans la pratique GitHub Actions, les "Reusable Workflows" hébergés dans des dépôts officiels (github.com/slsa-framework/slsa-github-generator) constituent des Trusted Builders au sens SLSA : leur code est public, auditable, et leur exécution génère des attestations signées par l'identité GitHub Actions du dépôt officiel. Ces attestations peuvent être vérifiées par quiconque disposant de la clé publique GitHub Actions, indépendamment de qui déclenche le workflow. Les implémentations de Trusted Builders incluent les Sigstore Builders (GitHub, GitLab, et autres), les Secure Build Services proposés par des fournisseurs comme Google Cloud Build (avec attestations SLSA natives) et BuildBuddy (pour Bazel). Dans Kubernetes, les Tekton Chains constituent une solution de Trusted Builder native cloud-native.
Propriétés d'un Trusted Builder selon SLSA
SLSA définit les Trusted Builders selon leurs propriétés : L1 = génère de la provenance (non signée), L2 = génère de la provenance signée par le builder, L3 = builder hermétique avec provenance signée et environnement isolé, L4 = builder bi-party verified (deux entités indépendantes valident le build). En pratique, les GitHub Actions Reusable Workflows officiels SLSA constituent des Trusted Builders L3 pour les projets hébergés sur GitHub.
GitHub Actions Trusted Builder en pratique
L'utilisation du SLSA GitHub Generator comme Trusted Builder : le projet cible appelle le reusable workflow slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml depuis son propre workflow. Ce workflow construit l'artefact dans un environnement isolé, génère l'attestation SLSA L3, et la signe via Sigstore. Le consommateur vérifie avec slsa-verifier verify-artifact --source-uri github.com/owner/repo --builder-id github.com/slsa-framework/slsa-github-generator.
Tekton Chains : Trusted Builder Kubernetes natif
Tekton Chains est un contrôleur Kubernetes qui observe les TaskRuns Tekton et génère automatiquement des attestations cryptographiques (format in-toto SLSA) après chaque exécution réussie. Ces attestations sont signées et poussées dans un registre OCI ou un système de stockage d'attestations (Rekor). Tekton Chains transforme n'importe quel pipeline Tekton en Trusted Builder avec un effort de configuration minimal, sans modification du code des pipelines existants.
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.