Deine CVE ist erreichbar. Aber lässt sie sich ausnutzen?

Jedes SCA -Tool, das etwas auf sich hält, verfügt heutzutage über Erreichbarkeitsanalyse . Wenn eine Abhängigkeit eine bekannte Sicherheitslücke aufweist, können diese Tools Ihnen mitteilen, ob Ihr Code die betroffene Funktion aufruft. Dies ist so gut wie unverzichtbar, da es Teams dabei hilft, ihre Sicherheitsmaßnahmen gezielt auszurichten, anstatt sich durch irrelevante Informationen zu wühlen. Jeder weitere Schritt bei der Priorisierung von CVEs in Abhängigkeiten baut darauf auf.

Doch nur weil die anfällige Funktion erreichbar ist, bedeutet das noch lange nicht, dass sie ausnutzbar ist . Erreichbarkeit bedeutet, dass Ihr Code die anfällige Funktion ausführen kann, während Ausnutzbarkeit bedeutet, dass ein Angreifer die notwendigen Bedingungen erfüllen kann, die der Fehler benötigt, um Schaden anzurichten.

Daher müssen Entwicklerteams, die nur über „ Erreichbarkeitsanalyse “ verfügen, weiterhin entweder manuell nachverfolgen, welche CVEs tatsächlich ein Problem darstellen, oder herausfinden, welche Befunde am dringendsten sind. Viele Teams verzichten gänzlich auf die manuelle „ triage “ und patchen einfach alles, was einen bestimmten CVSS-Schwellenwert überschreitet – und genau daraus resultieren der „Lärm“ und der unnötige Aufwand.

Schauen wir uns einmal an, wie „ Ausnutzbarkeitsanalyse “ „ Erreichbarkeitsanalyse “ weiterentwickelt.

Was ist „ Erreichbarkeitsanalyse “?

Die meisten Teams stufen CVEs nach dem CVSS-Schweregrad ein, häufig anhand der Standardbezeichnungen, die ihre Sicherheitstools anzeigen, und manche fügen zusätzlich EPSS und KEV hinzu (Erläuterungen zu den Abkürzungen finden Sie im Glossar am Ende). Diese Kennzahlen beschreiben die CVE allgemein und weisen jeder Anwendung, die das Paket nutzt, dieselbe Bewertung zu; sie sagen also nichts darüber aus, wie sich die CVE in Ihrem Code verhält.

Erreichbarkeitsanalyse prüft, ob Ihr Code die anfällige Funktion in einer Abhängigkeit ausführen kann, in der Regel indem die Aufrufe Ihres Codes in seine Abhängigkeiten als Aufrufgraph dargestellt werden. Wenn eine anfällige Funktion niemals aufgerufen wird, entsteht praktisch kein Schaden (es sei denn, die App ändert sich). 

Vor der Einführung von Erreichbarkeitsanalyse und SCA meldeten die Tools jede CVE in jeder Abhängigkeit, einschließlich transitiver Pakete, die Ihr Code gar nicht aufrief. Die Teams patchten entweder alles, was einen bestimmten CVSS-Schwellenwert überschritt, oder führten eine manuelle Priorisierung durch. Reachability hat dies geändert, indem es jeden Befund mit Ihrem tatsächlichen Code verknüpfte, sodass Entwickler ihre Zeit auf Befunde konzentrieren konnten, die in der Produktion wirklich von Bedeutung sind. Dadurch wurde aus einer Warteschlange mit Abhängigkeitswarnungen eine Liste, die sie tatsächlich abarbeiten konnten.

Die Erreichbarkeit funktioniert auf zwei Ebenen. 

• Die Erreichbarkeitsprüfung auf Abhängigkeitsebene überprüft, ob Ihr Code das anfällige Paket überhaupt importiert oder verwendet. Dadurch werden Pakete herausgefiltert, die lediglich als ungenutzte transitive Abhängigkeiten in Ihrer Lock-Datei enthalten sind. 
• Die Erreichbarkeit auf Funktionsebene geht noch einen Schritt weiter und prüft, ob Ihr Code die spezifische Funktion aufruft, die den Fehler enthält. So wird eine App, die lediglich eine XML-Bibliothek zur Erstellung von Dokumenten nutzt, hinsichtlich eines CVE im Parser dieser Bibliothek als fehlerfrei eingestuft.

Warum erreichbarer Code dennoch sicher sein kann

Erreichbarer Code ist jedoch nicht zwangsläufig ausnutzbar. Erreichbarer Code kann dennoch sicher sein, wenn ein Angreifer die Bedingungen, die für das Auslösen des Fehlers erforderlich sind, nicht erfüllen kann. Bei den meisten Schwachstellen reicht es nicht aus, dass die Funktion ausgeführt wird. Es bedarf einer vom Angreifer kontrollierten Eingabe in einer bestimmten Form, einer bestimmten Konfiguration oder einer aktivierten Funktion, einer bestimmten Berechtigungsstufe oder einer Bereitstellungsumgebung, in der das Ergebnis tatsächlich Schaden anrichten kann.

In der Liste der Begründungen für den VEX-Status (Vulnerability Exploitability eXchange) der CISA werden „anfälliger Code, der nicht im Ausführungspfad liegt“ und „anfälliger Code, der nicht vom Angreifer kontrolliert werden kann“ als separate Gründe dafür aufgeführt, dass ein Produkt nicht betroffen ist. Der erste Punkt beschreibt eine Beurteilung der Erreichbarkeit, der zweite eine Beurteilung der Ausnutzbarkeit.

Was macht eine CVE in einer App ausnutzbar?

Ein Exploit setzt in der Regel voraus, dass mehrere Bedingungen gleichzeitig erfüllt sind. Fehlt also eine davon in Ihrer App, schlagen Angriffe fehl. CVSS erfasst einige dieser Bedingungen in seinen Metriken zur Ausnutzbarkeit, wie beispielsweise erforderliche Berechtigungen und Benutzerinteraktion. Das tatsächliche Risiko Ihrer App kann deutlich über oder unter dem veröffentlichten Wert liegen.

Erreichbarkeit vs. Ausnutzbarkeit in einem Lodash-CVE

CVE-2021-23337 Es handelt sich um eine Befehlsinjektion in der JavaScript-Hilfsbibliothek Lodash. Die Sicherheitslücke befindet sich in Lodashs _.template betrifft Versionen vor 4.17.21. lodash fügt einen Wert in den Quellcode der Funktion ein, ohne ihn zu bereinigen. Ein Angreifer, der diese Option kontrolliert, kann daher anstelle eines Variablennamens Code übergeben und diesen beim Kompilieren der Vorlage ausführen.

Diese CVE hat einen CVSS-Wert von 7,2 und – Stand Oktober 2026 – einen EPSS-Wert von etwa 21 %, was höher ist als bei 97 % der bewerteten CVEs. Sie ist nicht in KEV enthalten. Diese Zahlen sehen beängstigend aus, aber diese Informationen sind natürlich völlig unabhängig vom Kontext Ihrer App. 

Schauen wir uns drei Apps an, die alle auf einer anfälligen Lodash-Version basieren, sich jedoch hinsichtlich ihrer Verbreitung und Ausnutzbarkeit unterscheiden.

• App A ruft nie an _.template und nutzt ausschließlich Inkassodienste wie Karte und Filter. Erreichbarkeitsanalyse kann diesen Befund außer Acht lassen, da die anfällige Funktion niemals ausgeführt wird.
• App B ruft an _.template um eine E-Mail zu generieren, wobei die Vorlagenzeichenfolge und die Optionen vom Entwickler fest codiert wurden. Reachability meldet dies als Sicherheitslücke, da die Funktion bei jeder Anfrage ausgeführt wird. Ein Angreifer kann die Variable „option“ jedoch nicht beeinflussen, sodass Ausnutzbarkeitsanalyse den Schweregrad des Befunds unter Angabe einer Begründung herabstufen kann.
• App C verteilt die Anfragedaten auf die Vorlagenoptionen. Die Funktion ist erreichbar, und die Eingaben des Angreifers gelangen in die Variable „option“, sodass die Schwere des Befunds hoch bleibt. „ Ausnutzbarkeitsanalyse “ würde die Schwere oder Priorität des Problems erhöhen.

Ein und dieselbe CVE erfordert je nach Anwendung unterschiedliche Maßnahmen. 

Die Ausnutzbarkeit kann sich ändern, wenn sich Ihr Code ändert

Wenn ein Tool zur Erkennung von Schwachstellen ( Ausnutzbarkeitsanalyse ) angibt, dass Ihr Code „nicht ausnutzbar“ ist, bezieht sich dies lediglich auf den aktuellen Stand Ihres Codes und Ihrer Bereitstellung. Ein neuer Aufrufort, ein neuer Eingabepfad, eine Konfigurationsänderung oder eine Aktualisierung des Basis-Images können diese Einschätzung jedoch auf den Kopf stellen.

Lodashs Korrektur aus dem Jahr 2021 fügte eine Validierung für die Option „variable“ hinzu, übersah jedoch options.imports Schlüsselnamen, die in dasselbe einfließen Function() Konstruktor. Dieser zweite Pfad wurde als CVE-2026-4800 identifiziert und in Lodash 4.18.0 behoben.

Im zuvor genannten Beispiel könnte also eine Prototyp-Verunreinigung an einer anderen Stelle in der Anwendung die Ausnutzbarkeit von App B verändern. Durch Prototyp-Verunreinigung kann ein Angreifer Eigenschaften zu Object.prototype (von dem – falls Sie kein JS-Entwickler sind – fast jedes JavaScript-Objekt erbt). _.template kopiert geerbte Eigenschaften in Importe, sodass ein Fehler durch Prototyp-Verunreinigung an einer beliebigen anderen Stelle in App B einem Angreifer diesen Pfad eröffnen könnte, ohne dass Änderungen an App B erforderlich wären. _.template Code.

So prüft „ Aikido “ die Ausnutzbarkeit von CVEs

AikidoDer CVE- Ausnutzbarkeitsanalyse liest den Code des Repositorys zusammen mit dem verknüpften container Kontext, einschließlich des Dockerfiles, des Basis-Images, der Distribution und der Art und Weise, wie das container ausgeführt wird. Er nutzt denAikido Agent, der analysiert, wie das anfällige Paket in Ihrem Code oder container Image verwendet wird, und entscheidet, ob der Befund in Ihrer Umgebung ausnutzbar ist. Der Agent führt dann die von Ihnen genehmigten triage Maßnahmen durch, darunter „Ignorieren“, „Zurückstellen“, „Downgrade“ oder „Upgrade“. Jede Entscheidung wird mit einer schriftlichen Begründung des Agenten versehen, die der Prüfer vor der Genehmigung einsehen kann.

Bevor eine angreifbare CVE in die Rangliste aufgenommen wird, muss zunächst ermittelt werden, ob Angreifereingaben den anfälligen Parameter erreichen können und wie Ihre Konfiguration und Bereitstellung aussehen müssen, damit der Fehler ausgelöst wird. CVE Ausnutzbarkeitsanalyse führt diese Überprüfung für jede betroffene CVE durch und dokumentiert die Begründung für jedes Ergebnis.

Sie können die CVE- Ausnutzbarkeitsanalyse en für Ihre Repositorys und verknüpften Container über die Einstellungen unter „ Triage “ auf Aikido aktivieren. Die Einrichtungsanleitung führt Sie Schritt für Schritt durch die Auswahl eines Geltungsbereichs und der Aktionen, die der Agent ausführen kann.

FAQ

Was ist ein CVE?

Eine CVE (Common Vulnerabilities and Exposures) ist eine eindeutige Kennung für eine öffentlich bekannt gegebene Sicherheitslücke, wie beispielsweise CVE-2021-23337. Das CVE-Programm wird von MITRE betrieben, und autorisierte Organisationen, sogenannte „CVE Numbering Authorities“, vergeben die Kennungen, sodass jedes Tool und jeder Sicherheitshinweis unter demselben Namen auf dieselbe Sicherheitslücke verweisen kann.

Was ist CVSS?

CVSS (Common Vulnerability Scoring System) bewertet den Schweregrad einer Sicherheitslücke auf einer Skala von 0 bis 10, basierend auf der Schwachstelle selbst. FIRST verwaltet den Standard, der mittlerweile in der Version 4.0 vorliegt, und die Bewertungen werden den Schweregraden von „gering“ bis „kritisch“ zugeordnet. Ein CVSS-Wert beschreibt die Sicherheitslücke allgemein und kann daher nicht berücksichtigen, wie Ihre App den betroffenen Code nutzt.

Was ist EPSS?

Das EPSS (Exploit Prediction Scoring System) schätzt die Wahrscheinlichkeit ein, dass eine CVE in den nächsten 30 Tagen irgendwo in der Praxis ausgenutzt wird. FIRST veröffentlicht für jede veröffentlichte CVE einen Wert zwischen 0 und 1 und aktualisiert diesen täglich. Ein hoher EPSS-Wert deutet auf Interesse von Angreifern im Internet hin, sagt jedoch nichts darüber aus, ob Ihre eigene App gefährdet ist.

Was ist KEV?

KEV ist der Katalog der CISA für bekannte, ausgenutzte Sicherheitslücken (Known Exploited Vulnerabilities), eine Liste von CVEs, deren Ausnutzung in der Praxis bestätigt wurde. US-Bundesbehörden müssen die im KEV aufgeführten CVEs gemäß der verbindlichen Betriebsrichtlinie 22-01 innerhalb festgelegter Fristen beheben, und die CISA empfiehlt allen Organisationen, den Katalog zur Priorisierung von Patches zu nutzen. Stand Oktober 2026 umfasst er etwa 1.700 CVEs.