„Betrifft diese CVE unser Produkt?”. Ein praktischer Triage-Workflow

Donnerstag, 16:40. Ein neues Advisory landet im Feed: eine ernste Schwachstelle in einer Komponente, die Ihre Produkte vielleicht verwenden. Management stellt die einzige Frage, die Management stellen kann: „Sind wir betroffen?" Was in den nächsten vier Stunden passiert, entscheidet, ob diese Frage eine Antwort oder eine Meinung bekommt. Die meisten Produktorganisationen haben dafür keinen Workflow, sie haben einen Mail-Thread, eine Tabelle und den, der zuerst antwortet.

Diese Note beschreibt den Workflow, den wir mit Product-Teams bauen: vier Stufen zwischen „Advisory veröffentlicht" und einer verteidigungsfähigen Aussage, jede Stufe mit klarem Exit-Kriterium. Es ist dieselbe Kette, ob das Advisory ein OpenSSL-Denial-of-Service ist, ein U-Boot-Signatur-Bypass wie CVE-2026-46728 oder ein Zephyr-Kernel-Overflow, die Komponente wechselt, die Fragen nicht.

Stufe 1: Presence, und warum Versions-Matching lügt

Der erste Filter ist faktisch: Ist die Komponente im Produkt, im betroffenen Versionsbereich? Die SBOM antwortet, wenn sie vollständig ist und wenn ihre Versionen ehrlich sind. Beide Wenns tragen Last. Firmware-Images enthalten routinemäßig Komponenten, deren berichtete Version nicht mehr der Realität entspricht, weil Patches backportet wurden, ohne den Versions-String anzuheben, oder weil das Vendor-BSP die Upstream-Version meldet und einen eigenen Fork ausliefert. Versions-Presence ist ein Signal, keine Antwort.

Für Embedded-Produkte schlägt binäre Presence die Manifest-Presence: Taucht das verwundbare Symbol tatsächlich im Firmware-Image auf? Hier zahlt sich Tooling aus, und hier finden wir regelmäßig SBOMs, die auflisten, was das Build-System kannte, minus die vier Komponenten, die das SDK hineingeschmuggelt hat.

Stufe 2: Reachability, ist der Codepfad aufrufbar?

Presence sagt: Der verwundbare Code existiert. Reachability fragt, ob irgendetwas im Produkt ihn aufrufen kann, und hier sollte die meiste Triage-Arbeit liegen, weil hier die meiste falsche Sicherheit liegt. Eine Parser-Schwachstelle in einer Bibliothek, die nur vertrauenswürdige, signierte Eingaben parst, hat eine andere Reachability als dieselbe Bibliothek, die Funk-Frames parst. Das sind Produktfragen, keine Bibliotheksfragen: Wer füttert diesen Code, womit, unter wessen Kontrolle?

Stufe 3: Exploitability. Sind die Bedingungen hier erfüllt?

Exploitability ist Reachability plus Umgebung: Konfiguration, Architektur, Mitigationen, physische Exposition. Dieselbe CVE kann auf einem Produkt ein Lehrbuch-Exploit sein und auf dem Schwesterprodukt eine Sackgasse, andere Compiler-Härtung, andere Netzposition, andere Privilegien-Trennung. Das ehrliche Ergebnis dieser Stufe ist eine bedingte Aussage: „ausnutzbar, wenn X; nicht ausnutzbar, wenn Y", mit Evidenz für beide Zweige. Diese Aussage wird zur Engineering-Aktion und, falls nötig, zur regulatorischen.

Stufe 4: Product Impact, die Antwort, dokumentiert

Der Endzustand ist eine von drei Aussagen, keine davon lautet „wahrscheinlich okay":

• Betroffen. Welche Produkte, welche Versionen, was der Angreifer gewinnt, was der Fix ist, wann er kommt.
• Nicht betroffen. Welche Stufe der Kette es festgestellt hat. Presence, Reachability oder Exploitability, und mit welcher Evidenz.
• Behoben. Welche Version den Fix enthält und wie ausgelieferte Geräte ihn bekommen.

Diese Struktur ist keine Bürokratie, sie ist exakt die Form eines VEX-Statements (Vulnerability Exploitability eXchange), des Industrie-Formats für maschinenlesbare Affected-/Not-Affected-Aussagen. Und seit September 2026 ist sie auch die Form, die der Cyber Resilience Act faktisch verlangt, wenn eine Schwachstelle Ihres Produkts aktiv ausgenutzt wird: 24 Stunden bis zur Early Warning, 72 bis zur Notification mit Produkten, Versionen und Impact. Teams, die in dieser Kette triagieren, können die Uhr des Regulators füttern. Teams, die es nicht tun, entdecken den Workflow während des Vorfalls. Die Melde-Timeline behandeln wir in CRA Vulnerability Reporting.

Wie eine funktionierende Routine aussieht

Teams, die das gut machen, teilen vier Gewohnheiten. Eine gepflegte SBOM pro Produktversion, als Build-Artefakt behandelt, nicht als Wiki-Seite. Ein benannter Owner für den Advisory-Feed mit definierten Reaktionszeiten. Die Vier-Stufen-Kette als Template im Tracker, damit jedes Advisory dieselben Fragen in derselben Reihenfolge bekommt. Und Probebetrieb: eine Trocken-Triage über eine echte CVE zweimal im Jahr, damit der erste echte Lauf nicht der erste Lauf ist.

Die Advisory-Saison 2026 war mit Übungsmaterial großzügig. U-Boots FIT-Signatur-Bypass, die Zephyr-DTLS- und Kernel-Issues, der OpenSSL-DoS-Cluster. Jedes davon ist ein guter Kandidat für die nächste Probe. Der beste Zeitpunkt, um herauszufinden, dass Ihre SBOM unvollständig ist, ist ein Donnerstagnachmittag ohne Reporter in der Leitung.