Immutable Releases Are Now Generally Available ![rw-book-cover](https://github.blog/wp-content/uploads/2025/10/506112189-347686ae-da68-4633-a150-7c6aca59bd21.jpg) ## Metadata - Author: [[The GitHub Blog]] - Full Title: Immutable Releases Are Now Generally Available - Category: #articles - Document Note: --- tags: [GitHub, Supply Chain Security, Sigstore] author: The GitHub Blog source: GitHub Blog reference: [https://github.blog/changelog/2025-10-28-immutable-releases-are-now-generally-available/] date created: 2025-10-31 00:00 --- # 🏷️ Title: Immutable releases are now generally available ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: GitHub made “immutable releases” GA: assets and tags are locked after publication, and releases get signed attestations. - Why it matters: Mitigates tampering and strengthens software supply chain trust. - Key stakeholders: Maintainers, consumers, security teams, CI/CD operators. - Risks and tradeoffs: Less flexibility to fix release assets; requires process updates for republishing and verification. - Bottom line: Enable immutability org/repo-wide to lock new releases and use attestations (Sigstore) to verify provenance. ## 📖 Main Content - Core: “assets can’t be added, modified, or deleted,” tags are protected, and releases include signed attestations for authenticity checks in and outside GitHub. - Context/terms: - Immutable release: a published release whose artifacts and tag are locked. - Attestation: a signed statement (Sigstore bundle) about artifacts’ integrity/provenance. - Sigstore: open standard for keyless signing and verification. - Uncertainties: Migration patterns for existing mutable releases; org policy combinations with branch protection and provenance requirements. ### 🗒️ Notes - “GitHub releases now support immutability... assets and tags are protected from tampering after publication.” - Features: - Immutable assets: no add/modify/delete post-publish. - Tag protection: tag cannot be deleted or moved. - Release attestations: signed using Sigstore bundle; verifiable via GitHub CLI or Sigstore-compatible tools. - Enable at repo or org level; affects new releases; existing remain mutable unless republished. - Disabling later does not retroactively unfreeze already-immutable releases. - Verification integrates into CI/CD policy enforcement. ## 📚 References - [Immutable releases documentation](https://docs.github.com/releases/working-with-releases/immutable-releases) - [Verify the integrity of a release](https://docs.github.com/releases/working-with-releases/verifying-the-integrity-of-a-release) - [Sigstore bundle format](https://docs.sigstore.dev/concepts/architecture/#bundle) - [GitHub CLI](https://cli.github.com/) - [GitHub Community discussion](https://github.community/) ## 🗣️ Paraphrase - Paragraph A: GitHub added a mode where release assets and tags are locked after publishing, preventing tampering. - Paragraph B: Each immutable release includes a Sigstore attestation that can be verified with GitHub CLI or other Sigstore tools, enabling automated policy checks. ## 📰 Newsletter - GitHub shipped immutable releases: lock assets/tags and ship attestations to harden your supply chain. Verify with Sigstore and integrate checks into CI. - Try: enable immutability at org level, add verification to pipelines, and publish SBOMs alongside releases. - Helpful links: GitHub’s [immutable releases docs](https://docs.github.com/releases/working-with-releases/immutable-releases), [integrity verification guide](https://docs.github.com/releases/working-with-releases/verifying-the-integrity-of-a-release), and [Sigstore overview](https://docs.sigstore.dev/). ## ✅ Action Items #### DevRel - Publish demo: enabling immutability + verifying with GH CLI and Sigstore. - Add docs/tutorials and quickstarts; sample policy files for CI. - Collect feedback on migration from mutable to immutable workflows. #### OSPO - Update release governance to mandate immutability for GA builds. - Add attestation verification to release checklists; training cadence quarterly. - Track SBOM/attestation presence in inventory; set freshness SLOs. #### Community - Run maintainer clinics on republishing strategy and provenance. - Create contributor guides: how to verify releases locally. - Sponsors: fund verification tooling and education. #### WordPress - Core: pilot immutable tags for milestone releases; define rollback plan. - Security: enforce Sigstore verification in build pipelines. - Documentation: add examples-first guidance for plugin/theme authors. #### The WPCC - Programs: microgrants for adding verification to popular plugins. - Projects: provenance scorecards; public dashboards. - Funding experiments: match grants tied to adoption milestones. ### FAIR - Technical independence: allow offline verification of attestations and artifacts. - Policies: transparent funding for ecosystem verification tools. - Governance artifacts: standard release/verification charters. ## 🧪 Hypotheses - Enabling immutability reduces post-release asset tampering incidents by ≥90%. - Projects with mandatory attestation checks see fewer supply chain alerts. - Organization-level immutability increases consumer trust/usage of latest releases. ### 📊 Methodology - Compare tampering/security incident rates before/after enablement across repos. - A/B orgs with and without enforced verification in CI. - Survey consumer trust; measure download adoption curves. ### ❓ Questions - How should projects handle hotfixes if assets are immutable? - What’s the recommended rollback pattern when a bad release ships? - How to attest multi-asset, multi-arch releases consistently? ### 🔮 Future Research - Standardized policies for provenance + SBOM co-publication. - Cross-ecosystem verification UX (package managers, OS distros). - Attestation chaining from build to deploy. ### 💡 Implications - Practice: treat publishing as append-only; automate verification steps. - Policy: require attestations for critical software intake. - Education: train maintainers on republishing vs. editing releases. ### 🧠 Learning Styles Assessment - Reading level: Flesch-Kincaid Grade ≈ 9–10. #### 👀 Visual learners - Present: screenshots implied. - Improve: end-to-end diagram of signing/verification flow. #### 🔊 Aural learners - Improve: short audio/TTS summary. #### 🗣️ Verbal learners - Present: clear definitions of immutability and attestations. - Improve: glossary comparing signatures vs. attestations. #### 🧩 Kinesthetic learners - Improve: step-by-step lab with CLI commands. #### 🧠 Logical learners - Present: cause-effect (immutability → fewer tampering vectors). - Improve: decision tree for republish/rollback paths. #### 🧑‍🤝‍🧑 Social learners - Improve: moderated Q&A and office hours. #### 🧘‍♀️ Solitary learners - Improve: self-check quiz on verification steps. #### 🌿 Naturalistic learners - Improve: lifecycle view of provenance from build to consumption. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: standard headings. - Improve: alt text for images illustrating settings. #### Keyboard navigation - Improve: ensure focus order in docs examples. #### Contrast and readability - Present: generally sufficient. - Improve: verify 4.5:1 in images. #### Text resizing and reflow - Present: responsive docs. - Improve: prefers-reduced-motion guidance. #### Media and captions - Improve: add captions for any demo videos. #### Forms and interactions - Improve: inline validation in examples. #### Standards reference - Map to WCAG 2.2 AA where applicable. ### 🌍 DEIB Assessment #### Cultural breadth - Improve: global examples across ecosystems. #### Inclusive language - Present: neutral, low-jargon. - Improve: add plain-language - Summary: GitHub releases now support immutability, adding a new layer of supply chain security. With immutable releases, assets and tags are protected from tampering after publication, so the software you publish—and… - URL: https://github.blog/changelog/2025-10-28-immutable-releases-are-now-generally-available/ ![GitHub release page with "enable release immutability" checked](https://github.blog/wp-content/uploads/2025/10/506111520-dcadd7e0-74fd-4dc6-90c1-363ff053672c.jpg?w=2064)GitHub release page with "enable release immutability" checked GitHub releases now support immutability, adding a new layer of supply chain security. With immutable releases, assets and tags are protected from tampering after publication, so the software you publish—and your users consume—remains secure and trustworthy. Immutable releases offer: * **Immutable assets**: Once you publish a release as immutable, its assets can’t be added, modified, or deleted. This helps protect distributed artifacts from supply chain attacks. * **Tag protection**: Tags for new immutable releases are protected and can’t be deleted or moved. * **Release attestations**: Immutable releases receive signed attestations so you can easily verify the authenticity and integrity of assets, both on GitHub and in external environments. You can enable immutable releases at the repository or organization level in your settings. Once enabled: * All new releases are immutable (i.e., assets are locked and tags are protected). * Existing releases remain mutable unless you republish them. Disabling immutability doesn’t affect releases created while it was enabled. They remain immutable. Release attestations let you verify that an artifact is authentic and unchanged, even outside GitHub. Attestations use the [Sigstore bundle format](https://docs.sigstore.dev/about/bundle/), so you can easily verify releases and assets using the GitHub CLI or integrate with any Sigstore-compatible tooling to automate policy enforcement in your CI/CD pipelines. For instructions on how to verify the integrity of a release, see [our docs on verifying the integrity of a release](https://docs.github.com/code-security/supply-chain-security/understanding-your-software-supply-chain/verifying-the-integrity-of-a-release?tool=cli?utm_source=changelog-docs-immutable-releases&utm_medium=changelog&utm_campaign=universe25). We’d love your feedback. Share your thoughts and questions on the [GitHub Community](https://gh.io/immutable-releases-ga?utm_source=changelog-community-immutable-releases&utm_medium=changelog&utm_campaign=universe25). For more information, see our [immutable releases documentation](https://docs.github.com/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases?utm_source=changelog-docs-immutable-releases&utm_medium=changelog&utm_campaign=universe25)., Immutable Releases Are Now Generally Available, The GitHub Blog, 01k8y62fgn50gahgsvfsjeht4w.