Sichere Abhängigkeiten

  • 5 Minuten

Ein großer Prozentsatz des Codes in modernen Anwendungen besteht aus den Bibliotheken und Abhängigkeiten, die Sie als Entwickler*in auswählen. Die Verwendung von Drittanbieterkomponenten ist eine gängige Praxis, die Zeit und Geld spart. Der Nachteil: Obwohl der Code von jemand anderem geschrieben wurde, sind Sie, da Sie ihn in Ihrem Projekt verwendet haben, jetzt dafür verantwortlich. Wenn Sicherheitsexpert*innen (oder schlimmer noch Hacker*innen) ein Sicherheitsrisiko in einer dieser Drittanbieterbibliotheken entdecken, wird der Fehler wahrscheinlich auch in Ihrer App vorhanden sein.

Die Verwendung von Komponenten mit bekannten Sicherheitsrisiken ist ein großes Problem in unserer Branche. Sie ist derart problembehaftet, dass sie seit mehreren Jahren in Folge den neunten Platz auf der OWASP-Top-10-Liste der schwerwiegendsten Sicherheitsrisiken in Webanwendungen einnimmt.

Nachverfolgen bekannter Sicherheitsrisiken

Für uns besteht das Problem darin, zu wissen, wann ein Problem erkannt wurde. Bibliotheken und Abhängigkeiten auf dem neuesten Stand zu halten (Nr. 4 auf unserer Liste!), ist natürlich hilfreich. Es empfiehlt sich aber auch, identifizierte Sicherheitsrisiken, die sich auf Ihre Anwendung auswirken können, nachzuverfolgen.

Wichtig

Wenn ein System ein bekanntes Sicherheitsrisiko aufweist, ist die Wahrscheinlichkeit deutlich höher, dass auch Exploits verfügbar sind (d. h. Code, der für Angriffe auf solche Systeme genutzt werden kann). Wenn ein Exploit veröffentlicht wird, ist es entscheidend, dass alle betroffenen Systeme sofort aktualisiert werden.

Mitre ist eine gemeinnützige Organisation, die die Common Vulnerabilities and Exposures (CVE) List (Liste der häufigen Sicherheitsrisiken und Sicherheitslücken) führt. Diese Liste ist eine öffentlich zugängliche durchsuchbare Sammlung von bekannten Cybersicherheitsrisiken in Apps, Bibliotheken und Frameworks. Eine Bibliothek oder Komponente, die Sie in der CVE-Datenbank finden, weist bekannte Sicherheitsrisiken auf.

Probleme werden von der Sicherheitscommunity gemeldet, wenn eine Sicherheitslücke in einem Produkt oder einer Komponente gefunden wird. Jedem veröffentlichten Problem ist eine ID zugewiesen, die das Datum der Entdeckung, eine Beschreibung des Sicherheitsrisikos und Verweise auf veröffentlichte Problemumgehungen oder Angaben des Anbieters zum Problem enthält.

Überprüfen Ihrer Drittanbieterkomponenten auf bekannte Sicherheitsrisiken

Sie könnten eine tägliche Aufgabe auf Ihrem Smartphone einrichten, um diese Liste jeden Tag zu überprüfen. Glücklicherweise gibt es jedoch viele Tools, mit denen überprüft werden kann, ob Abhängigkeiten gefährdet sind. Sie können diese Tools für Ihre Codebasis ausführen oder – noch besser – Ihrer CI/CD-Pipeline hinzufügen, um im Rahmen des Entwicklungsprozesses automatisch zu überprüfen, ob Probleme vorliegen.

  • OWASP Dependency Check – ein Tool, für das ein Jenkins-Plug-In verfügbar ist
  • Snyk ist für Open-Source-Repositorys in GitHub kostenlos.
  • Black Duck: ein Tool, das von vielen Unternehmen verwendet wird
  • Retire.js – ein Tool, mit dem Sie überprüfen können, ob Ihre JavaScript-Bibliotheken veraltet sind (kann als Plug-In für verschiedene Tools verwendet werden, einschließlich Burp Suite)

Sie können auch einige spezielle Tools für die statische Codeanalyse zu diesem Zweck verwenden.

Weitere Informationen zu den Risiken im Zusammenhang mit der Verwendung gefährdeter Komponenten finden Sie auf der OWASP-Seite zu diesem Thema.

Zusammenfassung

Wenn Sie Bibliotheken oder andere Drittanbieterkomponenten als Bestandteil Ihrer Anwendung nutzen, übernehmen Sie auch sämtliche Risiken, die diese möglicherweise aufweisen. Am besten lässt sich dieses Risiko verringern, indem Sie nur Komponenten ohne bekannte Sicherheitsrisiken verwenden.