Build Provenance

Définition

La Build Provenance (provenance du build) est l'ensemble des métadonnées documentant de manière vérifiable le processus de construction d'un artefact logiciel : quel code source a été utilisé (commit hash, dépôt, branche), sur quel système de build (runner, image de build), avec quels outils (compilateurs, dépendances de build), à quel moment, et selon quelles étapes. Ces métadonnées constituent la traçabilité cryptographique de l'artefact, permettant d'établir une chaîne de confiance depuis le code source jusqu'au binaire déployé. La Build Provenance est un concept central du framework SLSA (Supply-chain Levels for Software Artifacts). SLSA définit quatre niveaux de maturité de la provenance, de L1 (provenance générée mais non signée) à L4 (build hermétique, bi-party review, provenance scellée). En pratique, la plupart des organisations visent SLSA L2 ou L3 comme objectif réaliste, combinant génération automatique de la provenance et signature cryptographique par le système de build. Les informations typiques incluses dans une Build Provenance sont : les matériaux d'entrée (buildDefinition.resolvedDependencies contenant les hashes des dépendances de build), l'identité du builder (builder.id comme URI identifiant le système de build, ex : "https://github.com/actions/runner@v2"), les étapes de build exécutées (buildDefinition.buildConfig.steps), les paramètres (inputs), les métadonnées d'invocation (timestamp, runId), et le hash SHA-256 de l'artefact produit (subject.digest). La génération de Build Provenance peut être intégrée dans les pipelines CI existants via des extensions et plugins : les Attestation Actions GitHub, les extension BuildKit pour Docker, et les outils SLSA comme slsa-github-generator (Google) automatisent la génération et la signature de la provenance SLSA via Sigstore/Rekor. Les artefacts et leur provenance associée sont stockés ensemble dans des registres OCI-compatibles. La vérification de la provenance par les consommateurs (avant déploiement en production) utilise des outils comme cosign verify-attestation, slsa-verifier verify-image, ou des admission controllers Kubernetes configurés pour rejeter les déploiements d'artefacts sans provenance SLSA valide.