Was ein Release-Tag nicht garantiert: Tags und Assets
Ein Git-Tag lässt sich auf einen anderen Commit setzen, und ohne Schutz lassen sich Dateien an einem Release austauschen. Mit GitHub Immutable Releases schließt du genau diese Lücke: Nach dem Veröffentlichen sind Tag und Dateien des Releases gesperrt.
Dieser Beitrag stützt sich auf die GitHub-Dokumentation, gelesen am 26.09.2026: Immutable releases, Preventing changes to your releases, Verifying the integrity of a release und Managing releases in a repository. Ergänzend gilt die Ankündigung im GitHub-Changelog vom 28.10.2025. Folgerungen sind gekennzeichnet.
Zur Abgrenzung: Third-Party Actions pinnen: warum SHA statt Tag und was eine Allowlist bringt schützt dich als Nutzer fremder Actions. Provenance und Attestation: woher ein Artefakt wirklich stammt und Signierte Commits und Artefakte: Wann sich das lohnt klären Herkunft und Signatur. Hier geht es um die Unveränderbarkeit des Release-Objekts, das du selbst veröffentlichst.
Status und Geltungsbereich
Laut Changelog sind Immutable Releases allgemein verfügbar (GA), nicht in einer Preview. Die drei Doku-Seiten nennen den Status selbst nicht. Die Seitentexte nennen keine Einschränkung nach Plan. Die Versionsauswahl der Doku führt „Free, Pro, & Team“, „Enterprise Cloud“ und Enterprise Server 3.20 bis 3.22 auf.
Was GitHub Immutable Releases sperren
Die Doku nennt zwei Dinge:
- Der Git-Tag. Er ist an einen Commit gebunden, lässt sich nicht verschieben und nicht löschen, solange das Release existiert. Löschst du das Release, kannst du den Tag löschen, den Tag-Namen aber nicht wiederverwenden.
- Die Release-Assets. Alle angehängten Dateien, etwa Binaries und Archive, lassen sich weder ändern noch löschen. Die Seite zum Verwalten von Releases ergänzt: Nach dem Veröffentlichen kannst du auch keine Assets mehr hinzufügen oder ersetzen.
Zusätzlich schützt die Funktion vor sogenannten Repository-Resurrection-Angriffen: Auch wenn du ein Repository löschst und ein neues mit demselben Namen anlegst, sind Tags aus früheren Immutable Releases nicht wieder verwendbar.
Was nicht gesperrt wird
Gesperrt sind nur Assets und Tag. Titel und Release Notes eines veröffentlichten Releases kannst du weiter bearbeiten, ebenso die Markierung als Pre-Release oder als neuestes Release. Der automatisch erzeugte Quellcode-Download (Zip und Tarball) taucht in der Doku nur an einer Stelle auf: gh release verify-asset kann ihn nicht prüfen, weil diese Dateien erst beim Download entstehen.
Folgerung, nicht in der Doku: Die Sperre gilt dem Release-Objekt. Was davor im Build passiert ist, deckt sie nicht ab. Sie garantiert, dass sich das Veröffentlichte nicht mehr ändert, nicht dass es vorher richtig war.
GitHub Immutable Releases einschalten
Im Repository: Einstellungen, Abschnitt „Releases“, „Enable release immutability“ auswählen. In der Organisation: Einstellungen, unter „Code, planning, and automation“ den Punkt „Repository“, dort „General“. Im Abschnitt „Releases“ wählst du statt „No policy“ entweder „All repositories“ oder „Selected repositories“.
Die Doku weist darauf hin, dass die Unveränderbarkeit nur für künftige Releases gilt. Laut Changelog bleiben bestehende Releases veränderlich, außer du veröffentlichst sie neu. Schaltest du die Funktion wieder ab, bleiben Releases, die unter ihr entstanden sind, unveränderlich.
Der Draft-Workflow
Die Doku empfiehlt drei Schritte: Release als Draft anlegen, alle Assets anhängen, dann veröffentlichen. Erst mit dem Veröffentlichen wird das Release unveränderlich, damit alle Dateien vorher da sind.
Folgerung, nicht in der Doku: Ein Workflow, der erst veröffentlicht und danach Dateien hochlädt, läuft in die Sperre. Und ein falsches Asset lässt sich nach dem Veröffentlichen nicht mehr austauschen. Weil auch der Tag-Name nicht frei wird, bleibt nur eine neue Version.
Für die Kommandozeile nennt die Doku gh release create. Die Optionen --draft und gh release edit TAG --draft=false stehen in der gh-Hilfe. Ein Durchlauf gegen ein Repository mit aktivierter Funktion fand nicht statt, ein vollständiger Befehl steht deshalb hier bewusst nicht.
Prüfen und Verhältnis zu Attestations
Jedes Immutable Release erzeugt automatisch eine Release Attestation. Sie ist ein kryptografisch prüfbarer Eintrag mit Release-Tag, Commit-SHA und Assets. Damit können Nutzer nachweisen, dass Release und Dateien mit dem veröffentlichten GitHub-Release übereinstimmen. Laut Changelog nutzt sie das Sigstore-Bundle-Format.
Prüfen kannst du nach Doku so: gh release verify TAG bestätigt, dass ein Release existiert und unveränderlich ist. gh release verify-asset TAG PFAD vergleicht eine lokale Datei mit dem Asset. Auf der Release-Seite zeigt GitHub außerdem „Immutable“ unter dem Titel. Die Befehle sind Doku-Wortlaut und nicht getestet. Ab welcher gh-Version sie verfügbar sind, steht in der Doku nicht.
Folgerung, nicht in der Doku: Diese Attestation belegt, was am Release hängt und dass es sich nicht geändert hat. Wie ein Artefakt gebaut wurde, sagt sie nicht. Dafür bleibt Build-Provenance zuständig, und ob derselbe Quellstand dasselbe Artefakt ergibt, klärt Reproducible Builds: Warum derselbe Code zweimal dasselbe Artefakt ergeben sollte.
Wo Unterstützung ansetzt
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Hinterlasse einen Kommentar