Attestations de provenance de build : ce que la provenance SLSA enregistre et comment elle est vérifiée

Ce que c'est

La provenance, dans la spécification SLSA, est une information vérifiable sur la manière dont un artefact a été produit : quelle entité l'a construit, quel processus a été utilisé et quelles étaient les entrées. La piste Build définit des niveaux. Build L1 : la provenance existe, éventuellement non signée ; elle prévient les erreurs mais est « trivial to bypass or forge ». Build L2 : une plateforme de build hébergée génère et signe la provenance, ce qui protège contre les altérations après le build. Build L3 : une plateforme durcie dont les exécutions ne peuvent pas s'influencer entre elles et dont le matériel de signature de la provenance n'est pas accessible aux étapes de build définies par l'utilisateur, ce qui protège contre les altérations pendant le build. Le format recommandé est une attestation in-toto avec un predicateType https://slsa.dev/provenance/v1. Son subject liste les artefacts produits par empreinte. buildDefinition porte le buildType (un modèle identifiant le processus), les externalParameters (les entrées non fiables, qui doivent être enregistrées et vérifiées en aval), des internalParameters optionnels, et resolvedDependencies (ce vers quoi les entrées ont été résolues, par exemple le commit exact vers lequel pointait une URL de dépôt). runDetails nomme le builder.id et des métadonnées d'exécution. La plateforme de build signe l'enveloppe.

Pourquoi c'est important

Un SBOM dit ce qui se trouve à l'intérieur d'un artefact ; la provenance dit qui l'a construit et à partir de quoi. Avec une provenance vérifiée, une personne consommatrice peut rejeter un paquet construit à partir d'un commit absent du dépôt amont, construit par un flux de travail inattendu, ou construit avec des paramètres qui diffèrent du processus de publication documenté. Une provenance non vérifiée n'est que de la documentation.

Comment l'appliquer

• Côté production : construire sur une plateforme qui génère et signe la provenance, publier l'attestation à côté de l'artefact, et garder le processus de build cohérent afin que les personnes consommatrices puissent s'en faire une attente stable.
• Côté consommation : suivre les étapes de la spécification. Vérifier la signature de l'enveloppe face aux racines de confiance configurées (une correspondance entre l'identité du constructeur et le niveau pour lequel elle est fiable) ; vérifier que l'empreinte du subject correspond à l'artefact et que predicateType est bien le type de provenance SLSA ; puis comparer buildType et externalParameters aux valeurs attendues. La spécification indique que des paramètres externes non reconnus doivent faire échouer la vérification.
• Décider de l'action en cas d'échec (bloquer, avertir, journaliser) avant d'activer la vérification, et commencer par des artefacts dont on contrôle les deux extrémités.

Pièges

La provenance L1 est falsifiable ; elle attrape les erreurs, pas les attaquants. Faire confiance à un builder.id sans épingler sa clé ou l'identité de son certificat rend la signature dénuée de sens. La provenance couvre le build, pas la revue du code source ni les builds propres des dépendances ; la vérification récursive optionnelle des dépendances de la spécification et sa piste Source séparée traitent ces aspects.