Dependency Scanning: Schwachstellen in Drittbibliotheken finden

Das Risiko in deinen Abhängigkeiten

Wenn du eine moderne Webanwendung baust, schreibst du einen Bruchteil des Codes selbst. Der Rest kommt aus Drittbibliotheken: Frameworks, Utility-Libraries, ORM-Tools, HTTP-Clients, Logging-Bibliotheken, Kryptografie-Module und hunderte weitere Pakete.

Ein typisches Node.js-Projekt mit Express und einigen gängigen Bibliotheken hat leicht 500 bis 1.000 Abhängigkeiten (einschließlich transitiver Abhängigkeiten, also Abhängigkeiten von Abhängigkeiten). Ein Java-Projekt mit Spring Boot bringt ähnlich viele mit. Jede dieser Bibliotheken kann Schwachstellen enthalten, und du bist dafür verantwortlich, sie zu erkennen und zu beheben.

Prominente Beispiele

Log4Shell (CVE-2021-44228): Eine kritische Schwachstelle in der Java-Logging-Bibliothek Log4j, die Remote Code Execution ermöglichte. Nahezu jede Java-Anwendung war potenziell betroffen, weil Log4j als transitive Abhängigkeit in tausenden anderen Bibliotheken steckte. Viele Unternehmen wussten nicht einmal, dass sie Log4j verwendeten.

Spring4Shell (CVE-2022-22965): Eine Remote-Code-Execution-Schwachstelle in Spring Framework. Weniger kritisch als Log4Shell, aber mit ähnlich breiter Auswirkung auf Java-basierte Webanwendungen.

event-stream (2018): Ein npm-Paket, das von Millionen Projekten verwendet wurde, wurde von einem neuen Maintainer übernommen, der einen Schadcode einschleuste. Ein typischer Supply-Chain-Angriff. Der Code stahl Kryptowährungs-Wallets. Kein CVE, kein bekannter Bug, sondern ein Supply-Chain-Angriff über die Abhängigkeitskette.

ua-parser-js (2021): Ein weiteres populäres npm-Paket (7 Millionen Downloads pro Woche), bei dem kompromittierte Versionen veröffentlicht wurden, die Kryptominer und Passwort-Stealer enthielten.

Diese Beispiele zeigen zwei verschiedene Risiken: bekannte Schwachstellen in legitimer Software (Log4Shell, Spring4Shell) und Supply-Chain-Angriffe, bei denen bösartiger Code in vertrauenswürdige Pakete eingeschleust wird (event-stream, ua-parser-js).

Was Dependency Scanning ist

Dependency Scanning ist der automatisierte Prozess, alle Abhängigkeiten deiner Software (direkte und transitive) zu identifizieren und gegen Datenbanken bekannter Schwachstellen abzugleichen.

Der Prozess

1. Abhängigkeiten identifizieren: Das Tool liest die Abhängigkeitsdefinitionen deines Projekts (package.json und package-lock.json für Node.js, pom.xml oder build.gradle für Java, composer.json und composer.lock für PHP, requirements.txt oder poetry.lock für Python, go.sum für Go) und erstellt einen vollständigen Abhängigkeitsbaum, einschließlich aller transitiven Abhängigkeiten.

2. Schwachstellen abgleichen: Die identifizierten Abhängigkeiten und deren Versionen werden gegen Schwachstellendatenbanken abgeglichen. Die wichtigsten Datenbanken sind NVD (National Vulnerability Database) des NIST, die die offizielle US-Schwachstellendatenbank mit CVE-Einträgen (Common Vulnerabilities and Exposures) enthält, GitHub Advisory Database, die eine von der Community gepflegte Datenbank mit sprachspezifischen Schwachstellen bereitstellt, und OSV (Open Source Vulnerability Database) von Google, die ein aggregiertes Format bietet, das mehrere Datenbanken zusammenfasst.

3. Ergebnisse bewerten: Für jede gefundene Schwachstelle liefert das Tool den CVE-Identifier, den CVSS-Score (Schweregrad von 0 bis 10), eine Beschreibung der Schwachstelle, die betroffene Version und die erste gefixte Version (falls vorhanden).

4. Beheben: Aktualisiere die betroffene Bibliothek auf eine Version, die die Schwachstelle behebt. Wenn kein Fix verfügbar ist: Risiko bewerten und ggf. Workaround implementieren oder die Bibliothek ersetzen.

Tools im Vergleich

Dependabot (GitHub)

Dependabot ist in GitHub integriert und erkennt Schwachstellen in den Abhängigkeiten deiner Repositories. Es erstellt automatisch Pull Requests mit Updates für verwundbare Bibliotheken.

Stärken: Kostenlos für alle GitHub-Repositories (öffentlich und privat), keine Installation oder Konfiguration nötig (einfach aktivieren), automatische Pull Requests mit Changelog und Kompatibilitäts-Hinweisen, unterstützt alle gängigen Paketmanager (npm, pip, Maven, Gradle, Composer, Bundler, Go Modules, Cargo und weitere), Security Alerts mit CVSS-Score und Patch-Empfehlung.

Schwächen: Nur auf GitHub verfügbar (nicht für GitLab, Bitbucket oder selbst gehostete Git-Server), begrenzte Konfigurierbarkeit für komplexe Mono-Repos, keine Erreichbarkeitsanalyse (zeigt nicht, ob die verwundbare Funktion tatsächlich in deinem Code aufgerufen wird), keine Unterstützung für Container-Image-Scanning.

Geeignet für: Teams, die GitHub verwenden und eine unkomplizierte, kostenlose Lösung suchen.

Renovate

Renovate ist ein Open-Source-Tool für automatisierte Dependency-Updates. Es ist flexibler als Dependabot und unterstützt mehr Plattformen.

Stärken: Unterstützt GitHub, GitLab, Bitbucket, Azure DevOps und selbst gehostete Git-Server, hochgradig konfigurierbar (Automerge für Patch-Updates, Gruppierung von Updates, benutzerdefinierte Zeitpläne), Unterstützung für Lock-File-Maintenance, erkennt und aktualisiert auch Docker-Image-Tags, Terraform-Module und Helm-Chart-Versionen, Mend.io (ehemals WhiteSource) bietet eine gehostete Version als SaaS.

Schwächen: Höherer initialer Konfigurationsaufwand als Dependabot, Schwachstellen-Erkennung ist weniger prominent als das Update-Management (Renovate ist primär ein Update-Tool, kein Security-Scanner).

Geeignet für: Teams mit komplexen Setups (Mono-Repos, Multi-Plattform) oder solche, die nicht auf GitHub sind.

Snyk

Snyk ist ein kommerzielles Sicherheitstool, das Dependency Scanning, Container-Scanning, SAST und Infrastructure-as-Code-Scanning kombiniert.

Stärken: Erreichbarkeitsanalyse (zeigt, ob die verwundbare Funktion tatsächlich in deinem Code aufgerufen wird, was die Priorisierung erheblich verbessert), Fix-Empfehlungen mit minimaler Versionsänderung (nicht immer das neueste Major-Update, sondern die kleinste Änderung, die die Schwachstelle behebt), CLI-Integration für lokale Scans, IDE-Plugins (VSCode, IntelliJ), umfangreiche Datenbank mit proprietären Schwachstellendaten (zusätzlich zu NVD), Container-Image-Scanning.

Schwächen: Die kostenlose Version ist auf 200 Tests pro Monat begrenzt, die erweiterten Features (Erreichbarkeitsanalyse, benutzerdefinierte Policies) sind kostenpflichtig, Vendor-Lock-in (proprietäre Datenbank und Priorisierungs-Engine).

Kosten: Free Tier für Open-Source-Projekte und kleine Teams. Team-Plan ab ca. 52 USD pro Monat pro Entwickler.

Geeignet für: Teams, die eine umfassende Sicherheitsplattform mit guter Priorisierung suchen und bereit sind, dafür zu bezahlen.

Trivy

Trivy ist ein Open-Source-Sicherheitsscanner von Aqua Security, der Schwachstellen in Container-Images, Dateisystemen, Git-Repositories und Kubernetes-Clustern findet.

Stärken: Open Source und kostenlos, scannt Abhängigkeiten, Container-Images und Infrastructure-as-Code mit einem einzigen Tool, schnell und leichtgewichtig, gute CI/CD-Integration (GitHub Actions, GitLab CI), unterstützt SBOM-Generierung im SPDX- und CycloneDX-Format.

Schwächen: Weniger ausgefeilte Priorisierung als Snyk (keine Erreichbarkeitsanalyse), keine automatischen Pull Requests (reiner Scanner, kein Update-Tool), weniger IDE-Integration.

Geeignet für: Teams, die ein vielseitiges Open-Source-Tool für Container- und Dependency-Scanning suchen.

OWASP Dependency-Check

OWASP Dependency-Check ist ein Open-Source-Tool, das speziell für die Erkennung von Schwachstellen in Projektabhängigkeiten entwickelt wurde.

Stärken: Open Source und kostenlos, gute Unterstützung für Java/Maven und .NET/NuGet, detaillierte HTML-Berichte, Jenkins-Plugin verfügbar.

Schwächen: Höhere False-Positive-Rate als kommerzielle Tools, langsamere Scans (lädt die NVD-Datenbank bei jedem Scan herunter, wenn nicht gecacht), weniger gute Unterstützung für Node.js und Python im Vergleich zu Snyk oder Trivy.

Geeignet für: Java- und .NET-Teams, die ein kostenloses, etabliertes Tool suchen.

Dependency Scanning in die CI/CD-Pipeline integrieren

Die effektivste Nutzung von Dependency Scanning ist die Integration in die CI/CD-Pipeline als Teil des Secure Development Lifecycle. Jeder Commit oder Pull Request wird automatisch gescannt, und bei kritischen Schwachstellen wird der Build abgebrochen.

Implementierungsstrategie

Phase 1: Sichtbarkeit schaffen (Woche 1). Aktiviere Dependency Scanning für alle Repositories. Bei GitHub: Dependabot aktivieren (ein Klick). Bei GitLab: GitLab Dependency Scanning aktivieren. Bei anderen Plattformen: Trivy oder Snyk in die Pipeline integrieren. Ziel: Du weißt, welche Schwachstellen in deinen Projekten existieren.

Phase 2: Priorisieren (Woche 2-3). Bewerte die gefundenen Schwachstellen. Nicht jede Schwachstelle erfordert sofortiges Handeln. Priorisiere nach CVSS-Score (9.0-10.0: sofort beheben, 7.0-8.9: innerhalb einer Woche, 4.0-6.9: innerhalb eines Monats, unter 4.0: im nächsten regulären Update-Zyklus), nach Erreichbarkeit (wird die verwundbare Funktion in deinem Code tatsächlich aufgerufen?) und nach Verfügbarkeit eines Fixes (gibt es eine gefixte Version?).

Phase 3: Quality Gate einführen (Woche 3-4). Definiere eine Policy: "Kein Merge in den Hauptbranch, wenn kritische oder hohe Schwachstellen vorhanden sind." Konfiguriere die Pipeline so, dass sie bei kritischen Findings fehlschlägt. Erlaube Ausnahmen (Exceptions) für Schwachstellen, die nicht behebbar sind (kein Fix verfügbar), aber dokumentiere die Ausnahmen und überprüfe sie regelmäßig.

Phase 4: Automatisierung ausbauen (laufend). Aktiviere Automerge für Patch-Updates (z.B. 1.2.3 zu 1.2.4), die von Dependabot oder Renovate vorgeschlagen werden, sofern alle Tests bestehen. Das hält deine Abhängigkeiten aktuell, ohne manuellen Aufwand.

SBOM: Software Bill of Materials

Eine SBOM ist ein maschinenlesbares Inventar aller Softwarekomponenten, die in einer Anwendung enthalten sind, einschließlich Bibliotheken, Frameworks, Plugins und deren Versionen und Lizenzen.

Warum SBOMs wichtig werden

Die US-Regierung hat mit Executive Order 14028 (2021) SBOMs für Software, die an Bundesbehörden geliefert wird, verpflichtend gemacht. Die EU folgt mit dem Cyber Resilience Act (CRA), der SBOMs für Produkte mit digitalen Elementen fordert. NIS2 fordert Supply-Chain-Sicherheit, und SBOMs sind ein wesentliches Instrument dafür.

Auch ohne regulatorische Pflicht sind SBOMs nützlich: Wenn eine neue Schwachstelle wie Log4Shell bekannt wird, kannst du mit einer SBOM innerhalb von Minuten feststellen, welche deiner Anwendungen betroffen sind. Ohne SBOM musst du jedes Repository einzeln durchsuchen.

SBOM-Formate

Die zwei etablierten Formate sind SPDX (Software Package Data Exchange), entwickelt von der Linux Foundation, ISO-Standard (ISO/IEC 5962:2021), fokussiert auf Lizenz-Compliance und Softwarekomposition, und CycloneDX, entwickelt von OWASP, fokussiert auf Sicherheit und Schwachstellen-Tracking, unterstützt auch Hardware- und Service-Komponenten.

Beide Formate sind in JSON und XML verfügbar und werden von den gängigen Tools unterstützt.

SBOM generieren

Syft (von Anchore, Open Source) generiert SBOMs aus Dateisystemen, Container-Images und Archiven. Unterstützt SPDX und CycloneDX. Beispiel: syft dir:. -o cyclonedx-json > sbom.json.

Trivy kann neben Schwachstellen-Scans auch SBOMs generieren: trivy fs --format cyclonedx -o sbom.json ..

CycloneDX-Plugins gibt es für Maven (cyclonedx-maven-plugin), npm (@cyclonedx/cyclonedx-npm), Python (cyclonedx-bom) und weitere Ökosysteme.

Generiere die SBOM in der CI/CD-Pipeline bei jedem Build und archiviere sie. So hast du für jede Version deiner Software eine vollständige Komponentenliste.

Transitive Abhängigkeiten: Das unsichtbare Risiko

Die größte Herausforderung beim Dependency Scanning sind transitive Abhängigkeiten: Bibliotheken, die du nicht direkt einbindest, die aber als Abhängigkeit deiner Abhängigkeiten mitgeliefert werden.

Du verwendest Bibliothek A, die von Bibliothek B abhängt, die von Bibliothek C abhängt. Wenn Bibliothek C eine Schwachstelle hat, bist du betroffen, obwohl du Bibliothek C nie bewusst eingebunden hast und sie möglicherweise nicht einmal kennst.

Umgang mit transitiven Schwachstellen

Lock-Files verwenden: Lock-Files (package-lock.json, composer.lock, poetry.lock, go.sum) fixieren die exakten Versionen aller Abhängigkeiten, einschließlich transitiver. Ohne Lock-File kann jeder Build unterschiedliche Versionen herunterladen.

Transitive Abhängigkeiten überschreiben: Die meisten Paketmanager erlauben es, transitive Abhängigkeiten explizit auf eine bestimmte Version zu pinnen. In npm: overrides in package.json. In Maven: dependencyManagement. In Gradle: resolutionStrategy. Nutze das, um verwundbare transitive Abhängigkeiten auf eine gefixte Version zu zwingen, auch wenn die direkte Abhängigkeit sie noch nicht aktualisiert hat.

Abhängigkeitsbaum regelmäßig ausdünnen: Entferne nicht mehr benötigte direkte Abhängigkeiten. Jede entfernte direkte Abhängigkeit eliminiert auch deren transitive Abhängigkeiten. Prüfe regelmäßig, ob es schlankere Alternativen gibt: Brauchst du wirklich Lodash, oder reichen die nativen JavaScript-Methoden?

False Positives und Priorisierung

Dependency-Scanning-Tools produzieren False Positives: Schwachstellen, die in deinem spezifischen Kontext nicht ausnutzbar sind. Eine Schwachstelle in einer Funktion, die du nie aufrufst, ist theoretisch ein Risiko (der Code ist vorhanden), aber praktisch weniger dringend als eine Schwachstelle in einer Funktion, die bei jedem Request ausgeführt wird.

Umgang mit False Positives

Erreichbarkeitsanalyse nutzen: Snyk und einige andere Tools bieten eine Erreichbarkeitsanalyse, die prüft, ob die verwundbare Funktion in deinem Code-Pfad liegt. Das reduziert die Anzahl der relevanten Findings erheblich.

Exceptions dokumentieren: Wenn du eine Schwachstelle als nicht relevant einstufst (z.B. weil die verwundbare Funktion in deinem Kontext nicht erreichbar ist), dokumentiere diese Entscheidung. Tools wie Snyk und Trivy unterstützen Ignore-Dateien mit Begründungen und Ablaufdatum.

Regelmäßig überprüfen: Exceptions sollten ein Ablaufdatum haben (z.B. 90 Tage). Danach wird die Schwachstelle erneut bewertet: Gibt es inzwischen einen Fix? Hat sich der Code geändert?

Dependency Scanning und regulatorische Anforderungen

NIS2

NIS2 Artikel 21 Absatz 2 Buchstabe e fordert "Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen". Dependency Scanning ist ein direkter Beitrag zum Schwachstellenmanagement. Absatz 2 Buchstabe d fordert die "Sicherheit der Lieferkette". SBOMs und Dependency Scanning adressieren die Software-Supply-Chain-Komponente.

ISO 27001

Annex A, Kontrolle A.8.9 (Configuration management), fordert die Verwaltung der Konfiguration von Hardware, Software und Diensten. Ein SBOM ist Teil der Softwarekonfigurationsdokumentation. Kontrolle A.8.8 (Management of technical vulnerabilities) fordert, dass technische Schwachstellen zeitnah identifiziert und behoben werden. Der Aufbau eines Schwachstellenmanagements ist die organisatorische Grundlage dafür. Dependency Scanning ist das Werkzeug dafür.

Cyber Resilience Act (CRA)

Der CRA fordert für Produkte mit digitalen Elementen eine SBOM und ein dokumentiertes Schwachstellenmanagement. Dependency Scanning und SBOM-Generierung in der CI/CD-Pipeline sind die technische Umsetzung.

Vom Tool zum Prozess

Dependency Scanning ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Scans laufen bei jedem Commit und zusätzlich regelmäßig (täglich oder wöchentlich) auf den Hauptbranch. Neue Schwachstellen werden bewertet und priorisiert. Kritische Schwachstellen werden innerhalb definierter Fristen behoben. Exceptions werden dokumentiert und regelmäßig überprüft. SBOMs werden bei jedem Release generiert und archiviert. Der Prozess wird im Rahmen des ISMS dokumentiert und bei Audits nachgewiesen.

Wenn du diesen Prozess etabliert hast, bist du gegen die häufigsten Software-Supply-Chain-Risiken gut geschützt und erfüllst gleichzeitig wesentliche Anforderungen von NIS2, ISO 27001 und dem Cyber Resilience Act. In ISMS Lite lässt sich dein Dependency-Scanning-Verfahren mit Schwachstellenbewertungen, SLAs und Ausnahmen dokumentieren und für Audits aufbereiten.

Häufige Fehler beim Dependency Scanning

Nur direkte Abhängigkeiten prüfen. Viele Teams aktualisieren nur die Bibliotheken, die sie direkt einbinden, und vergessen die transitiven Abhängigkeiten. Log4Shell hat gezeigt, dass die verwundbare Bibliothek oft mehrere Ebenen tief in der Abhängigkeitskette steckt. Verwende Tools, die den gesamten Abhängigkeitsbaum analysieren.

Findings ignorieren, weil es zu viele sind. Beim erstmaligen Scan eines älteren Projekts kommen oft hunderte Findings. Die Versuchung ist groß, das Thema zu vertagen. Starte stattdessen mit den kritischen und hohen Findings (CVSS 7.0 und höher) und arbeite dich schrittweise vor. Lieber 20 kritische Schwachstellen beheben als 200 auf der Liste zu lassen, weil die Masse entmutigend wirkt.

Keine Zeitvorgaben für die Behebung. Ohne definierte Fristen bleiben Findings in der Liste stehen. Definiere SLAs: Kritisch (CVSS 9.0+) innerhalb von 48 Stunden, Hoch (CVSS 7.0-8.9) innerhalb von 7 Tagen, Mittel (CVSS 4.0-6.9) innerhalb von 30 Tagen.

Lock-Files nicht committen. Ohne Lock-File im Repository kann jeder Build unterschiedliche Versionen herunterladen. Das macht Dependency Scanning unzuverlässig und führt zu nicht reproduzierbaren Builds. Committe Lock-Files immer ins Repository.

Veraltete Projekte vergessen. Ältere Anwendungen, die noch in Produktion laufen, aber nicht mehr aktiv weiterentwickelt werden, bekommen keine Dependency-Updates. Sie werden zu tickenden Zeitbomben. Integriere auch Wartungsprojekte in den regelmäßigen Scan-Zyklus und verknüpfe die Ergebnisse mit deinem Patch-Management.

Weiterführende Artikel

• Secure Development Lifecycle (SDL): Sicherheit in den Entwicklungsprozess einbauen
• OWASP Top 10 für Entwickler: Die häufigsten Schwachstellen vermeiden
• Schwachstellenmanagement aufbauen: Vom Scan zur Behebung
• Supply-Chain-Angriffe: So schützt du dein Unternehmen
• Patch-Management im Mittelstand: Von der Schwachstelle zum Update