GitHub nutzt eBPF zur Erkennung zirkulärer Abhängigkeiten beim Deployment

GitHub Engineering veröffentlichte am 16. April 2026 einen detaillierten Ingenieurbeitrag darüber, wie das Unternehmen eBPF (extended Berkeley Packet Filter)-Technologie zur Verbesserung der Sicherheit seiner Deployment-Prozesse einsetzt. Der Beitrag zeigt einen konkreten Produktionseinsatz von eBPF jenseits seiner Standard-Netzwerk-Observability-Domäne.

Das Problem: unsichtbare zirkuläre Abhängigkeiten

Große verteilte Systeme wie das von GitHub haben Tausende interner Dienste mit einem komplexen Abhängigkeitsnetz. Zirkuläre Abhängigkeiten — bei denen Dienst A Dienst B zum Starten benötigt und B direkt oder transitiv A braucht — sind nicht nur ein akademisches Problem. Sie werden kritisch beim Cold-Start-Deployment einer gesamten Umgebung oder bei einem Disaster-Recovery-Szenario.

Die schlimmsten zirkulären Abhängigkeiten sind in Architekturdiagrammen unsichtbar, da sie durch tiefe transitive Verbindungen entstehen, die niemand explizit dokumentiert hat. Ein Deploy-Skript ruft ein anderes Skript auf, das ein Tool aufruft, das sich mit einer API verbindet, die von einem Dienst abhängt, der vom ersten abhängt.

Der Beitrag identifiziert drei Typen zirkulärer Abhängigkeiten, die GitHub als potenzielle Systemgefahren überwacht.

Warum eBPF?

eBPF ermöglicht die Ausführung sicherer, sandbox-isolierter Programme direkt im Linux-Kernel, die Systemaufrufe, Netzwerkereignisse und andere Kernel-Aktivitäten ohne Modifikation der Anwendungen abfangen können. Dies ist ein entscheidender Vorteil, da Deployment-Skripte von vielen Teams und in verschiedenen Sprachen kommen.

Statt jedes Skript zur Selbst-Instrumentierung zu zwingen, hat GitHub ein eBPF-Programm geschrieben, das:

1. Den Netzwerkzugriff aus dem Deployment-Kontext selektiv überwacht
2. Analysiert, welche Dienste aus welchen Skripten aufgerufen werden
3. Automatisch einen Graphen der tatsächlichen Laufzeitabhängigkeiten aufbaut
4. Zyklen erkennt und Ingenieure warnt, bevor sie zu einem Produktionsvorfall werden

Observability auf Kernel-Ebene für DevOps

Technisch gesehen zeigt dieser Ansatz die Reifung von eBPF über seine ursprüngliche Netzwerkrolle hinaus. In den letzten Jahren hat sich eBPF ausgeweitet auf:

• Sicherheit: Falco, Tetragon für Laufzeit-Bedrohungserkennung
• Observability: Pixie, Parca für Profiling ohne Instrumentierung
• Networking: Cilium für Service Mesh und CNI

GitHubs Beitrag fügt eine weitere Kategorie hinzu — Deployment-Sicherheit als Teil des Platform-Engineering-Stacks. Anstatt Abhängigkeiten durch statische Analyse von Konfigurationsdateien zu suchen, wird das tatsächliche Laufzeitverhalten des Systems während des Deployments beobachtet.

Für Ingenieure, die an großen Plattformen und SRE-Teams arbeiten, bietet der Beitrag eine praktische Fallstudie darüber, wie eBPF vom Netzwerkwerkzeug zu einer allgemeinen Observability-Schicht des Betriebssystems gewachsen ist.