Résumé

  • Une attestation GitHub cryptographiquement valide rattache le condensat d’un artefact à une provenance de build enregistrée ; elle ne certifie pas que l’artefact est sûr.
  • Le contrôle décisif appartient au consommateur, qui doit refuser le déploiement dès que le dépôt, l’identité immuable du workflow, le commit ou la version, l’environnement ou la frontière de confiance du runner sortent de la politique.
  • Pour les dépôts privés, l’absence du journal public de transparence utilisé par les dépôts publics modifie l’observabilité, sans démontrer à elle seule une faiblesse.

Une preuve valide peut conduire à un refus

Le cas révélateur n’est pas celui d’une signature invalide. C’est celui d’une image de conteneur dont la signature et le condensat sont parfaitement vérifiés, mais que la porte de déploiement refuse malgré tout. Le relevé peut désigner un dépôt inattendu, un workflow réutilisable appelé par une étiquette modifiable, un commit extérieur à la ligne de publication autorisée, un environnement non approuvé ou un runner exclu de la frontière de confiance.

Le refus ne contredit pas l’attestation. Il lui donne sa fonction opérationnelle.

GitHub présente les attestations d’artefacts comme des déclarations signées établissant la provenance d’un build. Elles peuvent consigner le workflow associé, le dépôt, l’organisation, l’environnement, le SHA du commit et l’événement déclencheur. Des éléments supplémentaires proviennent de l’identité OpenID Connect mobilisée pour établir cette provenance.

Dans un workflow, la provenance est générée après la construction. Les autorisations nécessaires couvrent notamment le jeton d’identité et l’écriture de l’attestation. Pour un binaire, le sujet peut être le fichier produit ; pour une image de conteneur, le nom complet et le condensat rattachent la déclaration à un contenu déterminé plutôt qu’à une simple étiquette susceptible de changer. Le consommateur dispose ainsi d’un lien vérifiable entre l’artefact présenté et le chemin de fabrication déclaré.

Ce lien reste limité. Il ne démontre ni l’innocuité du code source, ni la qualité des dépendances, ni la pertinence des instructions du workflow. Il ne prouve pas non plus qu’une machine d’exécution est restée intègre. Il répond à la question « quel chemin déclaré a produit ce contenu ? », pas à la question plus vaste « ce contenu peut-il être exécuté sans danger ? ».

GitHub formule elle-même cette limite : produire une attestation sans la vérifier n’apporte aucun bénéfice de sécurité, et l’attestation ne garantit pas la sûreté de l’artefact. Le consommateur doit définir ses critères, examiner le contenu de la preuve et prendre une décision de risque. Une validation cryptographique qui s’arrête à l’authenticité de la signature est donc incomplète.

La politique transforme la provenance en décision

Le premier critère concerne généralement le dépôt et l’organisation attendus. Mais accepter n’importe quel workflow de cette organisation serait trop large. Deux workflows valides peuvent appliquer des contrôles radicalement différents. L’un peut constituer la voie de publication centralisée et révisée ; l’autre n’être qu’une automatisation disposant des autorisations de signature.

L’identité immuable du workflow devient alors essentielle. GitHub considère le SHA complet d’un commit comme la référence la plus sûre pour appeler un workflow réutilisable externe. Une branche avance ; une étiquette peut être déplacée. Une attestation peut donc décrire fidèlement un chemin dont les instructions sous-jacentes ne correspondent plus à la version examinée. Une politique qui ne vérifie que le nom du workflow laisse cette variation hors du contrôle d’admission.

Le commit, l’événement déclencheur et l’environnement réduisent encore l’espace acceptable. Une organisation peut exiger un commit de version approuvé, plutôt que n’importe quel commit du bon dépôt. Elle peut distinguer une publication issue d’un environnement gouverné d’un build ordinaire. Ce ne sont pas des garanties ajoutées automatiquement par la signature : ce sont des conditions choisies par le consommateur.

La confiance accordée au runner forme une autre dimension. GitHub avertit que les runners auto-hébergés ne sont pas assurés d’être des machines éphémères et propres ; du code non fiable peut les compromettre durablement. Une attestation valide ne démontre donc pas que le runner était intact. La provenance renseigne l’identité enregistrée du build, tandis que la politique doit décider séparément quels environnements d’exécution sont admissibles.

Du constat cryptographique à la porte d’entrée

GitHub documente une mise en œuvre Kubernetes reposant sur le Sigstore Policy Controller, une racine de confiance GitHub et une politique d’image du cluster. Après activation dans les espaces de noms sélectionnés, le contrôleur vérifie les attestations avant l’admission des images et peut refuser celles qui ne satisfont pas la politique.

L’installation du contrôleur ne suffit toutefois pas : sans politique configurée et activée dans le bon espace de noms, il n’y a pas d’application effective. Les règles de correspondance des images et les exemptions déterminent également la surface contrôlée. Dire qu’une entreprise « utilise les attestations » ne renseigne donc pas sur ce que ses déploiements acceptent réellement.

L’observabilité varie aussi selon la visibilité du dépôt. Les attestations publiques s’appuient sur l’instance publique de Sigstore et sont inscrites dans un journal de transparence publiquement consultable. Les dépôts privés utilisent l’instance Sigstore de GitHub, fondée sur le même code, mais sans journal public et avec une fédération limitée à GitHub Actions. Cela réduit l’observation publique indépendante ; cela ne suffit pas à conclure que le mécanisme privé est faible.

Les sources de GitHub ne donnent ni taux d’adoption global, ni fréquence de refus, ni taux de fausse acceptation. Elles ne permettent pas davantage d’affirmer qu’un runner particulier n’a pas été compromis. Ces limites doivent rester visibles.

La conclusion pratique est celle d’un contrôle d’admission : exiger le dépôt attendu, une identité immuable du workflow, la condition de commit ou de version approuvée, l’environnement prévu et une frontière de confiance acceptable pour le runner. Si l’un de ces éléments diffère, refuser le déploiement et conserver un reçu indiquant précisément la condition rejetée.

Sources