Comment vérifier qu'un artifact GitHub Actions a été créé par vous, et non par un attaquant

Les attaques de chaîne d'approvisionnement sont passées depuis longtemps de la théorie à la réalité brutale. Imaginons qu'un utilisateur télécharge un binaire pré-construit depuis la section Releases sur GitHub. Comment peut-il vérifier que le fichier a été réellement créé par le serveur CI à partir du code source d'un commit spécifique, et non téléchargé par un hacker ayant accédé au compte du développeur ?

Pour résoudre ce problème, GitHub a lancé une action spéciale actions/attest-build-provenance. Décomposons son fonctionnement, pourquoi les signatures Sigstore sont nécessaires, et pourquoi vous aurez besoin d'un outil légèrement différent lors de la création de nouveaux pipelines.

Où lier la signature

L'essence de la signature de provenance est assez simple. Chaque fichier terminé nécessite un passeport numérique. Ce document confirme : l'artifact avec un hash spécifique a été créé à l'intérieur d'un workflow spécifique, dans un dépôt spécifique, et sur un commit spécifique.

L'outil génère un manifest selon la norme in-toto et la spécification SLSA (Supply-chain Levels for Software Artifacts). Ensuite, la partie la plus intéressante se produit : la signature de ce manifest.

Au lieu de forcer les développeurs à générer des clés PGP à longue durée de vie et à les stocker dans les secrets du dépôt, l'architecture Sigstore est utilisée. L'action demande un jeton OIDC temporaire depuis GitHub Actions et l'échange contre un certificat de signature à courte durée de vie.

Pour les dépôts publics, la signature est générée via le service public Sigstore, et les données à son sujet se retrouvent dans le journal transparent Rekor. Si le dépôt est privé, GitHub utilise sa propre instance Sigstore privée (cette fonctionnalité est disponible sur le plan Enterprise Cloud).

Une petite surprise dans la documentation

Si vous ouvrez le dépôt officiel du projet, vous verrez une note importante juste au début du README.

À partir de la version quatre, actions/attest-build-provenance est devenu un simple wrapper autour de l'action de base actions/attest. Les développeurs GitHub indiquent explicitement : si vous maintenez d'anciens pipelines, vous pouvez laisser tout en l'état. Mais pour les nouveaux projets, vous devriez commencer directement avec actions/attest.

Pourquoi GitHub a-t-il ajouté une couche supplémentaire ? Initialement, l'équipe construisait un outil étroitement spécialisé uniquement pour la provenance de build. Plus tard, le désir de signer non seulement des binaires mais aussi des SBOM (listes de dépendances) ou des résultats de scans de vulnérabilités est né. C'est ainsi que le actions/attest plus universel est apparu, et l'ancienne action a été retirée en tant que synonyme.

À quoi ressemblait la configuration

Dans les anciennes versions de l'action, la logique dans .github/workflows/build.yml était compressée en quelques lignes après l'étape de construction de l'artifact.

Ce qui est important ici sont les permissions id-token: write et attestations: write. Sans la première option, le workflow ne pourra pas obtenir de jeton OIDC pour la signature sans mot de passe via Sigstore, et sans la seconde, il ne téléchargera pas le résultat vers l'API GitHub Attestations.

Comment vérifier l'authenticité de l'artifact

Une fois l'attestation créée et liée au dépôt, n'importe quel utilisateur ou script de vérification peut contrôler le fichier localement. Pour cela, l'utilitaire CLI GitHub officiel est utilisé.

La commande de vérification ressemble à ceci :

gh attestation verify app.sh --owner my-organization

Si le fichier n'a pas changé et a été créé dans l'organisation spécifiée, la CLI affichera des informations sur le commit et le certificat de signature. Cependant, si le fichier a été modifié même minimalement, la vérification échouera avec une erreur.

Cela vaut-il la peine de l'implémenter

Si vous développez une bibliothèque open-source ou un outil CLI, générer des attestations offre aux utilisateurs un moyen simple de vérifier la sécurité de vos versions.

D'un autre côté, si vous avez un petit projet interne sans exigences strictes de sécurité de chaîne d'approvisionnement, ajouter des étapes supplémentaires à votre CI peut être excessif.

Pour les nouveaux workflows, utilisez directement actions/attest au lieu de actions/attest-build-provenance. Les fonctionnalités principales resteront les mêmes, mais vous utiliserez un outil à jour sans wrappers dépréciés.