A CVE in Your Vendor's Binary Is Not Proof of a Real Risk - Here's How to Tell the Difference
Security scanners are good at finding vulnerabilities. They are considerably less good at telling you which ones actually matter.
If you run any kind of software composition analysis against a vendor-supplied binary - an appliance firmware, a containerized application, a commercial off-the-shelf package - you will get a list of CVEs. That list is almost always long. It is also almost always misleading, because a CVE mapped to a component version is a theoretical statement, not an operational one. "This version of OpenSSL has a known vulnerability" and "that vulnerability is reachable and exploitable in this specific binary" are two very different claims.
The gap between those two claims is where most security teams waste enormous amounts of time.
Why Theoretical Vulnerability Mapping Fails in Practice
Most SCA tools work at the manifest or source level. They read a software bill of materials, parse dependency files, or scan source code, and then cross-reference component versions against CVE databases. That process is well understood and genuinely useful - for code you build yourself.
Vendor binaries are a different problem.
When a vendor ships you a compiled binary, you do not get the source. You do not get a trustworthy SBOM (if you get one at all). You get an artifact that may have been compiled with custom patches, may statically link only part of a vulnerable library, or may expose a vulnerable function through a code path that the binary never actually reaches. The scanner does not know any of that. It sees a version string or a linked library name, finds a matching CVE, and reports it.
The result: your vuln list is full of findings that are theoretically correct and operationally irrelevant. Meanwhile, the one CVE where the vulnerable code path is actually reachable - and weaponizable - sits at the same severity level as everything else.
What Exploit Validation Actually Means
Exploit validation is the process of confirming, against the actual binary artifact, that a specific vulnerability can be triggered in a way that produces real-world impact. It is not re-running a scanner. It is not reading the CVE description more carefully. It is testing the attack path inside the binary itself.
This matters for a few specific reasons:
Static linking and partial inclusion. A binary might link only the non-vulnerable subset of a library. Version-based matching cannot see that.
Compiler mitigations and build flags. ASLR, stack canaries, RELRO, and similar protections at the binary level change whether a known exploit technique can succeed. Two binaries built from the same source code can have very different exploitability profiles.
Reachability. A vulnerable function exists in the binary. Does anything actually call it in the deployed application context? If the code path is dead, the CVE is not a real risk in this artifact.
KEV relevance. CISA's Known Exploited Vulnerabilities catalog tells you what adversaries are actively using in the wild. A CVE that is both reachable in your binary and on the KEV list is a different category of problem from a theoretical library match.
How Binary-First Analysis Changes the Prioritization Question
Tools built for source-code-first environments have a hard time answering exploitability questions against vendor binaries. The artifact you received was never meant to be analyzed that way, and the tool was never designed to handle it.
Binary-first platforms approach this differently. KhaiCode, for example, inspects the binary directly - no source code required - using automated reverse engineering to identify embedded components and map them to CVEs and KEVs. The differentiation is in what happens next: rather than stopping at version correlation, KhaiCode applies an exploit-template-based validation step that tests whether a specific CVE is actually triggerable in the artifact under analysis. The result is not just a list of what components are present; it is a determination of which findings represent real attack paths versus theoretical matches.
That distinction - between a vulnerability that is present and a vulnerability that is exploitable - is what makes prioritization tractable.
KhaiCode also generates SBOM output in SPDX and CycloneDX formats from the binary itself, which is useful when a vendor has not provided one, or when you have reason to question the accuracy of the one they did provide. The platform covers software binaries, firmware, and containers across IT and OT environments.
The Practical Workflow for Validating a Vendor Binary
If you receive a third-party binary and need to assess whether reported CVEs represent real risk, the process looks roughly like this:
- Get the actual artifact. Not the vendor's SBOM - the binary itself. Version manifests are a secondary signal at best.
- Run binary composition analysis. Identify embedded libraries and components from the binary, not from documentation.
- Map to CVEs and KEVs. Cross-reference against known vulnerability databases, with KEV status flagged separately.
- Apply exploit validation. For findings that look high-severity, confirm that the vulnerable code path is reachable and that the binary does not have mitigations that break the known exploit technique.
- Generate a defensible SBOM. Document what was actually found in the artifact, which you can use for vendor conversations, compliance, and incident response.
This is not a process that manual review or traditional SCA handles well. It requires tooling designed specifically for binary-first analysis.
Who This Problem Belongs To
This is not exclusively a red team problem. Penetration testers and security researchers have been doing binary analysis for years. The emerging issue is that product security teams, procurement security reviewers, and organizations running OT or embedded environments are now responsible for assessing vendor-supplied software they have no source access to - and they need the same quality of exploitability signal that red teams have always needed, at scale.
If your current process is "run a scanner, get a CVE list, try to triage by CVSS score," you are working with an incomplete picture. CVSS scores the theoretical severity of a vulnerability in isolation. It does not score exploitability in your specific binary artifact.
The question worth asking about every high-severity CVE in a vendor binary: is this actually exploitable here, or is it a version match? Those are not the same thing, and treating them as equivalent is where real risks get buried.
KhaiCode is available through Apona. If you are working through a vendor binary assessment or want to see exploit validation in action against your own artifacts, contact us to connect with the right resource.
This post is about KhaiCode.