GitHub Enterprise Server 3.20 verrouille la supply chain — les releases ne bougeront plus après publication

Décembre\u00a02020. SolarWinds subit l’attaque supply chain la plus coûteuse de l’histoire\u00a0: 18\u00a0000 clients compromis via une mise à jour légitime du logiciel Orion. Mars\u00a02023. Le client VoIP 3CX distribue une version trojanisée à ses utilisateurs via un processus de build corrompu. Mars\u00a02024. Un backdoor dans xz utils, découvert par hasard par un développeur Microsoft, frôle l’inclusion dans des millions de systèmes Linux.

Ces trois attaques ont un point commun\u00a0: les victimes exécutaient un artefact signé, distribué par un canal officiel — et personne ne pouvait vérifier qu’il n’avait pas été altéré après publication.

Le 17 mars 2026, GitHub Enterprise Server 3.20 passe en disponibilité générale avec une réponse directe à ce problème. Les releases deviennent immuables par défaut. Les assets ne peuvent plus être modifiés, ajoutés ou supprimés après publication. Le tag ne peut plus être déplacé ni supprimé. Une fois une release publiée, le code distribué est figé — définitivement.

C’est la première fois qu’une forge logicielle majeure intègre l’immuabilité des releases comme primitive de sécurité, et non comme option de configuration. Le signal est clair\u00a0: la supply chain commence dans le dépôt Git, et GitHub entend la contrôler d’un bout à l’autre.

Immutable releases — ce qui change concrètement

Le mécanisme est simple, mais ses implications sont profondes. Quand l’immuabilité est activée sur un dépôt ou une organisation\u00a0:

• Les assets d’une release (binaires, archives, signatures) ne peuvent plus être ajoutés, modifiés ou supprimés après publication.
• Le tag Git associé est protégé contre le déplacement et la suppression. Si la release est supprimée, le tag peut être retiré mais ne peut pas être réutilisé — empêchant une attaque par re-tagging.
• La protection s’applique à toutes les nouvelles releases créées après activation. Les releases existantes restent modifiables tant qu’elles ne sont pas republiées.
• Désactiver l’immuabilité n’affecte pas les releases déjà verrouillées. Le verrou est irréversible.

Sur GitHub.com, ce mécanisme s’accompagne d’attestations de release au format Sigstore — des signatures cryptographiques vérifiables en dehors de GitHub, intégrables dans les pipelines CI/CD. Ces attestations ne sont pas disponibles sur GHES 3.20 — elles restent exclusives à la version cloud — mais l’immuabilité, elle, est bien présente sur l’appliance.

L’activation se fait au niveau du dépôt ou de l’organisation dans les paramètres de sécurité. Une fois activée, chaque release devient un point de confiance fixe dans la chaîne d’approvisionnement — exactement ce qui manquait à SolarWinds, 3CX et xz utils.

Une nuance importante\u00a0: les releases créées avant l’activation de l’immuabilité restent modifiables. GitHub ne verrouille pas rétroactivement l’existant — les équipes doivent republier leurs releases historiques pour les protéger.

Secret scanning — la gouvernance monte d’un cran

Le deuxième pilier de GHES 3.20 est le renforcement du secret scanning, qui passe d’un outil de détection à un outil de gouvernance.

Les validity checks arrivent sur GHES. Jusqu’ici réservés à GitHub.com, ils permettent de vérifier si un secret détecté est encore actif. Le scanner contacte le service émetteur — AWS, GitHub, Slack — pour déterminer si le token a été révoqué ou non. Les administrateurs GHES activent cette fonctionnalité depuis la Management Console, puis les administrateurs de dépôt peuvent l’activer projet par projet.

C’est un changement de paradigme\u00a0: au lieu de traiter chaque alerte avec la même urgence, les équipes priorisent les secrets réellement exploitables. Un token inactif depuis six mois n’a pas le même poids qu’un accès AWS encore valide.

La push protection s’étend. Les contrôles de delegated bypass — qui permettent à un reviewer désigné d’autoriser un push malgré une alerte — sont désormais configurables au niveau entreprise. Fini les politiques fragmentées par dépôt\u00a0: un enterprise owner définit une règle unique, applicable à toute l’organisation.

L’assignation d’alertes devient native. Les alertes de secret scanning supportent un champ assignee, avec des webhooks et des endpoints REST API dédiés. Le tri des alertes sort du duo «\u00a0tout le monde ou personne\u00a0» et entre dans un vrai workflow de remédiation.

De nouveaux détecteurs sont ajoutés et les détecteurs existants sont améliorés. La couverture par défaut de la push protection bloque davantage de types de secrets, réduisant le risque de fuite au moment du git push.

Enfin, pour les organisations utilisant GitHub Advanced Security, le rôle Enterprise Security Manager fait son entrée en public preview. Un poste transversal qui gère les politiques de sécurité et visualise les alertes sur l’ensemble de l’entreprise — jusqu’à 15\u00a0000 organisations.

Le reste de la release — ce qui compte vraiment

GHES 3.20 n’est pas qu’une mise à jour sécurité. Plusieurs autres évolutions méritent l’attention des platform engineers et des RSSI\u00a0:

Le service de backup intégré passe en disponibilité générale. Alternative native à backup-utils (qui sera retiré en version 3.22), ce service ne nécessite plus de machine séparée pour héberger le logiciel de sauvegarde. La bascule est à planifier maintenant — le deprecation path est déjà tracé.

Les enterprise teams arrivent en public preview. Les enterprise owners peuvent créer des équipes transversales, leur attribuer des rôles personnalisés et les assigner à plusieurs organisations. Ces équipes peuvent être ajoutées aux listes de bypass des rulesets. La gouvernance centralisée, longtemps absente de GHES, commence à exister.

L’expérience de merge des pull requests intègre les règles de dépôt et facilite la conversion en draft, la surveillance des checks optionnels en échec et le retrait de la merge queue. Les status checks sont groupés par statut, les échecs remontent en premier.

Côté GitHub Actions\u00a0: les workflows réutilisables peuvent désormais être imbriqués jusqu’à 10 niveaux (contre 4) et appeler jusqu’à 50 workflows au total (contre 20). Les workflow_dispatch supportent jusqu’à 25 inputs (contre 10). Et la version minimale du runner passe à 2.330.0.

CodeQL 2.23.9 est livré avec le support Rust en disponibilité générale, l’analyse incrémentale pour tous les langages, et le support des builds Swift 6.2 et Kotlin 2.2.

Le contexte — pourquoi ça arrive maintenant

Les chiffres de Sonatype sont sans appel\u00a0: les attaques supply chain ont augmenté de 742\u00a0% par an entre 2019 et 2025. Le vecteur n’est plus le périmètre réseau — il est dans la chaîne de compilation, de signature et de distribution du logiciel.

L’attaque xz utils de mars\u00a02024 a changé la perception du risque. Un maintainer de confiance, Jia Tan, a passé deux ans à gagner la confiance de la communauté avant d’insérer un backdoor dans un composant utilisé par systemd et OpenSSH. L’attaque a été découverte parce qu’un ingénieur Microsoft a remarqué une latence anormale de 500\u00a0ms dans ses connexions SSH. Pas par un scanner. Pas par une politique de sécurité. Par un humain attentif.

C’est ce genre de scénario que l’immuabilité des releases rend plus difficile. Si l’artefact publié ne peut plus être modifié, l’attaquant doit compromettre le build lui-même — un vecteur bien plus coûteux et plus facile à auditer. Et si le secret scanning détecte un token avant qu’il n’atteigne la branche principale, la surface d’attaque se réduit encore.

GitHub ne réagit pas seul. SLSA (Supply-chain Levels for Software Artifacts), le framework de Google, pousse depuis 2021 vers des niveaux de maturité incluant l’immuabilité des artefacts (niveau 3). Sigstore, le standard de signature porté par la Linux Foundation, est adopté par npm, PyPI et Maven Central. GHES 3.20 s’inscrit dans ce mouvement de fond\u00a0: la supply chain devient une couche de sécurité native, pas un surcoût optionnel.

Le verdict

Si vous hébergez GHES en on-premises et que vous distribuez des artefacts logiciels — binaires, conteneurs, paquets, scripts — activez les releases immuables immédiatement après la mise à jour vers la 3.20. Le coût de configuration est nul et la protection est irréversible. Republiez vos releases historiques critiques pour les verrouiller rétroactivement.

Si vous utilisez GitHub Advanced Security, le secret scanning avec validity checks est votre levier le plus rentable. Prioriser la remédiation des secrets actifs divise le temps de réponse effectif sans coût de licensing supplémentaire\u00a0: la fonctionnalité est incluse dans la licence existante. Activez-la depuis la Management Console.

Si votre entreprise compte plus de 50 organisations, déployez les enterprise teams et le rôle Enterprise Security Manager en preview. La gouvernance fragmentée par dépôt n’est plus tenable à cette échelle — ces deux fonctionnalités posent les fondations d’un contrôle d’accès centralisé.

Si vous utilisez encore backup-utils, planifiez la migration vers le backup service intégré avant la sortie de la 3.22. La deadline n’est pas encore fixée, mais le chemin de retrait est officiel. Attendre la dernière version pour migrer, c’est jouer avec un rollback path qui n’existera plus.

GHES 3.20 n’est pas une release de fonctionnalités tape-à-l’œil. C’est une release de fondations\u00a0: deux verrous structurels — releases immuables et secret scanning avec gouvernance — qui transforment la forge en maillon fort de la chaîne logicielle. Dans un paysage où SolarWinds a coûté 100 millions de dollars et xz a failli compromettre la moitié d’Internet, ce n’est pas un luxe. C’est le minimum.

Références

• GitHub Enterprise Server 3.20 is now generally available, GitHub Changelog, 17 mars 2026.
• GitHub Enterprise Server 3.20 release notes, GitHub Docs, consulté le 18 mars 2026.
• Immutable releases are now generally available, GitHub Changelog, 28 octobre 2025.
• GitHub Enterprise Server 3.20 release candidate is available, GitHub Changelog, 24 février 2026.
• Secret scanning — GitHub Enterprise Server 3.20 Docs, GitHub Docs.
• The SolarWinds Cyber-Attack: What You Need to Know, CISA, décembre 2020.
• The XZ Utils Backdoor: How It Happened, CISA, 29 mars 2024.
• 3CX DesktopApp Supply Chain Attack, CrowdStrike, 30 mars 2023.
• SLSA — Supply-chain Levels for Software Artifacts, Google / OpenSSF.