Was ist ein Dependency? Veraltete Abhängigkeiten einfach erklärt

Stellen Sie sich vor, Sie beauftragen einen Schreiner für einen neuen Schrank. Der Schreiner kauft Holz von Lieferant A, Scharniere von Lieferant B und Schrauben von Lieferant C. Wenn Lieferant B seine Scharniere nicht mehr produziert oder plötzlich fehlerhafte Ware liefert, hat das direkte Folgen für den fertigen Schrank.

Bei Software funktioniert das genauso. Jedes Programm nutzt Code, den andere Entwickler geschrieben haben. Diese Bausteine heißen Dependencies, auf Deutsch: Abhängigkeiten. Was eine Dependency genau ist, warum veraltete Abhängigkeiten ein unterschätztes Risiko sind und wie man den Überblick behält, erklärt dieser Artikel.

Was ist eine Dependency?

Eine Dependency (Abhängigkeit) ist eine externe Bibliothek oder ein externes Softwarepaket, das Ihre Anwendung nutzt. Niemand schreibt alles von Grund auf neu. Stattdessen greifen Entwickler auf fertigen Code für häufige Aufgaben zurück. Das spart Zeit und vermeidet typische Fehler.

Typische Beispiele für Abhängigkeiten sind:

• Eine Bibliothek, die das Versenden von E-Mails übernimmt
• Ein Paket für die sichere Verarbeitung von Passwörtern
• Ein Werkzeug zum Einlesen von PDF-Dateien
• Eine Komponente für die Datenbankverbindung

In einer mittelgroßen PHP-Anwendung gibt es oft 50 bis 200 solcher Abhängigkeiten. In JavaScript-Projekten sind es manchmal tausende. Das ist keine Ausnahme, das ist der Standard moderner Softwareentwicklung.

Warum sind veraltete Abhängigkeiten ein Problem?

Jede Abhängigkeit ist fremder Code. Und fremder Code kann Fehler enthalten, darunter auch Sicherheitslücken.

Die Hersteller dieser Bibliotheken veröffentlichen regelmäßig Updates. Diese Updates schließen Sicherheitslücken, korrigieren Fehler und verbessern die Kompatibilität. Wer seine Abhängigkeiten nicht aktualisiert, nutzt weiterhin die alten, unsicheren Versionen.

Das ist vergleichbar mit dem Einsatz eines Schlosses, dessen Schwachstellen öffentlich dokumentiert sind. Die Informationen über diese Lücken sind für jeden zugänglich. In öffentlichen Datenbanken wie der CVE-Datenbank (CVE steht für "Common Vulnerabilities and Exposures", zu Deutsch: bekannte Sicherheitslücken in Software) werden solche Lücken erfasst, beschrieben und eingestuft.

Automatisierte Angriffswerkzeuge durchsuchen das Internet nach Systemen mit bekannten Sicherheitslücken. Dabei spielt es keine Rolle, ob Ihr Unternehmen ein attraktives Ziel erscheint. Das System wird gefunden, wenn die Lücke bekannt ist.

Was macht das bei Legacy-Software besonders heikel?

Bei älterer Software, also Legacy Software, liegen Abhängigkeiten oft jahrelang unangetastet. Es gibt manchmal keine Werkzeuge für automatische Updates. Manchmal fehlt das Wissen darüber, welche Abhängigkeiten überhaupt vorhanden sind.

Das ist kein Einzelfall. Viele mittelständische Unternehmen betreiben Anwendungen, die vor zehn oder fünfzehn Jahren entwickelt wurden. Die damals verwendeten Bibliotheken wurden seitdem mehrfach überarbeitet. Manche werden nicht mehr gepflegt. Andere haben grundlegende Sicherheitsprobleme erhalten, die durch Updates längst geschlossen wurden.

Hinzu kommt: Technische Schulden akkumulieren sich nicht nur im eigenen Code, sondern auch in den Abhängigkeiten. Wer seit Jahren keine Updates eingespielt hat, hat ein angehäuftes Risikopotenzial, das sich von außen kaum einschätzen lässt.

Wie erkennt man das Problem?

Es gibt einige konkrete Warnsignale.

Keine zentrale Paketverwaltung: Ältere PHP-Projekte wurden oft ohne Composer gebaut, das gängige Werkzeug für das Verwalten von PHP-Abhängigkeiten. Bibliotheken wurden manuell heruntergeladen und in den Code eingefügt. Ein Überblick über Versionen und verfügbare Updates ist dann kaum möglich.

Unbekannte Versionsstände: Wenn niemand im Unternehmen sagen kann, welche Version einer Bibliothek im Einsatz ist, fehlt die Grundlage für eine Risikoeinschätzung.

Lange Zeit ohne Updates: Wenn eine Anwendung seit Jahren nicht angefasst wurde, sind mit hoher Wahrscheinlichkeit viele Abhängigkeiten veraltet.

Warnmeldungen von Hosting-Anbietern oder Scannern: Manche Server-Umgebungen oder Sicherheits-Tools geben Hinweise auf bekannte verwundbare Pakete. Diese Hinweise werden häufig ignoriert, weil niemand weiß, wie man damit umgehen soll.

Was können Sie konkret tun?

Der erste Schritt ist eine Bestandsaufnahme. Welche Abhängigkeiten sind in Ihrer Software vorhanden? Welche Versionen sind im Einsatz? Welche davon haben bekannte Sicherheitslücken?

Das klingt nach einem Entwicklerprojekt, und das ist es auch. Aber der Auftrag dazu kommt von Ihnen. Und Sie müssen kein Entwickler sein, um zu wissen, dass dieser Überblick fehlt.

Der zweite Schritt ist ein strukturiertes Update. Nicht jede Abhängigkeit lässt sich ohne weiteres aktualisieren. Manche Updates erfordern Anpassungen im eigenen Code. Ältere Bibliotheken wurden mitunter durch neuere Alternativen ersetzt. Das braucht Zeit. Aber es ist planbar und machbar.

Der dritte Schritt ist das Einführen eines regelmäßigen Prozesses. Abhängigkeiten veralten kontinuierlich. Ein einmaliges Update reicht nicht. Professionelle Software-Wartung schließt die regelmäßige Überprüfung und Aktualisierung von Abhängigkeiten ein. So bleibt das Risiko dauerhaft beherrschbar.

Fazit

Abhängigkeiten sind kein technisches Randdetail. Sie sind ein wesentlicher Teil jeder modernen Softwareanwendung. Veraltete Abhängigkeiten sind ein konkretes Sicherheitsrisiko, das sich still aufbaut, ohne dass jemand es aktiv bemerkt.

Die gute Nachricht: Das Problem lässt sich analysieren und lösen. Man muss wissen, was man hat, bevor man handeln kann. Dieser Überblick ist der erste Schritt.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Anwendung an und zeigen Ihnen, wo die Risiken liegen und was als nächstes sinnvoll ist.