Branchen-Analysen legen nahe, dass die große Mehrzahl markierter Schwachstellen in Drittkomponenten in einem konkreten Produkt nicht ausnutzbar ist. Die Zahl ist beruhigend und irreführend: Sie bedeutet, dass reine CVE-Korrelation enormen Lärm erzeugt, und dass die wenigen ausnutzbaren Fälle darin versteckt sind. Ein Team, das jedes CVE als kritisch behandelt, brennt aus; ein Team, das CVEs ignoriert, liefert irgendwann ein ausnutzbares Produkt aus.
Die Lücke zwischen CVE und Produkt-Impact hat konkrete technische Stufen. Die Komponente muss vorhanden sein, in der betroffenenen Version. Der betroffene Code muss gebaut und aktiviert sein, nicht nur im Source-Baum resident. Angreifer-gesteuerter Input muss die verwundbare Funktion über die echte Konfiguration des Produkts erreichen. Und die Exploit-Voraussetzungen. Memory-Layout, Privilegien, Protokoll-Zustand, müssen im Feld halten, nicht nur im Labor des Researchers.
Diese Fragen für Embedded-Produkte zu beantworten ist schwerer als für Server-Software. Firmware-Builds strippen oder inlinen Code, SBOMs sind unvollständig, und Reachability kann von einem Protokoll-Parser drei Schichten entfernt liegen. Genau diese Analyse unterscheidet Evidenz von Alarm.
Produkt-Impact hängt von mehreren technischen Fragen ab.
- Komponenten-Präsenz Ist die betroffene Komponente im Build in der betroffenen Version, inklusive transitiver Abhängigkeiten?
- Codepfad-Aktivierung Ist der verwundbare Code kompiliert und aktiviert, oder toter Code, gestripp oder per Konfiguration deaktiviert?
- Reachability Kann Angreifer-gesteuerter Input die betroffene Funktion über die Schnittstellen und Konfiguration des Produkts erreichen?
- Exploit-Voraussetzungen Halten die Bedingungen, die der Exploit braucht. Memory-Layout, Privilegien, Protokoll-Zustand, im eingesetzten Produkt?
- Betroffener Scope Welche Produktversionen, Varianten und Konfigurationen sind betroffen, nicht der gesamte Katalog, sondern die konkrete Menge?
- Feld-Mitigation Begrenzen bestehende Härtung, Isolation oder Netz-Position das Issue bereits?
- Verifikationspfad Wie würde ein Fix bestätigt, dass er den Pfad am realen Produkt schließt?
Kritisch in der Datenbank. Abwesend im Produkt.
Ein CVSS-9.8-CVE trifft eine Bibliothek, die Ihr Build enthält. Die Eskalation schreibt sich selbst: kritisch, remote, ohne Authentisierung. Das Team bereitet ein Emergency-Release vor.
Die Analyse zeigt: Die betroffene Funktion wurde vor zwei Versionen durch einen Vendor-Patch entfernt, und das Produkt ruft den verwundbaren API-Pfad nie auf. Das Emergency-Release verschießt trotzdem, потому die Entscheidung vor der Evidenz fiel. Derweil wartet ein Medium-Score-Parser-Issue, das tatsächlich erreichbar ist, im selben Report.
Das CVE ins Produkt verfolgen, nicht in die Datenbank.
Wir nehmen die gemeldete Komponente und verfolgen sie durch den echten Build: Präsenz, Codepfad-Aktivierung, Reachability von Angreiber-gesteuerten Inputs und Exploit-Voraussetzungen unter Feld-Bedingungen. Das Ergebnis ist per-Produkt-Evidenz, betroffen, nicht betroffen oder bedingt betroffen mit genannten Bedingungen.
- Ein kritisches CVE betrifft eine Komponente in Ihrem SBOM
- Kunde oder Regulator fragt nach einer Vulnerability-Impact-Bewertung
- Produkt liefert Drittanbieter-Bibliotheken, Kernel oder Toolchains
- Security-Advisory oder Release-Entscheidung in Vorbereitung
- SBOM-Qualität oder -Vollständigkeit ist unklar
- Wiederkehrende CVE-Triage bindet Engineering-Kapazität