Software Supply Chain Security for OT and IoT Device Manufacturers

When you ship a device, you ship everything inside it - the open-source libraries your team chose, the third-party SDKs you integrated, the firmware components the silicon vendor bundled in, and the transitive dependencies none of those parties documented well. For OT and IoT manufacturers, that embedded software stack is the attack surface regulators and customers are now scrutinizing, and it starts at the binary level, not the source level.

Source-based software composition analysis (SCA) has been the default answer to supply chain risk for years. It works well when you own the source. But device manufacturers routinely integrate precompiled libraries, proprietary blobs, vendor-supplied firmware images, and components built by third parties who will never hand you their source tree. The result is a visibility gap that source scanning cannot close.

The OT/IoT Supply Chain Problem Is a Binary Problem

A typical IoT or OT device firmware image contains dozens of compiled components. Some were written in-house. Many were not. Open-source libraries get statically linked and stripped. Third-party SDKs ship as object code. Bootloaders and real-time OS kernels arrive from chipset vendors as binary-only deliverables.

Source-based SCA tools identify components by reading package manifests, build files, or source trees. When those artifacts are absent - or when a library was compiled and linked without them - the tool has nothing to read. The component becomes invisible.

This is not an edge case for device manufacturers. It is the normal condition of firmware development. Binaries that contain CVE-affected code ship, and neither the manufacturer nor the customer knows.

What Binary-First Supply Chain Security Actually Does

Binary-first analysis inverts the approach. Instead of reading source artifacts, it inspects the compiled binary directly: extracting embedded component fingerprints, identifying library versions, mapping them to known CVEs and Known Exploited Vulnerabilities (KEVs), and validating whether those vulnerabilities are actually reachable given how the binary is constructed.

KhaiCode is built around this model. It performs binary composition analysis across software, firmware, and containers - covering IT and OT environments without requiring source code at any point in the process.

The capabilities that matter specifically for device manufacturers:

Complete visibility without source access. KhaiCode identifies embedded components from the binary itself. If a library is compiled into your firmware, it surfaces. This applies whether the component came from your team, a silicon vendor, or an upstream supplier.

Multi-architecture emulation. Device firmware runs on ARM, MIPS, RISC-V, and a range of embedded-specific architectures. KhaiCode's emulator supports multi-architecture and multi-platform analysis designed for edge devices, IIoT/IoT sensors, and embedded systems - analyzing binaries in conditions that approximate the actual deployment environment rather than an x86 lab.

Exploit validation, not just CVE matching. Finding a CVE match in a binary is a starting point, not a conclusion. KhaiCode applies exploit-based binary analysis and attack-path analysis to assess whether a vulnerability is actually exploitable in the context of that binary. This distinction matters for triage: manufacturers and their customers need to know which findings require action now and which are theoretical.

SBOM generation (SPDX and CycloneDX). Regulatory and customer pressure around software bills of materials is real and growing. KhaiCode produces SBOMs in both SPDX and CycloneDX formats from binary analysis - without requiring a manifest, build system, or source repository as input. For manufacturers releasing products into regulated markets or selling to enterprise customers with SBOM requirements, this closes the documentation gap for components that build-time SBOM tools miss entirely.

Where This Fits in the Device Manufacturing Workflow

Binary-first supply chain analysis is not a replacement for source-based security work - it is what you add to cover what source tools structurally cannot see.

If your team uses SAST or source-based SCA (including Labrador, which combines SAST, SCA, and supply-chain controls at the source level), KhaiCode is the layer that extends coverage to the compiled output and to any third-party binaries that never passed through your source pipeline. The two approaches are genuinely complementary: one works from source, one works from the artifact that actually ships.

For OT and IoT manufacturers specifically, the shipping artifact is what gets deployed in the field, integrated into customer infrastructure, and increasingly subject to product security requirements from buyers, regulators (FDA, EU Cyber Resilience Act, NIST SP 800-213), and sector-specific frameworks. The binary is what matters.

Assessing Your Current Visibility

A useful diagnostic: take your last firmware release and ask what percentage of the compiled components you could identify and map to current CVE data using your existing tools. For most teams that have not run binary composition analysis, the honest answer is: not all of them.

The components you cannot see are not necessarily safe. They are unknown. And unknown components in shipped firmware are the operational definition of supply chain risk.

What to Evaluate Next

If you are a device manufacturer evaluating supply chain security tooling, the questions worth asking any vendor include:

KhaiCode is designed to answer yes to each of those. You can explore its capabilities at khaicode.com or request a demo to see binary analysis applied to your own firmware.

Apona helps device manufacturers and their security partners evaluate and deploy binary-first supply chain security. KhaiCode is available through Apona's channel.

This post is about KhaiCode.

More on this