Im März veröffentlichte Wiz eine Command-Injection-Schwachstelle in GitHub. Jeder mit Push-Zugriff auf ein beliebiges Repository auf github.com konnte Code als git-User auf dem Storage-Node ausführen, der die Repositories von Millionen anderer Menschen enthielt. GitHub patchte die öffentliche Seite in zwei Stunden. Die meisten On-Premise-Enterprise-Installationen waren noch ungepatcht, als die Nachricht kam. Das Detail, das für den Rest von uns am wichtigsten war: Wiz fand den Bug mit KI.
Eine Plattform, vier Einfallstore
Schau auf die GitHub-Schlagzeilen der letzten achtzehn Monate. Der Wiz-Fund stand neben tj-actions/changed-files, einer GitHub Action, die von dreiundzwanzigtausend Repositories genutzt und still unter allen Abhängigen umgeschrieben wurde, nachdem ein Angreifer ein gestohlenes Personal Access Token sechs Monate lang ruhen gelassen hatte. Dann CamoLeak, wo unsichtbares Markdown in einem Pull Request Copilot Chat anwies, Secrets über GitHubs eigenen Image-Proxy zu exfiltrieren. Dann die Lasso-Veröffentlichung, dass Bings Cache und später Copilot selbst noch immer Inhalte aus Repositories ausliefert, die privat gemacht worden waren.
Vier verschiedene Angriffsklassen. Achtzehn Monate. Eine Plattform.
Das ist ein Problem mit der Form selbst
Zentralisiertes SaaS für Quellcode ist ein Ziel aus demselben Grund, aus dem es nützlich ist: Es konzentriert viel wertvollen Code an einem Ort, auf der Infrastruktur eines Betreibers, hinter einem Verteidigungsring. Was durch diesen Ring kommt, kommt zu allen durch, die auf der Plattform liegen. Das Tempo ist die andere Hälfte. Die Wiz-Forscher nutzten KI-Tools, um Closed-Source-Binaries zu lesen und die internen Protokolle zu reverse-engineeren. Dieselbe Art Tool, mit der der Rest von uns eine Funktion autocompletet, fand eine Schwachstelle, die Millionen Repositories in Reichweite brachte. Was auch immer du für die Rate neuer Funde im kommenden Jahrzehnt hältst, die echte Zahl wird höher sein. KI wird nicht müde.
Die niederländische Regierung las dieselben Schlagzeilen und handelte. Im April startete sie code.overheid.nl, eine selbst-gehostete Forgejo-Instanz, betrieben von ihrer eigenen Open-Source-Abteilung. Ihre Begründung, im Wortlaut: "Das Hosten von Quellcode ist eine kritische Komponente der Infrastruktur der niederländischen Regierung. Die Regierung kann das Risiko nicht eingehen, dass Code oder Binaries in Repositories manipuliert werden, da Menschen sie direkt ausführen können." Eine nationale Regierung sagt offen, dass sie ihren Code nicht auf der Kiste eines anderen manipulieren lassen kann. Das ist die erwachsene Antwort.
Was Managed Self-Hosting bedeutet
Managed Self-Hosting ist die Antwort für Teams, die die Souveränität wollen, ohne das Ops-Team zu betreiben. Eure Git-Plattform läuft auf dedizierter Single-Tenant-Hardware. Schlüssel, Daten und Audit Trail gehören euch. Wir deployen sie, patchen sie, sichern sie, monitoren sie und melden uns, wenn etwas eure Aufmerksamkeit braucht. Keine geteilte Anwendung. Keine anderen Mieter in derselben Instanz. Der Verteidigungsperimeter endet an eurem Team, nicht am Rand einer Plattform.
Der praktische Teil, der Operatoren am meisten bringt, ist Nähe. Eure Daten sind genau dort, wenn ihr sie braucht. Ihr könnt euch auf den Server einloggen und das Backup selbst von der Platte lesen. Ihr könnt prüfen, wer Zugriff hat, und ihn ohne Support-Ticket entziehen. Wenn die nächste Veröffentlichung kommt, steht ihr nicht in einer Warteschlange mit achtzigtausend anderen Firmen und wartet auf ein Patch Window.
Warum Gitea
Gitea sieht aus und fühlt sich an wie GitHub. Pull Requests, Issues, Project Boards, Actions Runners für CI, eine Container- und Package Registry. Die meisten Teams wechseln an einem Nachmittag und stellen fest, dass der tägliche Workflow derselbe ist. Es läuft komfortabel auf bescheidener Hardware, skaliert horizontal für die Teile, die es brauchen, und ist Open Source, sodass der Migrationsweg nach außen real ist, falls sich eure Anforderungen ändern.
Wir betreiben unser eigenes Engineering auf Gitea. Jede Zeile Code, die unser Team ausliefert, geht hindurch: Pull Requests, Actions-getriebene Releases, das Package Registry für unsere Go-Module und Container Images. Unser CRM, Helpdesk, Project Tracker und die Platform Demo, auf der unsere Agenten arbeiten, leben alle auf derselben dedizierten Hardware. Alles, was wir shippen, läuft auf der Infrastruktur, auf die wir morgen einen Kunden setzen würden.
Für wen das ist
Das ist für Softwareteams mit fünf bis fünfzig Menschen, die Code schreiben, der zählt. Digitalagenturen, deren Kunden-Codebases Teil der Lieferung sind. Softwarefirmen mit sensiblem IP, Vergabearbeit im öffentlichen Sektor oder Compliance-Pflichten unter DORA, NIS2 oder DSGVO, die einfacher werden, wenn die Audit-Grenze euer eigener Server ist. Es ist nicht für Hobby-Projekte oder Drei-Personen-Startups, die Runway verbrennen; für die ist die SaaS-Prämie immer noch ihr Geld wert. Die Frage ist, ob das Werkzeug, das den Quellcode eures Teams hält, auf der Plattform eines anderen sitzen sollte, zusammen mit dem aller anderen.
Zeit, die Kontrolle zu übernehmen?
Die Schlagzeilen werden nicht langsamer. Die nächste Veröffentlichung wird gerade jetzt geschrieben, von einem Forscher, der eine Reverse-Engineering-Schleife über Nacht laufen lässt, während die Welt schläft. Die Antwort ist dieselbe, auf die die niederländische Regierung gekommen ist: Bringt euren Quellcode auf Hardware, die ihr kontrolliert, mit Schlüsseln, die ihr haltet, und jemandem Kompetentem, der sie am Laufen hält.