Erreichbarkeit: Wird der verwundbare Code genutzt?

Hinweise aus Ihrer CI, dass eine Schwachstelle geladen, aufgerufen oder nie ausgeführt wird, mit dem Nachweis.

Viele Schwachstellen liegen in Code, den Ihr Produkt nie nutzt. Der CI-Schritt von Provetry, provetry reach, sucht nach Nachweisen in beide Richtungen und sendet Vorschläge; ohne Ihren Klick wird nichts entschieden.

Was es sagen kann

Von Ihrem Code aufgerufen (Go mit govulncheck und die unten genannten Sprachen): Die verwundbare Funktion wird erreicht. Die Schwachstelle rückt nach oben.
Aufruf in Ihrem Code gefunden (npm und PyPI): Eine Aufrufanalyse findet, wo Ihr Code eine Funktion aufruft, die zum behobenen Code führt, mit Datei und Zeile. Die Schwachstelle rückt nach oben.
Von Ihrem Code geladen (alle Sprachen): Das verwundbare Paket wird importiert, mit Datei und Zeile. Ob die verwundbare Funktion selbst aufgerufen wird, ist auf dieser Ebene nicht bekannt.
Never loaded oder never called: als nicht betroffen vorgeschlagen, mit der Erläuterung des Werkzeugs als Nachweis. Übernehmen Sie sie einzeln oder alle auf einmal.

Für Rust stammt die Funktionsebene aus den Funktionen, die RustSec nennt. Für npm und PyPI erhält Ihre CI in den Tarifen Pro und Consultant außerdem die öffentlichen Funktionen, die zum behobenen Code jedes Hinweises führen, sodass sie „geladen“ von „aufgerufen“ unterscheiden kann.

Wo Ihr Code eine dieser Funktionen nennt, sucht danach eine Aufrufanalyse den Aufruf selbst, über Aliasse und Importe hinweg: Jelly (ein Aufrufgraph-Analysator der Universität Aarhus) für JavaScript und TypeScript, ein Lesen der Importe und Aufrufe jeder Datei für Python. Sie fügt nur Nachweise hinzu: Solche Analysen übersehen manche Aufrufe (eine als Callback übergebene Funktion, ein Re-Export), daher ändert ein nicht gefundener Aufruf nichts. In der CI läuft Jelly über npx; provetry reach --no-calls überspringt es.

Für Java (Maven) decken dieselben Daten die öffentlichen Methoden ab, die zum behobenen Code führen. Java-Bibliotheken finden sich auch zur Laufzeit gegenseitig (Service Loader, Provider-Dateien, Auto-Konfiguration), daher braucht ein „never called“ zwei weitere Dinge: Die Bibliothek ist eine direkte Abhängigkeit Ihres Projekts, und Ihr Build schreibt seine CycloneDX-SBOM, die den vollständigen Abhängigkeitsgraphen liefert. Fügen Sie dem Build das CycloneDX-Plugin hinzu, bevor provetry reach läuft: mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom (schreibt target/bom.json) oder das Gradle-Plugin org.cyclonedx.bom (build/reports/). Ohne es erhält Java nur die Paketebene.

Die Regel

Jeder Zweifel zählt als Nutzung. Ein dynamischer Import, ein Makro, eine Methode, die ein Framework über ihren Namen aufruft: Das Werkzeug schließt dann nichts. Und die Pipeline schlägt nur bei nachgewiesenen Aufrufen fehl, nie bei Vorschlägen.