“Does This CVE Affect Our Product?”. A Practical Triage Workflow

Thursday, 16:40. A new advisory lands in the feed: a serious vulnerability in a component your products might use. Management asks the only question management can ask: "Are we affected?" What happens in the next four hours decides whether that question gets an answer or an opinion. Most product organizations don't have a workflow for it, they have a mail thread, a spreadsheet, and whoever answers first.

This note describes the workflow we build with product teams: four stages between "advisory published" and a defensible statement, each stage with a clear exit condition. It is the same chain whether the advisory is an OpenSSL denial-of-service, a U-Boot signature bypass like CVE-2026-46728, or a Zephyr kernel overflow, the component changes, the questions don't.

Stage 1: Presence, and why version matching lies

The first filter is factual: is the component in the product, in the affected version range? The SBOM answers, if it is complete and if its versions are honest. Both ifs are load-bearing. Firmware images routinely contain components whose reported version no longer matches reality, because patches were backported without bumping the version string, or the vendor BSP reports the upstream version while shipping its own fork. Version presence is a signal, not an answer.

For embedded products, binary-level presence beats manifest presence: does the vulnerable symbol actually appear in the firmware image? This is where tooling pays for itself, and where we regularly find SBOMs that list what the build system knew about, minus the four components the SDK smuggled in.

Stage 2: Reachability, is the code path callable?

Presence says the vulnerable code exists. Reachability asks whether anything in the product can invoke it, and this is where most triage effort should go, because it is where most false certainty lives. A parser vulnerability in a library that only parses trusted, signed input has a different reachability than the same library parsing radio frames. The questions are product questions, not library questions: who feeds this code, with what, under whose control?

Stage 3: Exploitability, are the conditions met here?

Exploitability is reachability plus environment: configuration, architecture, mitigations, physical exposure. The same CVE can be a textbook exploit on one product and a dead end on its sibling, different compiler hardening, different network position, different privilege separation. The honest output of this stage is a conditional statement: "exploitable if X, not exploitable if Y", with evidence for both branches. That statement is what turns into engineering action and, if needed, into a regulatory one.

Stage 4: Product impact, the answer, documented

The end state is one of three statements, and none of them is "probably fine":

• Affected. Which products, which versions, what an attacker gains, what the fix is, when it ships.
• Not affected. Which stage of the chain established it, presence, reachability or exploitability, and the evidence.
• Fixed. Which version contains the fix and how deployed devices get it.

This structure is not bureaucracy, it is exactly the shape of a VEX statement (Vulnerability Exploitability eXchange), the industry format for machine-readable affected/not-affected claims. And since September 2026, it is also the shape the Cyber Resilience Act effectively demands when a vulnerability in your product is actively exploited: 24 hours to an early warning, 72 to a notification that names products, versions and impact. Teams that triage in this chain can feed the regulator's clock. Teams that don't, discover the workflow during the incident. We treat the reporting timeline in CRA Vulnerability Reporting.

What a working routine looks like

The teams that do this well share four habits. A maintained SBOM per product version, treated as a build artifact, not a wiki page. A named owner for the advisory feed, with defined reaction times. The four-stage chain as a template in the tracker, so every advisory gets the same questions in the same order. And rehearsal: a dry-run triage on a real CVE twice a year, so the first live run is not the first run.

The 2026 advisory season has been generous with practice material. U-Boot's FIT signature bypass, the Zephyr DTLS and kernel issues, the OpenSSL DoS cluster. Any of them is a good candidate for the next rehearsal. The best time to find out your SBOM is incomplete is a Thursday afternoon with no reporter on the line.