Erreichbarkeitsanalyse in SCA: Funktionsweise und Grenzen

Warum es sie gibt

Ein SCA-Scan gleicht Paketversionen mit Advisories ab. Er weiß, dass eine Version einen Fehler enthält, aber nicht, ob Ihre Anwendung den betroffenen Teil nutzt. Eine Bibliothek mit Hunderten Funktionen und einem verwundbaren Parser wird gleich gemeldet, ob Sie diesen Parser aufrufen oder nicht, und über einen großen Abhängigkeitsbaum summiert sich das zu einem Backlog, das niemand abarbeiten kann.

So funktioniert die Erreichbarkeitsanalyse

Den verwundbaren Code finden. Das Tool muss wissen, in welcher Funktion eine Schwachstelle sitzt. Advisories sagen das oft nicht, deshalb pflegen Anbieter eigene Daten.
Einen Aufrufgraphen erstellen. Es bildet ab, welche Funktionen welche aufrufen, von Ihrem Code bis hinunter in die Abhängigkeiten.
Nach einem Pfad suchen. Führt eine Aufrufkette von Ihrem Code zur verwundbaren Funktion, ist der Befund erreichbar. Falls nicht, wird er als nicht erreichbar markiert und niedriger eingestuft.

Stufen der Erreichbarkeit

Stufe	Beantwortete Frage	Abwägung
Abhängigkeit	Wird das Paket überhaupt importiert?	Günstig, sortiert aber nur ungenutzte Abhängigkeiten aus
Funktion	Kann ein Aufrufpfad die verwundbare Funktion erreichen?	Das übliche Ziel, braucht aber einen Aufrufgraphen und Schwachstellendaten pro Funktion
Laufzeit	Wurde dieser Code in der Produktion geladen oder ausgeführt?	Nachweis aus echtem Datenverkehr, aber nur für das, was während der Beobachtung lief

Für einen echten Exploit braucht es mehr als einen Pfad. Die Eingabe muss die Funktion in einer Form erreichen, die den Fehler auslöst, und das können nur wenige Tools beurteilen.

Wo die Erreichbarkeitsanalyse an Grenzen stößt

Nicht erreichbar heißt nicht sicher. Es heißt, dass das Tool keinen Pfad gefunden hat. Reflection, dynamische Importe und das Laden von Plugins können Pfade schaffen, die die statische Analyse nicht sieht.
Die Sprachabdeckung schwankt. Statisch kompilierte Sprachen lassen sich leichter nachverfolgen als dynamische, und Tools unterscheiden sich darin, welche Ökosysteme eine Analyse auf Funktionsebene erhalten.
Schwachstellendaten sind unvollständig. Hat niemand ein Advisory einer Funktion zugeordnet, hat das Tool nichts, wonach es suchen kann.
Sie ändert sich mit Ihrem Code. Ein heute nicht erreichbarer Befund kann nach dem nächsten Release erreichbar sein, die Antwort muss also erneut geprüft werden.
Sie ordnet nur, was identifiziert wurde. Eine Komponente, die der Scanner nie gefunden hat, lässt sich nicht analysieren. Ohne vollständiges Inventar sortiert die Erreichbarkeit nur einen Teil des Bildes.

So setzen Sie sie sicher ein

Nutzen Sie sie, um Arbeit zu ordnen, nicht, um sie abzutun. Beheben Sie erreichbare Befunde zuerst und planen Sie den Rest ein, statt ihn zu schließen.
Lassen Sie sie nicht schwerer wiegen als aktive Ausnutzung. Ein Befund im KEV-Katalog von CISA oder mit hohem EPSS-Wert verdient eine menschliche Entscheidung, auch wenn er als nicht erreichbar markiert ist.
Seien Sie vorsichtig bei aus dem Internet erreichbaren Diensten. Eine falsche Antwort kostet dort am meisten, wo Angreifer Sie direkt erreichen können.
Halten Sie die Begründung fest. Entscheiden Sie, dass ein Befund nicht zutrifft, bewahrt eine VEX-Aussage die Entscheidung auf und erklärt Ihren Kunden den Grund.

Wie sich Erreichbarkeit mit Schweregrad, Exploit-Daten und Geschäftskontext verbindet, lesen Sie unter so priorisieren Sie Schwachstellen.

Welche Tools bieten Erreichbarkeitsanalyse?

Viele kommerzielle SCA-Tools, darunter Snyk, Endor Labs, Mend, Checkmarx, Semgrep und Aikido, wobei sich die Tiefe je nach Sprache unterscheidet. Das Go-Tool govulncheck ist ein kostenloses Beispiel für ein einzelnes Ökosystem. Was jedes abdeckt, zeigt Die besten SCA-Tools im Vergleich.

Wo CRACI ansetzt

CRACI bietet keine Erreichbarkeitsanalyse. Es arbeitet am Schritt davor: zu wissen, was überhaupt im Build steckt. Es ist ein GitHub-Actions-Runner, der jedes Paket aufzeichnet, das ein Job lädt, einschließlich der versteckten Abhängigkeiten, die Lockfile-Scannern entgehen, und die SBOMs des Ausgelieferten laufend neu bewertet, sobald neue Schwachstellen veröffentlicht werden. Hat die Erreichbarkeit für Sie oberste Priorität, setzen Sie neben CRACI ein Tool ein, das dafür gebaut ist. Siehe wo CRACI neben Ihren SCA-Tools ansetzt.

Erreichbarkeitsanalyse: häufig gestellte Fragen

Was ist Erreichbarkeitsanalyse in SCA?

Sie prüft, ob Ihr Code die verwundbare Funktion in einer Abhängigkeit tatsächlich aufrufen kann, sodass Befunde ohne Pfad von Ihrem Code niedriger eingestuft werden können.

Ist die Erreichbarkeitsanalyse zuverlässig?

Sie ist nützlich, aber kein Beweis. Ein erreichbarer Befund hat einen echten Pfad, ein nicht erreichbarer bedeutet nur, dass das Tool keinen gefunden hat. Reflection, dynamisches Laden und Lücken in Schwachstellendaten können einen Pfad verbergen.

Können Sie nicht erreichbare Schwachstellen ignorieren?

Ignorieren Sie sie nicht pauschal. Planen Sie sie hinter erreichbaren Befunden ein, prüfen Sie sie nach Codeänderungen erneut und achten Sie besonders auf alles, was aktiv ausgenutzt wird oder in einem aus dem Internet erreichbaren Dienst läuft.

Was ist der Unterschied zwischen Erreichbarkeit und Ausnutzbarkeit?

Erreichbarkeit fragt, ob Code zur verwundbaren Funktion gelangen kann. Ausnutzbarkeit fragt, ob ein Angreifer diesen Pfad nutzen kann, um Schaden anzurichten. Ein Fehler kann erreichbar und in Ihrer Umgebung trotzdem nicht ausnutzbar sein.

Reduziert die Erreichbarkeitsanalyse Warnungen?

Ja, das ist ihr Hauptzweck. Wie stark, hängt von der Sprache, dem Tool und davon ab, wie viel von jeder Abhängigkeit Ihr Code nutzt.