GitHub Enterprise Server 3.20 locks down the software supply chain — once a release is published, it stays published

December 2020. The SolarWinds attack breaches 18,000 organizations through a signed update to the Orion platform — the most expensive supply chain compromise in history. March 2023. 3CX ships a trojanized version of its desktop VoIP client through a corrupted build pipeline. March 2024. A backdoor slipped into xz utils, caught only because a Microsoft engineer noticed 500 ms of unexpected SSH latency, nearly lands in every Linux distribution on the planet.

All three attacks share the same root cause: victims ran a signed artifact from an official distribution channel, and nobody could verify it hadn’t been tampered with after publication.

GitHub Enterprise Server 3.20, released to general availability on March 17, 2026, answers this problem directly. Releases are now immutable. Assets cannot be added, modified, or deleted after publication. The release tag cannot be moved or deleted — and if the release itself is deleted, the tag cannot be reused. Once a release goes out, it is frozen. Permanently.

This is the first time a major software forge has baked release immutability into its platform as a security primitive — not an optional configuration toggle, but a structural guarantee. The message is unambiguous: the supply chain starts in your Git repository, and GitHub intends to control every link in it.

How immutable releases work

The mechanism is straightforward, but its implications run deep. Once immutability is enabled on a repository or at the organization level:

• Release assets — binaries, archives, signatures — are locked. No additions, no modifications, no deletions.
• The associated Git tag is protected from being moved or deleted. If the release is deleted, the tag can be removed but cannot be reused, blocking re-tagging attacks.
• Protection applies to all new releases created after activation. Existing releases remain mutable until republished.
• Disabling immutability does not unlock releases created while it was enabled. The lock is one-way.

On GitHub.com, this mechanism is paired with release attestations in the Sigstore bundle format — cryptographically verifiable signatures that can be checked outside GitHub and integrated into CI/CD pipelines. These attestations are not available on GHES 3.20 — they remain a cloud-only feature — but immutability itself ships on the appliance.

Enabling it is a toggle in the repository or organization security settings. Once flipped, every new release becomes a fixed trust anchor in the software supply chain. That’s precisely what was missing when SolarWinds, 3CX, and xz utils were compromised.

There’s one caveat: releases created before immutability was enabled stay mutable. GitHub does not retroactively lock existing artifacts — teams need to republish their critical historical releases if they want them protected.

Secret scanning gets governance teeth

The second pillar of GHES 3.20 is a revamped secret scanning pipeline that graduates from detection to governance.

Validity checks arrive on GHES. Previously a GitHub.com exclusive, these checks now run on self-hosted appliances. When secret scanning detects a leaked credential, it queries the issuing service — AWS, GitHub, Slack — to determine whether the token is still active. GHES administrators enable the feature from the Management Console; repository admins then toggle it on per-project.

This shifts triage from urgency-by-volume to urgency-by-impact. A Slack webhook that’s been dead for six months doesn’t deserve the same priority as an active AWS IAM key. Validity checks make that distinction programmatically.

Push protection expands. Delegated bypass controls — the mechanism that lets a designated reviewer approve a push despite a secret scanning alert — can now be configured at the enterprise level. No more patchwork repository-level policies: an enterprise owner sets the rule once, and it propagates across the organization.

Alert assignment becomes native. Secret scanning alerts now support an assignee field with dedicated webhooks and REST API endpoints. Triage moves from “everyone or no one” to structured remediation workflows.

New detectors are added and existing ones improved. Default push protection coverage blocks more secret types, catching leaks before they land on the branch.

For organizations on GitHub Advanced Security, the Enterprise Security Manager role enters public preview. A cross-cutting position that manages security policies and views alerts across the entire enterprise — currently capped at 15,000 organizations.

What else matters in this release

GHES 3.20 isn’t just a security drop. Several other changes deserve attention from platform engineers and CISOs:

The integrated backup service hits GA. This built-in alternative to backup-utils (slated for retirement in version 3.22) eliminates the need for a separate host to run backup software. If you’re still on backup-utils, the migration clock is ticking — the deprecation path is already published.

Enterprise teams arrive in public preview. Enterprise owners can create cross-organization teams, assign them custom roles, and add them to ruleset bypass lists. Centralized governance — long absent from GHES — is starting to take shape.

The pull request merge experience gets tighter: it now integrates repository rules, supports one-click draft conversion, surfaces failing optional checks, and allows removal from the merge queue. Status checks are grouped by outcome, with failures surfaced first.

On the GitHub Actions side: reusable workflows can now be nested up to 10 levels (up from 4) and call up to 50 total workflows (up from 20). workflow_dispatch triggers support up to 25 inputs (up from 10). The minimum runner version bumps to 2.330.0.

CodeQL 2.23.9 ships with general availability support for Rust, incremental analysis across all languages, and support for Swift 6.2 and Kotlin 2.2 builds.

Why this matters now

The numbers from Sonatype are stark: supply chain attacks increased by 742% per year between 2019 and 2025. The attack vector is no longer the network perimeter — it’s the toolchain that compiles, signs, and distributes software.

The xz utils incident of March 2024 rewired threat models everywhere. A trusted maintainer, Jia Tan, spent two years building community trust before inserting a backdoor into a component used by systemd and OpenSSH. The attack was stopped because an engineer at Microsoft noticed unusual SSH latency — not by a scanner, not by a security policy, but by human attention to detail. It was the closest the open-source ecosystem has come to a catastrophic compromise since Heartbleed.

Release immutability makes this attack class harder to pull off. If published artifacts can’t be modified after the fact, an attacker must compromise the build itself — a far more expensive and auditable vector. Combine that with secret scanning that catches tokens before they hit the main branch, and the attack surface shrinks further.

GitHub isn’t acting in isolation. SLSA (Supply-chain Levels for Software Artifacts), the framework from Google, has pushed since 2021 for maturity levels that include artifact immutability at level 3. Sigstore, the signing standard backed by the Linux Foundation, is now adopted by npm, PyPI, and Maven Central. GHES 3.20 aligns with this trajectory: supply chain security isn’t a bolt-on — it’s becoming a native platform layer.

The verdict

If you run GHES on-premises and distribute software artifacts — binaries, containers, packages, scripts — enable immutable releases immediately after upgrading to 3.20. There’s zero configuration cost and the protection is irreversible. Republish critical historical releases to lock them retroactively.

If you’re on GitHub Advanced Security, secret scanning with validity checks is your highest-ROI lever. Prioritizing active secrets cuts effective remediation time without additional licensing cost — the feature is included in your existing license. Enable it from the Management Console.

If your enterprise spans more than 50 organizations, deploy enterprise teams and the Enterprise Security Manager role in preview. Fragmented per-repository governance doesn’t scale at that level — these two features lay the foundation for centralized access control.

If you’re still on backup-utils, start planning the migration to the integrated backup service before 3.22 ships. The exact deadline isn’t set, but the retirement path is official. Waiting for the last version to migrate means risking a rollback path that will no longer exist.

GHES 3.20 isn’t a splashy feature release. It’s a foundation release: two structural safeguards — immutable releases and governed secret scanning — that turn the forge into the strongest link in the software chain. In a landscape where SolarWinds cost $100 million and xz nearly compromised half the internet, this isn’t a luxury. It’s the baseline.

References

• GitHub Enterprise Server 3.20 is now generally available, GitHub Changelog, March 17, 2026.
• GitHub Enterprise Server 3.20 release notes, GitHub Docs, accessed March 18, 2026.
• Immutable releases are now generally available, GitHub Changelog, October 28, 2025.
• GitHub Enterprise Server 3.20 release candidate is available, GitHub Changelog, February 24, 2026.
• Secret scanning — GitHub Enterprise Server 3.20 Docs, GitHub Docs.
• The SolarWinds Cyber-Attack: What You Need to Know, CISA, December 2020.
• Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094, CISA, March 29, 2024.
• 3CX DesktopApp Supply Chain Attack, CrowdStrike, March 30, 2023.
• SLSA — Supply-chain Levels for Software Artifacts, Google / OpenSSF.
• 8th Annual State of the Software Supply Chain, Sonatype, 2025.