Veraltete Abhängigkeiten gehören zu den am häufigsten unterschätzten Sicherheitsrisiken in modernen Softwareprojekten. Während Unternehmen erhebliche Ressourcen in Firewalls und Zugriffskontrollen investieren, schlummern in den eigenen Codebasen Hunderte von Bibliotheken, die seit Monaten oder Jahren kein Sicherheits-Update mehr erhalten haben. Das Ergebnis: eine stille, wachsende Angriffsfläche, die Cyberkriminelle gezielt ausnutzen.
Dieser Leitfaden zeigt Ihnen, warum veraltete Abhängigkeiten so gefährlich sind, wie Sie betroffene Komponenten systematisch identifizieren und welche Prozesse Sie dauerhaft vor Schwachstellen schützen.
Warum veraltete Abhängigkeiten ein kritisches Sicherheitsproblem sind
Moderne Softwareentwicklung ist ohne externe Bibliotheken und Frameworks kaum denkbar. Eine typische Node.js-Webanwendung nutzt laut npm-Statistiken schnell 500 bis über 1.000 transitive Abhängigkeiten — also Pakete, die Ihre direkten Abhängigkeiten wiederum einbinden. Jede einzelne davon ist ein potenzieller Einfallspunkt.
Das Problem wächst exponentiell: Wird eine bekannte Schwachstelle (CVE) in einer populären Bibliothek veröffentlicht, beginnen automatisierte Angriffstools innerhalb von Stunden, das Internet nach verwundbaren Systemen zu scannen. Unternehmen, die nicht schnell reagieren, riskieren Datenverluste, Betriebsunterbrechungen und empfindliche Bußgelder nach DSGVO.
Besonders kritisch sind drei Szenarien:
- Direkte Schwachstellen: Eine von Ihnen verwendete Bibliothek enthält eine bekannte Sicherheitslücke (z. B. Log4Shell in Log4j, die 2021 Millionen Systeme betraf).
- Transitive Abhängigkeiten: Eine Bibliothek, die Sie selbst nicht kennen, weil sie tief im Abhängigkeitsbaum vergraben ist, enthält eine kritische Lücke.
- Abandoned Packages: Bibliotheken, deren Entwicklung eingestellt wurde und die keine Sicherheits-Updates mehr erhalten — auf unbestimmte Zeit.
Der reale Schaden durch ungepatchte Bibliotheken
Die Zahlen sprechen für sich: Der Verizon Data Breach Investigations Report zeigt year für year, dass ein signifikanter Anteil erfolgreicher Angriffe auf bekannte, aber ungepatchte Schwachstellen zurückgeht. Die Equifax-Datenpanne 2017, bei der Daten von 147 Millionen Menschen gestohlen wurden, basierte auf einer ungepatchten Apache-Struts-Komponente — eine veraltete Abhängigkeit mit bekannter CVE.
Für deutsche KMU bedeutet das konkret: Ein einziger erfolgreicher Angriff über eine veraltete Bibliothek kann Bußgelder nach Art. 83 DSGVO von bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes nach sich ziehen — ganz abgesehen vom Reputationsschaden.
Den eigenen Software-Stack analysieren: So starten Sie
Bevor Sie Abhängigkeiten aktualisieren können, müssen Sie wissen, was in Ihrem Stack steckt. Dieser Prozess wird als Software Composition Analysis (SCA) bezeichnet.
Schritt 1: Eine vollständige Bestandsaufnahme erstellen (SBOM)
Ein Software Bill of Materials (SBOM) ist ein vollständiges Inventar aller Softwarekomponenten und ihrer Versionen. Das BSI empfiehlt SBOMs inzwischen explizit als Teil einer modernen IT-Sicherheitsstrategie.
Für die Erstellung nutzen Sie am besten ökosystemspezifische Werkzeuge:
- JavaScript/Node.js: `npm audit`, `yarn audit`
- Python: `pip-audit`, `safety`
- Java/Kotlin: OWASP Dependency-Check, Gradle/Maven-Plugins
- PHP: `composer audit`
- Ruby: `bundler-audit`
- Docker/Container: `trivy`, `grype`
Ein einfacher erster Schritt: Führen Sie `npm audit --json > sbom.json` in Ihrem Projekt aus. Die Ausgabe zeigt Ihnen sofort, wie viele Pakete bekannte Schwachstellen aufweisen und wie kritisch diese sind (Low, Moderate, High, Critical).
Schritt 2: Schwachstellen nach Kritikalität priorisieren
Nicht jede veraltete Abhängigkeit ist gleich gefährlich. Nutzen Sie das CVSS-Score-System (Common Vulnerability Scoring System), um zu priorisieren:
1. Critical (9.0–10.0): Sofortige Aktion erforderlich — innerhalb von 24 Stunden patchen
2. High (7.0–8.9): Patch innerhalb einer Woche einplanen
3. Medium (4.0–6.9): Im nächsten Sprint berücksichtigen
4. Low (0.1–3.9): In regulären Update-Zyklen beheben
Wichtig: Berücksichtigen Sie auch den Kontext. Eine kritische Schwachstelle in einer Bibliothek, die nur in Ihrem Build-Prozess, nicht im Produktivcode läuft, ist weniger dringlich als eine Medium-Schwachstelle in einer öffentlich exponierten API-Komponente.
Veraltete Abhängigkeiten systematisch aktualisieren
Das Identifizieren von Schwachstellen ist der erste Schritt. Das kontrollierte Aktualisieren ist der zweite — und oft der schwierigere.
Das Dilemma: Stabilität vs. Sicherheit
Viele Entwicklungsteams scheuen Updates, weil sie Breaking Changes fürchten. Dieses Zögern ist verständlich, aber gefährlich. Die Lösung liegt in einer strukturierten Update-Strategie:
- Patch-Updates (z. B. 2.3.4 → 2.3.5): Sicherheitsfixes ohne API-Änderungen — immer sofort einspielen
- Minor-Updates (z. B. 2.3.x → 2.4.0): Neue Features, abwärtskompatibel — in regulären Sprints testen
- Major-Updates (z. B. 2.x → 3.0.0): Breaking Changes möglich — als eigenes Projekt mit Testabdeckung planen
Automatisierte Tools nehmen Ihnen einen Großteil der Arbeit ab:
- Dependabot (GitHub): Erstellt automatisch Pull Requests für veraltete Abhängigkeiten, inkl. CVSS-Score und Changelogs
- Renovate Bot: Hochkonfigurierbar, unterstützt zahlreiche Ökosysteme und ermöglicht gruppierte Updates
- Snyk: Kombiniert SCA mit automatischen Fix-Vorschlägen und CI/CD-Integration
Testabdeckung als Sicherheitsnetz
Kein Update ohne Tests — das ist die goldene Regel. Ohne ausreichende Testabdeckung können Sie nicht sicher sein, ob ein Dependency-Update unerwünschte Seiteneffekte hat. Investieren Sie deshalb parallel in:
- Unit Tests für kritische Geschäftslogik
- Integrationstests für externe Schnittstellen
- End-to-End-Tests für kritische User Journeys
Eine Testabdeckung von mindestens 70 % für kritische Systempfade gilt als Mindeststandard, bevor Sie größere Dependency-Updates automatisieren.
Dauerhafter Schutz: Dependency Management als Prozess
Einmalige Bereinigungen reichen nicht aus. Veraltete Abhängigkeiten entstehen täglich neu, weil neue Schwachstellen in bestehenden Paketen entdeckt werden. Nachhaltiger Schutz erfordert daher einen kontinuierlichen Prozess.
Dependency-Hygiene in den Entwicklungszyklus integrieren
Folgende Maßnahmen sollten fester Bestandteil Ihres Software-Development-Lifecycles (SDLC) sein:
1. CI/CD-Gates einrichten: Lassen Sie Ihren Build-Prozess automatisch fehlschlagen, wenn kritische CVEs im Abhängigkeitsbaum gefunden werden. Tools wie `npm audit --audit-level=high` oder OWASP Dependency-Check lassen sich nahtlos in Jenkins, GitLab CI oder GitHub Actions einbinden.
2. Wöchentliche Dependency-Reviews: Planen Sie ein festes 30-minütiges Meeting pro Woche, in dem Ihr Team die Dependabot-/Renovate-PRs reviewed und merged.
3. Dependency-Policy dokumentieren: Legen Sie fest, welche Bibliotheken Sie einsetzen dürfen (Whitelisting) und welche als veraltet oder unsicher gelten. Dokumentieren Sie Ausnahmen mit Begründung und Ablaufdatum.
4. Lieferkettensicherheit beachten: Prüfen Sie bei neuen Abhängigkeiten: Wie aktiv ist die Entwickler-Community? Wann war das letzte Release? Gibt es eine Security-Policy? Ein verlassenes Paket mit 50.000 wöchentlichen Downloads ist ein erhebliches Risiko.
5. Version Pinning vs. Ranges: Überlegen Sie strategisch, ob Sie Versionen exakt pinnen (`"lodash": "4.17.21"`) oder Ranges erlauben (`"lodash": "^4.17.0"`). Pinning erhöht die Stabilität, erfordert aber aktives Update-Management. Ranges erleichtern automatische Updates, bringen aber das Risiko unerwarteter Breaking Changes.
Das Lieferketten-Risiko: Supply Chain Attacks
Ein wachsendes Bedrohungsszenario sind Software Supply Chain Attacks, bei denen Angreifer nicht direkt Ihr System, sondern eine Ihrer Abhängigkeiten kompromittieren. Bekannte Beispiele sind der SolarWinds-Angriff (2020) und die Kompromittierung des npm-Pakets `event-stream` (2018).
Schützende Maßnahmen umfassen:
- Subresource Integrity (SRI) für CDN-geladene Bibliotheken
- Package-Lock-Dateien (`package-lock.json`, `yarn.lock`) im Repository versionieren
- Private Package Registries für kritische interne Bibliotheken
- Signierten Commits und verifizierten Paketen (z. B. npm provenance) den Vorzug geben
Tooling-Empfehlungen für deutsche KMU
Der Markt für Dependency-Security-Tools ist unübersichtlich. Hier eine praxisorientierte Auswahl nach Reifegrad:
Einstieg (kostenlos, sofort umsetzbar)
- npm audit / yarn audit / pip-audit: In jedes Projekt integrierbar, keine Zusatzkosten
- Dependabot: In GitHub-Repositories kostenlos aktivierbar, erstellt automatisch PRs
- OWASP Dependency-Check: Open-Source-Tool für Java, .NET und weitere Ökosysteme
Professioneller Einsatz (für wachsende Teams)
- Snyk: Kombination aus SCA, Container-Scanning und IaC-Analyse; kostenfreie Tier für kleine Teams
- Mend (ehemals WhiteSource): Umfassendes SBOM-Management und Compliance-Reporting
- JFrog Xray: Ideal für Unternehmen, die JFrog Artifactory als Package Registry nutzen
Enterprise-Level
- Veracode Software Composition Analysis: Für komplexe Multi-Technologie-Stacks
- Black Duck by Synopsys: Marktführer im Bereich Open-Source-Compliance und Sicherheitsanalyse
Empfehlung für KMU: Starten Sie mit Dependabot und `npm audit` im CI/CD-System. Das kostet nichts, ist in wenigen Stunden eingerichtet und deckt die häufigsten Schwachstellen ab. Skalieren Sie dann mit Snyk, sobald Ihr Team wächst oder regulatorische Anforderungen steigen.
Regulatorische Anforderungen: Was deutsche Unternehmen wissen müssen
Für Unternehmen in regulierten Branchen oder kritischer Infrastruktur sind SBOMs und Dependency-Management keine Empfehlung mehr, sondern Pflicht.
- NIS2-Richtlinie (seit Oktober 2024): Verpflichtet betroffene Unternehmen zu umfassendem Schwachstellen-Management — explizit inklusive Software-Lieferketten. Veraltete Abhängigkeiten ohne Patch-Prozess gelten als Verstoß.
- BSI IT-Grundschutz: Baustein CON.10 (Entwicklung von Webanwendungen) fordert explizit den Einsatz aktueller, sicherer Bibliotheken.
- DSGVO Art. 32: Technische Maßnahmen zur Sicherheit der Verarbeitung umfassen implizit das Patching bekannter Schwachstellen.
Unternehmen, die NIS2 unterliegen, müssen nachweisen können, dass sie bekannte Schwachstellen in ihrer Software systematisch identifizieren und beheben. Ein SBOM ist dabei der Schlüsselbaustein.
Wenn Sie unsicher sind, ob und wie Ihr Unternehmen von NIS2 betroffen ist, finden Sie auf unserer Pilecode Blog-Übersicht weitere Beiträge zu regulatorischen IT-Anforderungen.
Häufige Fehler — und wie Sie sie vermeiden
Selbst gut organisierte Entwicklungsteams machen beim Dependency Management typische Fehler:
- "Es läuft doch noch": Funktionierender Code bedeutet nicht sicherer Code. Veraltete Abhängigkeiten laufen oft problemlos — bis ein Angreifer die bekannte Lücke ausnutzt.
- Zu selten prüfen: Monatliche Scans sind zu selten. Neue CVEs erscheinen täglich. Integrieren Sie Prüfungen in jeden Build.
- Alle Updates auf einmal: Massive Bulk-Updates erhöhen das Risiko, dass ein Problem übersehen wird. Lieber kleinteilig und kontrolliert vorgehen.
- Lock-Files ignorieren: Ohne eingecheckte Lock-Files (`package-lock.json`) können unterschiedliche Entwickler unterschiedliche (ggf. verwundbare) Versionen installieren.
- Interne Pakete vergessen: Selbst entwickelte Bibliotheken, die intern geteilt werden, brauchen dieselbe Sorgfalt wie externe Open-Source-Pakete.
Fazit: Dependency Management ist Sicherheitspflicht
Veraltete Abhängigkeiten sind keine theoretische Bedrohung — sie sind eine der führenden Ursachen realer Sicherheitsvorfälle. Die gute Nachricht: Mit den richtigen Prozessen und Tools lässt sich das Risiko erheblich reduzieren, ohne den Entwicklungsprozess zu verlangsamen.
Der Schlüssel liegt im Dreiklang aus Sichtbarkeit (SBOM, regelmäßige Scans), Priorisierung (CVSS-Scores, Kontextbewertung) und Prozess (CI/CD-Integration, automatisierte PRs, Testabdeckung). Für KMU gilt: Fangen Sie heute an — auch wenn es zunächst nur `npm audit` und Dependabot sind.
Wer seinen Software-Stack dauerhaft sicher halten möchte, braucht nicht nur das richtige Tooling, sondern auch die richtigen Entwicklungspartner. Pilecode unterstützt Sie bei der Analyse Ihres bestehenden Stacks, der Einführung automatisierter Sicherheitsprozesse und der Entwicklung sicherer, wartbarer Software — von der ersten Zeile Code bis zum laufenden Betrieb. Mehr über unsere Herangehensweise an sichere Softwareentwicklung erfahren Sie in unserer Blog-Übersicht.
Jetzt kostenloses Erstgespräch vereinbaren →
Haben Sie Fragen zu diesem Thema? Jetzt Kontakt aufnehmen.