Von der Kompromittierung ausgehen: was der GitHub-Vorfall allen lehrt, die Software bauen

Im Mai 2026 gab GitHub bekannt, dass ein Angreifer rund 3.800 seiner internen Repositories kopiert hatte. Der Weg hinein war kein ausgefeilter Exploit gegen GitHubs Plattform. Es war der Laptop eines einzigen Mitarbeiters, und darauf eine manipulierte Version einer beliebten Erweiterung für den Editor Visual Studio Code. Die vergiftete Version war nur Minuten lang im Marketplace verfügbar, bevor sie zurückgezogen wurde, und das genügte. GitHub fand keine Hinweise darauf, dass Kunden-Repositories betroffen waren.

Die Lektion ist eine, die viele Teams lieber nicht hören: Wer Software baut, wird irgendwann Teil eines Einbruchs sein. Nicht aus Nachlässigkeit, sondern weil moderne Entwicklung auf Schichten von Werkzeugen, Erweiterungen und Abhängigkeiten läuft, die niemand vollständig kontrolliert.

Von der Kompromittierung ausgehen, die Auswirkung minimieren

Prävention zählt weiterhin, und wir investieren in sie. Aber ein Design, das nur funktioniert, solange nichts hereinkommt, ist ein Design, das am schlimmsten Tag versagt. Wir gehen von der umgekehrten Annahme aus: Jemand wird hereinkommen, also sorgen wir dafür, dass er ohne etwas von strategischem Wert wieder geht. In der Praxis läuft das auf vier Gewohnheiten hinaus.

• Kernlogik hinter Schnittstellen. Eigene Regeln und Algorithmen liegen nicht als lesbarer Quellcode in einem Repository. Sie leben hinter Diensten, Schnittstellen oder privaten Modulen, sodass ein kopiertes Repository zeigt, wie Dinge zusammenhängen, nicht wie sie funktionieren.
• Nichts Sensibles im Code. Keine Geheimnisse, keine internen Endpunkte, keine Konfiguration, die die Infrastruktur kartiert. Geheimnisse leben in einem Tresor und werden zur Laufzeit von einer Identität abgerufen, nie in eine Datei eingefügt.
• Bewusste Abstraktion. Code wird so geschrieben, dass er für die Menschen, die daran arbeiten, klar ist und jedem, der ihn nicht lesen sollte, so wenig wie möglich verrät.
• Standardmäßig öffentlich. Jedes Repository wird so geschrieben, als könnte es morgen offengelegt werden. Wäre eine Datei auf der Titelseite einer Nachrichtenseite ein Problem, gehört sie nicht ins Repository.

Der Arbeitsplatz ist der Perimeter

Der GitHub-Fall zeigt auch, wo der eigentliche Perimeter heute liegt: auf dem Rechner des Entwicklers. Der Editor, seine Erweiterungen und die Kommandozeilen-Werkzeuge auf diesem Rechner laufen alle mit dem Zugriff des Entwicklers. Das verlangt dieselbe Disziplin wie jeder andere Teil der Umgebung: eine kurze Liste freigegebener Erweiterungen, verwaltete und aktuell gehaltene Geräte, an ein verwaltetes Gerät gebundene Anmeldungen und Zugriff, der auf die Aufgabe zugeschnitten ist statt auf alles, was ein Entwickler irgendwann brauchen könnte.

Resilienz, nicht Paranoia

Sicherheit bedeutet nicht nur, Angreifer draußen zu halten. Sie bedeutet, dafür zu sorgen, dass der Schaden, wenn etwas passiert, klein, eingegrenzt und schnell behoben ist. Der GitHub-Vorfall wird nicht die letzte Schlagzeile dieser Art sein. Wie viel er Sie kostet, entscheidet sich mit jeder Designentscheidung, lange vor dem Vorfall.

Wir betreiben unsere eigenen Repositories auf diese Weise, und wir helfen Teams, dieselben Gewohnheiten zu übernehmen: Geheimnisse in einem Tresor, verwaltete Entwicklergeräte, eine kurze Liste freigegebener Editor-Erweiterungen und ein Review bei jeder Änderung.

Sehen Sie, was wir in Cybersecurity und Compliance und Team-Enablement anbieten.