Industry analysis suggests that the vast majority of flagged vulnerabilities in third-party components are not exploitable in a given product. The number is comforting and misleading: it means that raw CVE correlation produces enormous noise, and that the few exploitable cases hide inside it. A team that treats every CVE as critical burns out; a team that ignores CVEs eventually ships an exploitable product.
The gap between a CVE and a product impact has concrete technical stages. The component must be present, at the affected version. The affected code must be built and enabled, not merely resident in the source tree. Attacker-controlled input must reach the vulnerable function through the product's real configuration. And the exploit prerequisites, memory layout, privileges, protocol state, must hold in the field, not only in the researcher's lab.
Answering these questions for embedded products is harder than for server software. Firmware builds strip or inline code, SBOMs are incomplete, and reachability may depend on a protocol parser three layers away from the vulnerable library. This is exactly the analysis that distinguishes evidence from alarm.
Product impact depends on several technical questions.
- Component presence Is the affected component in the build at the affected version, including transitive dependencies?
- Code path activation Is the vulnerable code compiled in and enabled, or dead code stripped or gated by configuration?
- Reachability Can attacker-controlled input reach the affected function through the product's interfaces and configuration?
- Exploit prerequisites Do the conditions the exploit requires, memory layout, privileges, protocol state, hold in the deployed product?
- Affected scope Which product versions, variants and configurations are affected, not the entire catalog, the specific set?
- Field mitigation Do existing hardening, isolation or network position already contain the issue?
- Verification path How would a fix be confirmed as closing the path on the real product?
Critical in the database. Absent in the product.
A CVSS 9.8 CVE lands in a library your build includes. The escalation writes itself: critical, remote, no authentication. The team prepares an emergency release.
Analysis shows the affected function was removed by a vendor patch two versions ago, and the product never calls the vulnerable API path. The emergency release ships anyway, because the decision was made before the evidence. Meanwhile, a medium-score parser issue that is genuinely reachable waits in the same report.
Follow the CVE into the product, not the database.
We take the reported component and trace it through the actual build: presence, code path activation, reachability from attacker-controlled inputs, and exploit prerequisites under field conditions. The result is per-product evidence, affected, not affected, or conditionally affected with the conditions named.
- A critical CVE affects a component in your SBOM
- Customer or regulator asks for a vulnerability impact assessment
- Product ships third-party libraries, kernels or toolchains
- Preparing a security advisory or release decision
- SBOM quality or completeness is uncertain
- Recurring CVE triage consumes engineering capacity