How to Find Vulnerabilities in Closed-Source Third-Party Binaries
Most security teams know how to handle code they can read. You run a scanner, you get a dependency list, you patch what the tool flags. The workflow is imperfect but at least it's a workflow.
The problem breaks down the moment a vendor hands you a .dll, a firmware image, or a compiled SDK and says "here you go." No source. No lockfile. No dependency manifest. Just a binary - and the expectation that you'll integrate it into something that matters.
This is the closed-source third-party binary problem, and it's more common than the tooling industry admits.
Why Standard SCA Falls Short Here
Software composition analysis tools - including source-based SAST/SCA platforms - work by parsing package manifests, reading dependency declarations, or tracing source imports. That approach works well when you control the build chain. It does not work when you are handed a precompiled artifact with no accompanying metadata.
The gap is real and consequential:
- Embedded third-party libraries inside a binary are invisible to manifest-based scanners
- A vendor's binary may carry a dependency version that differs from what the vendor's own documentation claims
- Firmware and OT software routinely ship with open-source components that never appear in any disclosed SBOM
- Containers pull in layers you do not own and may not be able to inspect at the source level
Standard SCA tools are not broken - they're just solving a different problem. When source is unavailable, you need a fundamentally different starting point.
The Binary-First Approach: What It Actually Means
Binary-first analysis inverts the usual workflow. Instead of starting from source and tracing forward to a build artifact, you start from the artifact itself and work backward to identify what's inside it.
Concretely, this involves:
Binary fingerprinting and component identification. Automated reverse engineering techniques extract signals from the compiled binary - strings, function signatures, symbol patterns, library boundaries - and match them against known component fingerprints. The goal is to reconstruct something like a bill of materials from the compiled output, not from a declared dependency list.
CVE and KEV correlation. Once components and approximate versions are identified, they are mapped to known vulnerabilities. The distinction between CVEs (the full universe of disclosed vulnerabilities) and KEVs (CISA's Known Exploited Vulnerabilities catalog) matters here: a CVE-to-KEV flag means the vulnerability has confirmed, active exploitation - not just theoretical risk.
Exploit-based validation. This is where binary-first analysis gets meaningful for prioritization. Identifying a CVE inside a binary doesn't tell you whether the vulnerable code path is actually reachable in the compiled artifact as shipped. Exploit-based verification - testing whether an exploit template actually executes against the binary in question - shifts the finding from "this component has a known CVE" to "this specific build is demonstrably exploitable." That distinction changes the conversation with vendors and internal stakeholders significantly.
Building an SBOM When You Have No Source
Regulatory pressure around SBOMs (NTIA guidance, FDA requirements for medical device software, emerging DoD requirements) increasingly applies to software you consume, not just software you produce. If a vendor provides a binary and no SBOM, that gap is yours to fill.
Binary composition analysis can produce SPDX and CycloneDX SBOMs directly from artifact inspection - without requiring source code, build tooling, or vendor cooperation. The resulting SBOM reflects what actually shipped, which is meaningfully different from what a vendor claims shipped. Version drift, undisclosed dependencies, and embedded components that predate your vendor relationship all show up in a binary-derived SBOM in ways they simply cannot in a vendor-declared one.
For procurement and vendor risk workflows, a binary-derived SBOM gives you an auditable artifact that represents ground truth rather than vendor attestation.
Where This Applies Across IT and OT
The closed-source binary problem is not limited to enterprise software procurement. It appears across:
- Firmware from hardware vendors - network appliances, industrial controllers, medical devices where the vendor has no obligation and no incentive to share source
- Commercial off-the-shelf software - compiled Windows or Linux binaries integrated into workflows or embedded in products you resell
- Containers - third-party base images and layers that incorporate open-source components with no manifest coverage
- OT and embedded systems - PLC firmware, HMI software, and industrial protocol stacks that may carry decade-old open-source components with well-documented vulnerabilities
The analysis workflow is the same regardless of environment: ingest the artifact, fingerprint its components, correlate against known vulnerabilities, validate exploitability, and produce a structured output (SBOM + prioritized findings) that security and procurement teams can act on.
Complementing Source-Based Security Programs
Binary-first analysis is additive, not a replacement for source-based scanning. If your team already runs SAST or SCA against your own codebase, binary composition analysis fills the blind spot that those tools structurally cannot cover: the software your organization did not write and cannot read.
A mature supply-chain security posture covers both layers - source-level hygiene for what you build, binary-level inspection for what you integrate.
Getting Started
The practical entry point is simple: pick a binary you currently integrate but cannot inspect - a vendor SDK, a firmware image, a third-party container layer - and run it through binary composition analysis. The output tells you what's inside, which CVEs apply, which of those are actively exploited, and whether the exploitation is confirmed against this specific build.
KhaiCode is built specifically for this workflow: binary composition analysis, CVE/KEV correlation, exploit-based validation, and SPDX/CycloneDX SBOM generation from artifact inspection alone, across software, firmware, and containers in both IT and OT environments.
If you're evaluating whether your third-party binary inventory has exposure you can't currently see, a demo is the fastest way to find out what's there.
This post is about KhaiCode.