GitHub Actions : revoir la confiance dans les workflows

Source originale: GitHub Changelog · Date de l’annonce: 2026-11-02

Les faits confirmés

GitHub annonce le blocage par défaut de pull_request_target dans les dépôts publics au 2026-12-02 ; les dépôts privés et internes sont exclus.

Analyse éditoriale

La documentation GitHub explique que cet événement s’exécute dans le contexte du dépôt de base, et que l’exécution de code non fiable peut y exposer des accès sensibles. Selon nous, la réponse appropriée n’est pas simplement d’ajouter une exception pour conserver un CI au vert. Il faut commencer par comprendre le rôle exact de chaque workflow et vérifier si cette tâche a réellement besoin des pouvoirs associés à ce contexte.

Notre recommandation pratique consiste à séparer l’examen du contenu entrant des opérations autorisées à publier. Dans un exemple hypothétique, ajouter une étiquette à une demande de fusion et exécuter un script fourni par cette demande sont des décisions différentes. Le relecteur doit comprendre l’origine du code et la permission utilisée à chaque étape. Il s’agit d’une méthode de revue, pas d’une modification des paramètres du lecteur ni d’une affirmation que tout usage de ce déclencheur est dangereux.

À vérifier avant de décider

• Inventorier les workflows dépendants de l’événement et identifier leur responsable de maintenance.
• Examiner les chemins de récupération du code avec toutes les permissions et tous les secrets accessibles.
• Avant l’échéance annoncée, évaluer la politique par défaut et le besoin réel d’une exception.

En pratique

Les équipes de dépôts privés peuvent aussi profiter de cette annonce pour revoir leurs frontières de confiance, même si ce changement ne les concerne pas. Le bon objectif est de préserver le travail nécessaire avec les droits minimaux requis, sans contourner une protection par habitude.

Référence complémentaire · À lire aussi