Die 0deps-Bewegung: Lokale Abhängigkeiten und unveränderliche Verträge
Softwareentwickler installieren oft hunderte externe Bibliotheken. Moderne Frameworks verlassen sich auf tausende transitive Abhängigkeiten. Das bedeutet, dass Ihre Anwendung Code von Fremden ausführt.
Dies schafft ein Risiko für die Software-Lieferkette (Software Supply Chain Risk).
Jede Abhängigkeit vergrößert Ihre Angriffsfläche. Sie kann:
- Sicherheitslücken einführen.
- Zum Ziel von Supply-Chain-Angriffen werden.
- Von Maintainern aufgegeben werden.
- Ihre öffentliche API ändern.
- Die Abwärtskompatibilität brechen.
Die 0deps-Bewegung stellt eine einfache Frage: Was wäre, wenn sich Ihre Anwendung nur auf Code verlassen würde, den Sie selbst kontrollieren?
Im 0deps-Modell betten Sie notwendige Abhängigkeiten direkt in Ihr Projekt-Repository ein. Sie hören auf, diese während der Builds dynamisch herunterzuladen. Alles, was zum Ausführen der Anwendung benötigt wird, befindet sich von Anfang an im Repository.
Dieser Ansatz bietet:
- Reproduzierbare Builds.
- Geringere Abhängigkeit von externen Registries.
- Zentralisierte Sicherheitsaudits.
- Höhere Vorhersehbarkeit.
Das Kernprinzip besteht nicht darin, Code statisch zu halten. Implementierungen und Algorithmen müssen sich weiterentwickeln, um Fehler zu beheben und die Sicherheit zu verbessern. Was stabil bleibt, ist der öffentliche Vertrag (Public Contract).
Jede Bibliothek stellt eine sorgfältig entworfene Schnittstelle bereit. Beispiele hierfür sind:
authenticate()createSession()verifyPasskey()
Diese Funktionen definieren einen Vertrag. Dieser Vertrag ändert sich nie. Sie können den Code dahinter neu schreiben oder die Bibliothek komplett austauschen. Der Rest Ihrer Anwendung wird die Änderung nicht bemerken.
Wenn eine Schwachstelle auftritt, stehen Sie normalerweise vor zwei Problemen:
- Die Schwachstelle beheben.
- Überprüfen, ob das Update Ihre Anwendung beschädigt.
In einer 0deps-Architektur verschwindet das zweite Problem. Sie aktualisieren die interne Implementierung, während die öffentliche API gleich bleibt. Ihre Anwendung funktioniert weiterhin ohne Codeänderungen.
Sie isolieren externe Integrationen mithilfe eines internen Adapters: Anwendung -> Öffentliche Schnittstelle -> Adapter -> Implementierung
Wenn eine Bibliothek morgen verschwindet, müssen Sie nur den Adapter ändern. Kein anderer Teil Ihrer Anwendung geht kaputt.
0deps macht Software nicht perfekt. Es reduziert die Risiken in der Lieferkette. Es verhindert Probleme wie bösartige Pakete, Kompromittierungen von Registries und Dependency Confusion.
Projekte halten Jahrzehnte an. Bibliotheken und Frameworks ändern sich. Mit 0deps nutzt Ihre Anwendung weiterhin dieselben stabilen Verträge, unabhängig davon, wie sich das Ökosystem entwickelt.