Le 22 octobre 2026, Vercel a déclaré la mort des identifiants statiques après un sondage de plus de 1 000 éditeurs SaaS dont seuls 8,4 % supportent une authentification OIDC. Deux échéances s’appliquent au Marketplace, mais le guide officiel de déploiement GitHub Actions de Vercel impose encore un token longue durée.
Le 14 octobre 2026, GitHub a ouvert en aperçu public les lockfiles de workflow : chaque action et workflow réutilisable est épinglé sur un commit précis, de sorte que le code relu est le code exécuté. Activez le verrouillage sur vos dépôts critiques avant qu’un tag déplacé n’introduise du code malveillant dans votre CI.
La campagne GhostAction compromet des comptes mainteneurs pour pousser un faux workflow de « sécurité » qui exfiltre les secrets CI/CD vers une IP contrôlée. Vérifiez vos dépôts pour les fichiers security-audit.yml et github_actions_security.yml, puis révoquez les identifiants concernés.
GitHub retirera l’image de runner macOS 14 le 2 novembre 2026 et fait déjà échouer les jobs qui l’utilisent encore pendant huit fenêtres de brownout réparties sur octobre. Migrez vos workflows vers un label arm64 — macos-15 ou macos-latest — avant la prochaine coupure du 12 octobre.
Le 17 septembre 2026, GitHub annonce que le label ubuntu-latest passe d’Ubuntu 24.04 à 26.04, avec un déploiement progressif entre le 19 octobre et le 19 novembre 2026. La migration embarque un saut de JDK de 17 à 25, des sauts de version majeure pour Docker Compose et Helm, et la suppression d’une douzaine d’outils préinstallés : les workflows qui ne pinent pas leur runtime vont casser.
Les actions actions-cool/issues-helper et maintain-one-comment, compromises le 18 mai 2026 dans la campagne Mini Shai-Hulud, ont été réactivées le 16 septembre avec des tags pointant toujours vers le code malveillant, selon Socket. La leçon est brutale : en CI/CD, un tag mutable est une porte laissée ouverte.
GitHub a durci l’application de la version minimale des runners auto-hébergés : des brownouts ont commencé le 14 septembre et, à partir du 25 septembre 2026, tout runner non mis à jour sous 30 jours ne reçoit plus aucun job. L’échec est silencieux — les jobs restent « Queued » sans erreur : auditez vos runners avant la prochaine fenêtre.
Le 3 septembre 2026, GitHub a livré trois mises à jour de GitHub Actions : une permission vulnérabilités pour GITHUB_TOKEN, le contexte job des workflows réutilisables et une API de dépréciation des runners. Remplacez vos portées larges par la permission vulnérabilités et adoptez job.workflow_ref dans vos workflows réutilisables.
Face aux détournements de tags qui ont frappé tj-actions et 23 000 dépôts, GitHub déploie une feuille de route de sécurité pour Actions : lockfiles de dépendances, secrets scopés et pare-feu d’égression. Deux mesures sont déjà disponibles : l’épinglage par SHA et l’OIDC.
À partir du 1er octobre 2026, GitHub applique à la rétention des checks, des workflow runs et des statuses le même réglage que celui des artefacts et des logs, soit 90 jours par défaut au lieu de plus de 400. Les équipes qui s’appuient sur cet historique doivent vérifier leur réglage et exporter ce qu’elles veulent conserver.
Début août 2026, GitHub a livré une permission « vulnerability-alerts: read » qui autorise le jeton de CI à consulter les alertes Dependabot sans recourir à un PAT surdimensionné. Les workflows qui automatisent la remédiation des vulnérabilités peuvent enfin appliquer le moindre privilège jusqu’au bout.
Docker Hub supporte désormais les connexions OIDC pour GitHub Actions. Les workflows s’authentifient avec des tokens éphémères par exécution au lieu de stocker des PAT ou OAT dans les secrets GitHub. La rotation manuelle des credentials appartient au passé.
Depuis le 1er août 2026, GitHub génère automatiquement des attestations de build SLSA Niveau 3 pour chaque workflow Actions exécuté sur un dépôt public. La supply chain logicielle devient vérifiable sans effort — et la conformité réglementaire suit.
Les images de runner custom passent en disponibilité générale le 26 mars 2026 après six mois de preview publique. Plus rapides et préconfigurées, elles éliminent le setup à chaque job — mais transfèrent la maintenance, la sécurité et le versioning aux équipes.
