0deps: Mehr Sicherheit durch lokale Abhängigkeiten und unveränderliche Verträge

Die moderne Softwareentwicklung ist seit Jahren von einer Kultur geprägt, die auf externe Bibliotheken setzt – oft Hunderte oder sogar Tausende pro Projekt. Diese Abhängigkeiten beschleunigen zwar die Entwicklung, bergen aber auch erhebliche Risiken für die Softwaresicherheit. Die 0deps-Bewegung stellt diese Praxis infrage und schlägt eine radikale Alternative vor: Projekte sollen nur noch Code verwenden, den sie selbst kontrollieren.

Warum externe Abhängigkeiten zum Sicherheitsrisiko werden

Jede zusätzliche Abhängigkeit erweitert die potenzielle Angriffsfläche einer Anwendung. Mögliche Gefahren umfassen:

• Sicherheitslücken in externen Bibliotheken
• Kompromittierte Paketquellen oder Lieferkettenangriffe
• Unerwartete Änderungen in öffentlichen APIs
• Veraltete oder nicht mehr unterstützte Bibliotheken
• Unverträgliche Versionen oder transitive Abhängigkeiten
• Typosquatting-Angriffe durch manipulierte Paketnamen

Sobald eine Anwendung sich auf externe Bibliotheken verlässt, verliert sie die Kontrolle über einen Großteil des in der Produktion laufenden Codes. Je komplexer die Abhängigkeitsstruktur, desto größer wird das Risiko – selbst wenn die ursprünglichen Abhängigkeiten harmlos erscheinen.

Der 0deps-Ansatz: Abhängigkeiten fest im Projekt verankern

Die zentrale Idee der 0deps-Bewegung besteht darin, alle benötigten Abhängigkeiten direkt in das Projekt-Repository zu integrieren. Anstatt sich auf dynamische Paketmanager zu verlassen, die Bibliotheken während der Installation oder des Build-Prozesses herunterladen, wird der gesamte benötigte Code bereits bei der Auslagerung des Projekts bereitgestellt.

Diese Strategie bietet mehrere entscheidende Vorteile:

• Reproduzierbare Builds: Jeder Entwickler und jede Umgebung erhält exakt denselben Code, was Fehlerquellen minimiert.
• Reduzierte Abhängigkeit von externen Paketregistern: Keine Unterbrechungen durch ausgefallene oder abgesicherte Paketquellen.
• Zentrale Sicherheitsprüfung: Alle Abhängigkeiten sind lokal verfügbar und können vor der Integration geprüft werden.
• Höhere Vorhersagbarkeit: Keine unerwarteten Änderungen durch externe Bibliotheken.
• Kleinerer Angriffsvektor: Die Software-Lieferkette wird auf das Nötigste reduziert.

Unveränderliche Verträge statt starrer Implementierungen

Ein häufiges Missverständnis ist, dass 0deps unveränderliche Implementierungen voraussetzt. Das ist nicht der Fall. Vielmehr geht es um unveränderliche öffentliche Verträge – die Schnittstellen, mit denen andere Teile des Systems interagieren.

Stellen Sie sich vor, eine Bibliothek stellt folgende Funktionen bereit:

authenticate()

createSession()

verifyPasskey()

sendMagicLink()

Diese Funktionen definieren den öffentlichen Vertrag. Die Implementierung dahinter – also die tatsächliche Logik, Algorithmen oder Datenstrukturen – kann sich weiterentwickeln. Wichtig ist nur, dass die Schnittstelle stabil bleibt. Selbst wenn die interne Bibliothek durch eine völlig neue Implementation ersetzt wird, bleibt die Art und Weise, wie das restliche System mit der Bibliothek interagiert, unverändert.

Sicherheitsupdates ohne Anwendungsunterbrechung

Ein häufiges Dilemma bei klassischen Abhängigkeiten ist das Risiko, dass Sicherheitsupdates bestehende Anwendungen brechen könnten. Entwickler stehen dann vor der Herausforderung, zwischen Sicherheit und Stabilität abzuwägen.

In einem 0deps-basierten System wird dieses Problem eliminiert. Sicherheitslücken lassen sich durch interne Updates beheben, ohne dass die öffentliche API angepasst werden muss. Die Anwendung läuft weiter – ohne Codeänderungen. Nur die Implementierung hinter der Schnittstelle wird aktualisiert.

Interne Adapter für externe Integrationen

Jede externe Schnittstelle wird hinter einem internen Adapter gekapselt. Die Architektur folgt diesem Muster:

Anwendung → Öffentliche Schnittstelle → Adapter → Implementierung

Sollte eine externe Bibliothek in Zukunft veraltet oder nicht mehr verfügbar sein, muss nur der Adapter angepasst werden. Die restliche Anwendung bleibt unberührt. Diese Kapselung reduziert die Auswirkungen technologischer Veränderungen über lange Zeiträume hinweg erheblich.

Versionierung als Implementierungsdetail

Anwendungen, die nach dem 0deps-Prinzip entwickelt wurden, interagieren nie direkt mit externen Bibliotheks-APIs. Stattdessen kommunizieren sie ausschließlich über stabile interne Verträge. Bibliotheksversionen werden damit zu einem reinen Implementierungsdetail – die Entwickler der Anwendung müssen sich nicht mehr um Versionen oder Kompatibilität kümmern.

Langfristige Stabilität durch Design

Der größte Vorteil von 0deps zeigt sich oft erst Jahre nach der Veröffentlichung eines Projekts. Während Bibliotheken verschwinden, Frameworks sich ändern und Programmiersprachen weiterentwickelt werden, bleibt die Anwendung stabil – weil sie auf unveränderliche Verträge setzt. Verantwortung für die Anpassung an neue Ökosysteme liegt zentralisiert bei den internen Adaptern des Projekts, nicht verteilt über hunderte abhängige Anwendungen.

Selbst wenn eine Bibliothek durch eine komplett neue Implementierung ersetzt wird, bleibt die Anwendung funktionsfähig. Disruptive Upgrades werden zu einfachen Ersetzungen der internen Logik, die keine Auswirkungen auf die Funktionalität der Anwendung haben.

Die 0deps-Bewegung: Keine Ablehnung, sondern Neugestaltung von Open Source

Die 0deps-Bewegung steht nicht im Widerspruch zu Open Source. Im Gegenteil: Sie erkennt den enormen Wert quelloffener Software an, schlägt aber ein anderes Konsummodell vor. Anstatt Bibliotheken als dynamisch installierte Abhängigkeiten zu behandeln, werden sie zu geprüften, versionierten Komponenten, die hinter stabilen öffentlichen Verträgen gekapselt sind.

Das Ergebnis ist Software, die vorhersehbarer, widerstandsfähiger und einfacher zu warten ist – und gleichzeitig deutlich weniger anfällig für Risiken in der Software-Lieferkette. Implementierungen können sich weiterentwickeln. Die Verträge bleiben unverändert. Und genau diese Stabilität ermöglicht es Anwendungen, die heute entwickelt werden, auch in vielen Jahren noch genauso zu funktionieren wie am ersten Tag.