Erreichbarkeit
Viele Warnungen zu Ihren Abhängigkeiten betreffen Code, den Ihr Produkt nie ausführt. Provetry zeigt Ihnen, welche, mit Nachweisen.
Mit der Cyberresilienz-Verordnung braucht jede bekannte Schwachstelle einer unterstützten Version eine Bewertung. Sie einzeln zu bewerten und dafür den Code zu lesen, kostet die meiste Zeit. Provetry sucht in Ihrer eigenen CI nach Nachweisen in beide Richtungen und gibt Ihnen die Antwort mit ihrem Nachweis.
Drei Antworten, jede mit ihrem Nachweis
Nie geladen
Das verwundbare Paket steht in Ihrer Lock-Datei, aber kein Pfad führt von Ihrem Code dorthin. Provetry nennt die Kette, die es mitbringt, und schlägt „nicht betroffen: Die Komponente wird nie geladen“ vor.
Geladen, nie aufgerufen
Ihr Code lädt das Paket, nennt aber nie die Funktionen, die zum verwundbaren Code führen. Provetry listet diese Funktionen auf und schlägt „nicht betroffen: Der verwundbare Code wird nie ausgeführt“ vor.
Aufgerufen
Ihr Code erreicht den verwundbaren Code: Die Schwachstelle rückt in der Liste nach oben, mit Datei und Zeile. Auf Wunsch schlägt Ihre Pipeline daran fehl.
Was Sie in der Anwendung sehen
flat@5.0.0 · direktPrototype Pollution in flat
Von Ihrem Code importiert (web/src/config.js:2), von nichts anderem geladen
Vorgeschlagen: nicht betroffen — der verwundbare Code wird nie ausgeführt
Die Funktion, die zum behobenen Code führt (unflatten), wird nirgends im Repository genannt.
Was abgedeckt ist
| Ökosystem | Paketebene | Funktionsebene | Quelle |
|---|---|---|---|
| Go | Ja | Ja | govulncheck |
| Rust (Cargo) | Ja | Ja | Die Funktionen, die RustSec nennt |
| JavaScript und TypeScript (npm) | Ja | Pro und Consultant | Die Daten zu verwundbaren Funktionen von Provetry und die Aufrufanalyse Jelly |
| Python (PyPI) | Ja | Pro und Consultant | Die Daten zu verwundbaren Funktionen von Provetry und ein Lesen der Aufrufe |
| Java (Maven) | Nur Nachweis der Nutzung | Pro und Consultant, für direkte Abhängigkeiten, mit der CycloneDX-SBOM Ihres Builds | Die Daten zu verwundbaren Funktionen von Provetry |
| PHP, Ruby, .NET | Ja | Noch nicht | — |
Die Ergebnisse kommen aus Ihrer CI mit einem API-Schlüssel in Provetry an, in den kostenpflichtigen Tarifen.
Die Daten zu verwundbaren Funktionen
Die meisten Sicherheitshinweise nennen ein Paket und seine Versionen, nicht die betroffenen Funktionen. Jeden Tag liest Provetry die Korrektur jedes geprüften Hinweises, findet die Funktionen, die sie ändert, und dann die öffentlichen Funktionen des Pakets, die dorthin führen. Dadurch kann Ihre CI „geladen“ von „aufgerufen“ unterscheiden. Diese Daten werden Pro- und Consultant-Kunden mit ihrem API-Schlüssel bereitgestellt.
Wie es läuft
In Ihrer CI, auf Ihrem Code
Der Open-Source-Kern läuft in Ihrer Pipeline (GitHub-Action, GitLab-Vorlage). Ihr Quellcode verlässt nie Ihre Infrastruktur: Provetry erhält die Ergebnisse, nicht den Code.
Vorschläge, nie Entscheidungen
Jedes „nicht betroffen“ ist ein Vorschlag mit seinem Nachweis. Sie übernehmen ihn, einzeln oder alle zusammen, und er wird zu Ihrer VEX-Bewertung, veröffentlicht, wenn Sie es wünschen.
Jeder Zweifel zählt als Nutzung
Wo es einen dynamischen Import, einen Aufruf per Reflection, ein Makro, eine Methode, die ein Framework per Konvention aufruft, oder eine zu große Datei sieht, schließt das Werkzeug nichts. Ein falsches „nie aufgerufen“ ist der Fehler, den es vor allem vermeiden soll.
Als Nachweis aufbewahrt
Übernommene Bewertungen gehen in Ihr Nachweisjournal ein, verkettet und mit Zeitstempel, bereit für eine Marktüberwachungsbehörde.
Die Grenzen, offen gesagt
- Die Funktionsebene liest Namen, keine Typen: Eine Funktion, die Ihr Code nennt, zählt als möglicherweise aufgerufen, auch wenn sie es nicht ist. Für npm und PyPI sucht danach eine Aufrufanalyse den Aufruf selbst und zeigt, wenn sie ihn findet, Datei und Zeile; andernfalls bleibt die Erwähnung, weil solche Analysen manche Aufrufe übersehen. Wie jede Codeanalyse kann sie einen Aufruf nicht sehen, der auf eine ihr unbekannte Weise erfolgt.
- Eine Korrektur kann mehr als den verwundbaren Code ändern, und ein Hinweis kann gar keine nennen: Dann gibt es keine Antwort auf Funktionsebene, nur auf Paketebene.
- Java-Bibliotheken finden sich auch zur Laufzeit gegenseitig (Service Loader, Provider-Dateien, Auto-Konfiguration). Ein „nie aufgerufen“ gibt es nur für eine direkte Abhängigkeit, anhand des vollständigen Abhängigkeitsgraphen, den Ihr Build schreibt, und nie, wenn generierter Code (Lombok, MapStruct …) oder mitgelieferte JARs sie aufrufen können.