Résumé

  • GitHub Actions peut démarrer un flux workflow_run lorsqu’un autre flux est demandé ou achevé; GitHub indique que ce flux aval peut obtenir des secrets et des jetons d’écriture indisponibles au flux précédent.
  • Ce passage en aval ne constitue pas un verdict sur l’artefact: la condition sur la conclusion, le filtre de branche, la sélection de l’artefact, le checkout et les privilèges effectifs restent des décisions distinctes.
  • Une affirmation défendable relie le run amont et sa révision, la configuration et les conditions du déclencheur aval, l’artefact et le checkout exacts, le contexte de privilège, la décision aval et une observation bornée de la cible.

Dire qu’un flux de publication « a suivi la validation » peut décrire une architecture, mais non une chaîne de preuve complète. GitHub Actions permet à un flux d’écouter l’événement workflow_run d’un autre flux, au moment où celui-ci est demandé ou terminé. GitHub précise aussi que le flux déclenché peut accéder à des secrets et à des jetons d’écriture, même lorsque le flux précédent ne le pouvait pas. Cette séparation peut être prudente: un travail d’entrée peu privilégié produit un candidat, puis une seconde étape, plus encadrée, décide quoi en faire. Elle crée aussi une frontière de privilège. Un libellé de run amont ne suffit pas à en rendre compte.

Il faut d’abord distinguer l’achèvement de l’acceptation. GitHub documente qu’un run workflow_run s’exécute quelle que soit la conclusion du flux précédent, sauf si le flux aval comporte une condition explicite, par exemple un test de github.event.workflow_run.conclusion == 'success'. Un run amont terminé ne prouve donc ni la réussite des contrôles ni l’évaluation, par le job aval, de la condition attendue. Le nom d’un flux dans un événement n’est ni la révision du fichier qui l’écoute, ni le contenu de l’événement reçu, ni l’expression qui a autorisé l’étape privilégiée.

Les filtres de branche ont la même limite. GitHub précise qu’ils s’appliquent à la branche du flux déclencheur et que les motifs d’inclusion et d’exclusion obéissent à un ordre. Une valeur branches déclarée est une preuve utile d’intention. Elle ne prouve pas qu’un artefact provient du commit attendu, que le checkout aval a résolu la même révision, ni que l’expression « la branche de publication a passé les tests » désigne réellement la référence évaluée. Si cette conclusion doit être revue, il faut conserver ensemble l’identifiant du run amont, l’action d’événement, la branche et le SHA de tête, l’identité du flux et le contexte d’une éventuelle relance.

Vient ensuite l’artefact. La documentation de GitHub illustre qu’un flux aval peut récupérer les artefacts associés au run déclencheur. C’est un chemin d’accès, pas un certificat de qualité. Un artefact peut être correctement attaché à un run tout en étant le mauvais intrant logique pour une action ultérieure. Le flux aval peut choisir un autre nom, télécharger un ensemble plutôt qu’un objet, décompresser dans un environnement différent, utiliser un checkout distinct ou donner l’artefact à une commande que la validation amont n’avait pas envisagée.

Le relevé pertinent n’est pas seulement « artefact disponible »: il associe l’artefact au run amont, à son nom ou identifiant, à sa taille et à son empreinte lorsqu’elles existent, à l’heure de récupération, au ref et SHA résolus du checkout aval, puis au programme qui l’a consommé et aux conditions de traitement.

La référence de GitHub sur l’usage sûr explique pourquoi cette précision est nécessaire. Elle avertit qu’un workflow_run peut devenir dangereux lorsqu’un flux privilégié récupère du contenu de pull request non fiable; les secrets, droits d’écriture et caches partagés peuvent alors amplifier ce que le flux aval accepte. Cet avertissement ne désigne ni dépôt ni artefact concret. Il décrit une structure: « le flux amont a réussi » ne montre pas ce que le flux aval a accepté, ni ce qu’il avait le droit de faire avec cet intrant.

Le déclencheur n’est pas non plus un reçu d’effet sur la cible. Même un artefact correctement sélectionné peut n’être traité que pour inspection. Une commande aval peut être refusée par une autre limite de permission, s’arrêter avant tout appel à la cible, agir sur une autre ressource, ou se terminer alors qu’une observation ultérieure raconte une autre histoire opérationnelle. À l’inverse, une conclusion amont défavorable peut être portée par l’événement tandis qu’une condition aval empêche toute action privilégiée. Événement, condition, traitement de l’artefact, décision de commande et état observé sont des points différents.

Il faut donc un reçu aval borné. Conserver le nom et l’identifiant du flux amont, l’action de l’événement, la branche et le SHA de tête, la conclusion, l’essai ou la relance, et une référence stable à sa définition. Conserver la révision de la définition aval, le sélecteur workflow_run, les filtres de branche et le résultat de la condition qui a permis ou bloqué le job conséquent. Conserver les spécifications de checkout et leurs SHA résolus. Pour chaque artefact utilisé, conserver l’association amont, le nom ou identifiant, l’empreinte disponible, le contexte de récupération et le chemin de traitement. Conserver le contexte effectif des permissions du GITHUB_TOKEN, des secrets et des caches sans exposer de valeur sensible. Enfin, joindre le résultat de l’opération aval à une observation datée de la cible. Les secrets peuvent rester protégés; les jointures, elles, ne se reconstituent pas après coup.

Cette discipline ne prétend pas que le pipeline est « digne de confiance » en bloc. Elle indique ce que l’événement a relié, ce que le flux aval a décidé, ce qu’il a consommé, quel privilège il détenait et ce qui a été observé. Un workflow_run est une frontière de contrôle utile. Ce n’est pas un certificat implicite de l’artefact, de la décision privilégiée et de l’effet qu’il n’a pas enregistrés.

Sources

  1. GitHub Docs — Events that trigger workflows
  2. GitHub Docs — Secure use reference
  3. GitHub Docs — Triggering a workflow