GitHub Launches Immutable Releases: New Era of Supply Chain Security

Hello HaWkers, GitHub has just launched one of the most important security features in recent years: immutable releases, now available to everyone as of October 28, 2025.

This functionality protects assets and tags from tampering after publication, ensuring that the software you publish - and your users consume - remains secure and trustworthy. But what does this mean in practice?

The Problem Immutable Releases Solve

Before understanding the solution, we need to understand the critical security problem that exists in the software ecosystem:

Software Supply Chain Attacks

In recent years, software supply chain attacks have become one of the biggest security threats:

Real Examples:

• Modification of releases after publication
• Replacement of binaries with malicious versions
• Git tags moved to different commits
• Tampered assets without leaving traces
• "Trojanized" versions of popular libraries

Alarming Statistics:

• 742% increase in supply chain attacks (2020-2023)
• 62% of companies suffered some related incident
• Average cost of $4.3 million per incident
• Average detection time: 287 days

🔥 Context: A single compromised package can affect millions of applications that depend on it, creating a devastating cascade effect.

The Technical Problem

Before immutable releases, it was possible to:

Risk Scenarios:

1. Modify assets: An attacker with access could replace a .zip or binary
2. Move tags: Git tags could point to different commits
3. Add malware: Add malicious files to an existing release
4. No audit: Difficult to detect when changes occurred
5. Zero trust: Impossible to guarantee integrity without manual checks

How Immutable Releases Work

GitHub implemented three main components:

1. Immutable Assets

Once published as immutable, the release cannot be modified:

Protections:

• Assets cannot be added after publication
• Existing assets cannot be modified
• Assets cannot be deleted
• Release metadata is locked

In Practice:

# Attempt to modify asset in immutable release
gh release upload v1.0.0 new-binary.zip
# Error: Cannot modify immutable release v1.0.0

# Attempt to delete asset
gh release delete-asset v1.0.0 binary.zip
# Error: Cannot delete asset from immutable release

2. Tag Protection

Tags associated with immutable releases are protected:

Guarantees:

• Tag cannot be deleted
• Tag cannot be moved to another commit
• Maintains permanent reference to exact code

Example:

# Immutable release tag
git tag -d v1.0.0
# Error: tag 'v1.0.0' is protected by immutable release

# Attempt to move tag
git tag -f v1.0.0 abc123
# Error: Cannot move tag associated with immutable release

3. Attestations

Immutable releases receive signed attestations:

How It Works:

• GitHub generates a cryptographic signature of the release
• Uses Sigstore bundle format (industry standard)
• Allows verification of authenticity and integrity
• Compatible with existing CI/CD tools

Verification:

# Verify attestation using GitHub CLI
gh attestation verify v1.0.0 \
  --owner myorg \
  --repo myrepo

# Verify using Sigstore tooling
cosign verify-blob \
  --bundle attestation.json \
  --certificate-identity "https://github.com/myorg/myrepo" \
  binary.zip

# Output shows:
# ✓ Signature verified
# ✓ Certificate identity matches
# ✓ Timestamp valid
# ✓ Release is immutable

Enabling Immutable Releases

Configuration is simple and can be done at different levels:

Repository Level

# Settings > Code security and analysis > Immutable releases
- Navigate to repository settings
- Enable "Immutable releases"
- All new releases become immutable automatically

Behavior:

• New releases are immutable by default
• Old releases remain mutable (until republished)
• Disabling does not affect already immutable releases

Organization Level

To apply to all repositories:

# Organization Settings > Code security > Immutable releases
- Navigate to organization settings
- Enable for all repositories
- Optionally: allow repositories to override

Advantages:

• Centralized security policy
• Ensures consistency across all projects
• Reduces human error

CI/CD Integration

Example GitHub Actions workflow:

name: Immutable Release
on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      attestations: write

    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: |
          make build
          tar -czf release.tar.gz dist/

      - name: Create Immutable Release
        uses: actions/create-release@v1
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          draft: false
          immutable: true  # Release will be immutable

      - name: Upload Assets
        uses: actions/upload-release-asset@v1
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: ./release.tar.gz

      - name: Generate Attestation
        uses: actions/attest-build-provenance@v1
        with:
          subject-path: './release.tar.gz'

Benefits For Different Audiences

For Open Source Maintainers

Advantages:

• Protection against compromised account
• Users can trust that releases don't change
• Reduces liability in case of attack
• Demonstrates commitment to security

Use Case:

## Security of Our Releases

All releases of this project are immutable:
- ✓ Assets cannot be modified after publication
- ✓ Tags are protected against alteration
- ✓ Verifiable attestations for each release
- ✓ Compliance with supply chain security best practices

Verify any release:
`gh attestation verify <version> --owner <org> --repo <repo>`

For Companies and Security Teams

Compliance:

• Meets SLSA (Supply chain Levels for Software Artifacts) requirements
• Facilitates security audits
• Reduces attack surface
• Allows complete provenance tracking

Security Policies:

Requirement	Without Immutability	With Immutability
Integrity verification	Manual, complex	Automatic
Change audit	Hard to track	Impossible to change
SLSA compliance	Level 1-2	Level 3+
Release trust	Low	High
Incident response	Reactive	Preventive

For Consumer Developers

Trust:

• Know that code hasn't been altered since publication
• Cryptographic verification of authenticity
• Protection against man-in-the-middle
• Build reproducibility

Simple Verification:

# Before using a dependency, verify
gh attestation verify v2.1.0 \
  --owner popular-lib \
  --repo awesome-package

# If verified, you have guarantees:
# 1. Assets haven't been modified
# 2. Tag points to original commit
# 3. Release was published by legitimate maintainer
# 4. Provenance is documented

Comparison: Before vs After

Attack Scenario: Compromised Account

Without Immutable Releases:

1. Attacker gains access to maintainer account
2. Modifies assets of popular release v1.0.0
3. Replaces binary with backdoored version
4. Thousands of users download compromised version
5. Attack goes undetected for weeks
6. Massive damage to ecosystem

With Immutable Releases:

1. Attacker gains access to maintainer account
2. Attempts to modify release v1.0.0
3. GitHub blocks: "Cannot modify immutable release"
4. Attacker tries to create new malicious release
5. Users verify attestation
6. Attestation fails: invalid signature
7. Attack is immediately detected and blocked

Integration with Sigstore

One of the most powerful aspects is compatibility with Sigstore:

What is Sigstore?

Sigstore is an open source standard for software signing and verification:

Components:

• Cosign: signing tool
• Rekor: transparency log
• Fulcio: certificate authority

Why It Matters:

• Industry standard
• Adopted by Kubernetes, npm, PyPI, etc.
• GitHub-independent verification
• Publicly auditable

Offline Verification

You don't need to trust only GitHub:

# Download attestation bundle
gh attestation download v1.0.0 \
  --owner myorg \
  --repo myrepo \
  --output attestation.json

# Verify locally using cosign
cosign verify-blob \
  --bundle attestation.json \
  --certificate-identity-regexp ".*github.com/myorg/myrepo.*" \
  myapp.tar.gz

# Check public Rekor log
rekor-cli search \
  --artifact myapp.tar.gz

Adoption and Best Practices

Migration Strategy

For Existing Projects:

Phase 1: Preparation (Weeks 1-2)

• Document current release process
• Identify dependencies and integrations
• Communicate changes to users

Phase 2: Testing (Weeks 3-4)

• Enable in test repository
• Validate release process
• Test attestation verification

Phase 3: Rollout (Weeks 5-6)

• Enable in production repositories
• Next release will be immutable
• Update documentation

Phase 4: Evangelization (Ongoing)

• Teach users to verify releases
• Promote practice adoption
• Share successes

Implementation Checklist

Before enabling immutable releases:

Prerequisites:

• Team understands what immutability is
• Release process is documented
• CI/CD supports attestations
• Communication plan is ready
• Rollback strategy is defined

Post-enablement:

• First immutable release published successfully
• Attestation can be verified
• Documentation updated
• Users know how to verify
• Monitoring is working

Limitations and Considerations

What Immutable Releases DON'T Do

It's important to understand the limits:

Doesn't Protect:

• Malicious code in original commit
• Undiscovered vulnerabilities
• Compromised dependencies
• Stolen signing keys

Requires:

• Development security practices
• Rigorous code review
• Dependency analysis
• Credential rotation

When NOT to Use

Situations where immutability may not be ideal:

• Releases under active development (use drafts)
• Internal projects without security requirements
• Prototypes and experiments
• Cases where releases need quick fixes

Alternative: Create new corrected release instead of modifying existing one.

The Future of Supply Chain Security

Immutable releases are part of a larger trend:

Related Initiatives

SLSA (Supply chain Levels for Software Artifacts):

• Security framework developed by Google
• Defines maturity levels (1-4)
• Immutable releases help achieve level 3+

SBOM (Software Bill of Materials):

• Complete documentation of components
• GitHub is integrating with releases
• Total dependency transparency

Automated Verification:

• Tools automatically verify attestations
• Integration in package managers
• Blocking unverified packages

Conclusion

GitHub's launch of immutable releases marks a significant evolution in software security. It's not just a new feature, but a fundamental change in how we think about software distribution.

For project maintainers, especially open source, enabling immutable releases is one of the simplest and most effective ways to protect your users. For companies, it's an essential step toward a more secure and auditable supply chain.

The best part? Implementation is simple, cost is zero, and benefits are immense. With supply chain attacks growing exponentially, adopting preventive measures is no longer optional - it's essential.

If you want to understand more about how large companies are dealing with security at scale, I recommend checking out another article: Cloudflare Rewrites Main System in Rust where you'll discover how security and performance can go hand in hand.

Let's go! 🦅