Über Reachability hinaus: Was wirklich zählt, priorisieren

Die meisten modernen Anwendungen enthalten zahlreiche Open-Source-Pakete, Bibliotheken und Frameworks. Schätzungen zufolge stammen mindestens 80 % des Quellcodes moderner Anwendungen aus Open-Source-Projekten. Entwicklungsteams setzen nicht nur in hohem Maße auf Standardkomponenten, um Anwendungen zu erstellen, sondern stellen diese Apps und Services häufig auch mithilfe von Container-Basis-Images aus der Community bereit. Außerdem greifen sie auf Ressourcen von Drittanbietern zurück, wie etwa KI-Coding-Assistenten, um eigenen Code zu generieren und so die Software-Supply-Chain weiter zu beschleunigen. 

Die stetig zunehmende Nutzung von Open-Source-Bibliotheken, generativer KI und Containern bringt neue Lizenz- und Sicherheitsrisiken mit sich. Allein 2023 wurden fast 29.000 neue Schwachstellen entdeckt (2024 waren es bereits mehr als 28.000). Wenn sich die Geschichte wiederholt, wird mehr als die Hälfte dieser neu entdeckten Schwachstellen einen hohen oder kritischen Schweregrad haben. Anders gesagt: Einige der größten Risiken für Ihre Anwendungen – und möglicherweise für Ihr gesamtes Unternehmen – gehen von Komponenten aus, die Sie nicht kontrollieren.

Die Herausforderungen der Open-Source-Sicherheit heute

Alle Open-Source-Schwachstellen in Ihren Anwendungen zu finden, zu priorisieren und zu beheben, ist unrealistisch. Selbst nur die Schwachstellen mit hohem Schweregrad in Ihren Abhängigkeiten von Drittanbietern zu beheben, kann eine Herausforderung sein. Schließlich müssen Sie nicht nur neu entdeckte Schwachstellen angehen, sondern auch den gesamten Rückstand an Schwachstellen in Ihrer Codebasis. Dieser Rückstand hat verschiedene Ursachen: Vielleicht haben Sie ihn übernommen oder er stammt aus einem Projekt, das schon lange umgesetzt war, bevor Sie mit der Suche nach Open-Source-Schwachstellen begonnen haben.

Selbst kleine Projekte können Hunderte von Schwachstellen in Dutzenden direkten Abhängigkeiten enthalten, die ausdrücklich in den Abhängigkeitsmanifesten definiert sind. Indirekte oder „transitive“ Abhängigkeiten – also Bibliotheken, die von den direkten Abhängigkeiten benötigt werden – gibt es wahrscheinlich noch viel mehr. Multipliziert man all das mit der Anzahl der Projekte in Ihrem Unternehmen, entsteht eine überwältigend lange Liste. 

Statische Priorisierungsmethoden reichen nicht aus

Viele Unternehmen nutzen statische Risikofaktoren wie den NVD-/CVSS-Schweregrad, um diese lange Liste von Schwachstellen zunächst zu sichten und zu entscheiden, welche zuerst behoben werden sollen. Solche Momentaufnahmen des Risikos lassen jedoch viele wichtige Faktoren für eine präzise und wirksame Priorisierung außer Acht. 

Neuere Risikofaktoren wie EPSS (Exploit Prediction Scoring System) versuchen, mehr Informationen über die Schwachstelle einzubeziehen, lassen aber weiterhin wichtige Details wie den übergeordneten Anwendungskontext oder Geschäftskontext außen vor. Wie andere statische Risikofaktoren betrachtet auch EPSS einzelne Probleme isoliert und nur aus einem engen Blickwinkel – nicht Ihre Anwendungen als Ganzes. Jede von EPSS bewertete Schwachstelle bezieht sich auf eine bestimmte CVE und nicht darauf, was Ihr gesamtes Unternehmen am stärksten beeinträchtigt. 

Viele Unternehmen nutzen Reachability, um ihre statischen Priorisierungsmethoden zu ergänzen und besser zu verstehen, welche Schwachstellen zuerst behoben werden sollten. Bei der statischen Reachability wird die Definition der Schwachstelle untersucht und ermittelt, wo sie in einer bestimmten Version einer Bibliothek vorkommt. Anschließend wird versucht festzustellen, ob ein Aufrufpfad von Ihrem eigenen Code zu der Funktion führt, in der sich die Schwachstelle vermutlich befindet. Teams können dann verschiedene statische Signale kombinieren – etwa Reachability-Daten und einen hohen CVSS- oder EPSS-Score –, um zu entscheiden, welche Probleme zuerst behoben werden sollen.

Statische Reachability kann zwar die Priorisierung unterstützen, lässt aber auch Lücken. Sie kann beispielsweise Codepfade identifizieren, die anfällige Funktionen aufrufen. Umgekehrt kann sie jedoch nicht eindeutig feststellen, wann etwas nicht erreichbar ist. Außerdem enthalten nicht alle Schwachstellen die für eine statische Reachability-Analyse erforderlichen Informationen. Es gibt jedoch Methoden, mit denen sich die anfälligen Funktionen in Open-Source-Paketen ermitteln lassen. Snyk nutzt beispielsweise eine KI-gestützte Lösung, die Fix-Commits auswertet, um diese Funktionen zu berechnen. 

Die Kombination statischer Reachability mit CVSS/EPSS verbessert die Priorisierung. Sie lässt sich jedoch weiter optimieren, wenn entscheidender Kontext einbezogen wird: die Bedeutung eines bestimmten Artefakts für das Unternehmen. Um Schwachstellen präzise nach dem tatsächlichen Geschäftsrisiko zu priorisieren, müssen Teams neben der statischen Reachability also auch Kontextfaktoren berücksichtigen.

Unternehmen brauchen einen ganzheitlichen Ansatz zur Risikopriorisierung

Wichtig ist: Ein hoher Schweregrad und Reachability bedeuten nicht automatisch, dass eine Schwachstelle ausnutzbar ist. 

Sehen wir uns das genauer an: Angenommen, Sie haben zwei Schwachstellen – eine kritische, „erreichbare“ Schwachstelle in Ihrer internen Entwicklungs-Sandbox und eine mittelschwere Schwachstelle ohne Reachability-Daten in der Produktionsumgebung. Welche sollten Sie zuerst beheben? Was, wenn die mittelschwere Schwachstelle in der Produktion einen einfachen, weithin bekannten Exploit hat und sich in einem internetexponierten Container am Netzwerkrand befindet? Die mittelschwere Schwachstelle scheint dann eindeutig die richtige Wahl zu sein. Statische Signale allein könnten die Sandbox-Schwachstelle jedoch tatsächlich höher priorisieren!

Dieses Beispiel zeigt, dass statische Reachability oft nicht das ganze Bild liefert. Sie bietet zwar Einblicke in die Priorisierung von Schwachstellen, ermöglicht Teams aber nicht, das Gesamtrisiko zu steuern. Eine große Zahl kritischer Schwachstellen zu beheben, mag auf dem Papier gut aussehen. Entscheidend ist jedoch, jene Schwachstellen zu beseitigen, die Ihrem Unternehmen und seinem Geschäftsergebnis am meisten schaden können.

Die folgenden zusätzlichen Signale können die Lücken schließen, die statische Reachability lässt: 

• Ist die Schwachstelle überhaupt für das Betriebssystem relevant, auf dem der Service läuft?

• Ist die Anwendung geschäftskritisch? Welche konkrete Rolle spielt sie, und wie hängt sie mit den zentralen Geschäftsfunktionen zusammen?

• Ist die Anwendung bereitgestellt? Wenn ja, wo? Ist sie öffentlich zugänglich oder erreichbar, und sind die Pakete geladen?

• Hat der Service, in dem sich die Schwachstelle befindet, Zugriff auf vertrauliche Daten?

Kontextbasierte, risikoorientierte Priorisierung mit Snyk

Da Unternehmen nicht alle Open-Source-Schwachstellen – und auch nicht alle Schwachstellen mit hohem oder kritischem Schweregrad – beheben können, ist es entscheidend, Sicherheitsprobleme richtig zu priorisieren. Snyk unterstützt Unternehmen nicht nur dabei, Softwareschwachstellen zu finden und zu beheben, sondern auch dabei, die Behebung nach dem realen Risiko für das Unternehmen zu priorisieren. Unsere Lösungen stärken die Anwendungssicherheitsprozesse von Unternehmen mit folgenden Funktionen: 

• Risikobasierte Priorisierung hilft Unternehmen, die Wahrscheinlichkeit, dass eine Schwachstelle ausgenutzt wird, und die möglichen Folgen klar einzuschätzen.

• Reachability vom Code bis zur Cloud umfasst sowohl die statische Reachability, bei der Code und anfällige Funktionen analysiert werden, als auch die dynamische Reachability, die die bereitgestellte Anwendung und ihre Laufzeitumgebung untersucht. Unsere KI-gestützte Lösung wird von menschlichen Sicherheitsexperten validiert und sorgt so für höhere Genauigkeit und Abdeckung.

• Anwendungskontext aus SCMs, Entwicklerportalen, CMDBs und weiteren Quellen. Dieser detaillierte Kontext hilft Unternehmen, die relevanten Schwachstellen weiter einzugrenzen – etwa anhand der Code-Verantwortlichkeit, der Aktualität von Repositories und anderer Faktoren.

• Flexibilität für Unternehmen dank der Möglichkeit, proprietäre Sicherheits- und Compliance-Richtlinien direkt in die Snyk-Lösung zu integrieren.

• Ganzheitlicher Risiko-Score, der sich einfach für Ihre AppSec-Maßnahmen nutzen lässt. Mit diesen Scores können Sie SCA-Probleme in Ihrer gesamten Umgebung priorisieren oder einzelne Risikofaktoren wie die statische Reachability genauer untersuchen.

Erfahren Sie, wie Snyk AppRisk funktioniert: Sehen Sie sich unsere Demo auf Abruf an.