From SoC to Shipped Firmware
For SOHO routers and IP cameras, the important supply-chain question is not simply which company’s logo is on the enclosure. It is how a kernel baseline crosses from a system-on-chip platform into the firmware that a device vendor releases, and which decisions remain under whose control at each handoff. Tracing that path makes two facts easier to judge: why a small set of platform choices can shape many products, and why the final firmware image is an incomplete record of how its security foundation was selected.
The path begins with a practical engineering problem. A chip is a piece of hardware; it is not yet a router or a camera. It needs software that understands its processor, memory, storage, network interfaces, and the other components assembled on the board. The solution used in the SOHO ecosystem is often a platform package built around a reduced Linux kernel. That package is convenient to reuse, but reuse also gives the package’s original assumptions a long downstream life.
The platform stack is an agreement around hardware
A SOHO device’s system-on-chip, or SoC, combines much of the computing needed by a low-cost networked product. The board also includes memory, flash storage, and interfaces such as Ethernet or Wi-Fi. Those parts determine the physical capabilities the software must expose, but they do not specify a complete product experience. The software has to initialize the platform, coordinate the hardware, and provide the network and device functions that the router or camera needs.
An SoC vendor therefore starts with a mainstream Linux release and selects the pieces relevant to the target platform. The resulting kernel is stripped down compared with a general-purpose Linux installation. It is accompanied by custom drivers and platform-specific code, configuration templates, build systems, and other development artifacts. Together, these materials form a software development kit, or SDK. An SDK is not merely a download of Linux. It is an integration starting point that packages assumptions about the chip, the board, the available drivers, and the way downstream firmware will be built.
That distinction matters for security. A downstream team that receives an SDK is not choosing a kernel in a vacuum. The team is also receiving the code that makes the selected kernel useful on a particular platform. A different kernel may have a better upstream support position, but moving to it can require the team to recover or replace platform-specific code and to validate the result against the device’s hardware. The exact engineering cost varies by platform and is not measured by the study, but the dependency is visible in the architecture: the kernel baseline is coupled to the surrounding SDK material.
The SDK also carries a selection state that a product description tends to erase. The mainstream release contains more possibilities than the platform needs; the SDK records which subset and supporting code were made workable for the target SoC. Downstream firmware may add more functions, but it begins from that selected state. This explains why a kernel version alone is a weak description of the device: two images can name the same Linux line while enabling different components or carrying different fixes. It also explains why a newer line is not a drop-in replacement merely because its version number looks preferable. The relevant boundary is the relationship between the kernel and the platform code that makes the product operate.
The stack has four identities that should not be collapsed. The chip is the hardware platform. The SDK kernel baseline is the Linux line and associated platform package chosen as the starting point for that hardware. Customized firmware is the assembled software that adds the product’s functions and configuration. The branded device is the finished router or camera as sold and supported. A product vendor may control the last two identities without having selected the first kernel line. Conversely, an SoC vendor may exercise disproportionate influence over the baseline without shipping the consumer product that an owner can identify.
This is also why the word “firmware” can obscure rather than clarify. It names the software image that crosses into the device, but it does not reveal which parts came from the SDK, which parts were changed downstream, or which kernel line remained unchanged. A firmware image is an endpoint artifact. The SDK is a lineage artifact. To understand a security outcome, an evaluator often needs both: what was shipped and what platform the shipped software inherited.
The boundary between these identities is not perfectly clean. Device vendors and original design or manufacturing partners may share development work, and the paper treats those integrators as one downstream entity for its analysis. Hardware revisions can also change the SoC, SDK lineage, firmware instructions, or available source releases even when a product family keeps a familiar model name. A model name is therefore weaker evidence than a revision-specific relationship among the hardware, source release, SDK, and binary.
What crosses the organizational handoffs
The first handoff is from the SoC vendor’s platform work to the SDK used by downstream developers. What crosses it is more than a kernel version: it includes the selected kernel source, platform code, drivers, build evidence, and assumptions about the target hardware. The SoC vendor’s choice establishes a default baseline. If that baseline is old, the downstream team inherits a maintenance question before it has added the product’s own features.
The next handoff is integration. An ODM or OEM—an original design or manufacturing partner—uses the platform materials to assemble firmware for a device vendor. At this point, the integrator can preserve the SDK kernel line or, at least in principle, detach from it and adopt a newer supported line. The integration work changes the software image, but it does not automatically transfer ownership of every upstream dependency. A device vendor may set the product requirements and release the image while relying on the integrator to understand the platform details.
The final operational handoff is shipment and support. The branded vendor presents the router or camera as a product, publishes firmware, and communicates whatever support promise reaches the user. That vendor becomes the most visible point of accountability, but visibility is not the same as origin. If the vendor ships the inherited SDK baseline without examining its support status, a platform decision has been converted into a product-level maintenance obligation. If the vendor requires evidence of a supportable baseline, the same handoff can become an opportunity to interrupt inheritance.
Open-source communities and regulators sit differently in this arrangement. They do not usually control the original hardware platform or the vendor’s release pipeline. A community project may create an alternative firmware and a regulator may establish expectations for software updates or transparency. These forces can change the options available after or around shipment, but they do not rewrite the chain automatically. Their effectiveness depends on what information, drivers, source material, and authority are available at the boundary they are trying to influence.
A useful way to follow the chain is to track both an artifact and a decision. The artifact begins as platform source and build material, becomes an integrated firmware image, and ends as software installed on a router or camera. The decision is whether to preserve the inherited kernel line, modify it, or replace it. A later organization may own the image without owning every artifact that made the image possible. If the lineage is not recorded, the artifact survives while the decision disappears; later maintainers then have to infer the baseline from a binary, a source release, or a model name. That is precisely where false confidence can enter. A recognizable product can have an unrecognizable software ancestry.
The failure condition is not only that a device contains an old kernel. It is also that no participant can state which kernel is present, which platform components depend on it, or who would adapt a fix if upstream support ended. In that situation, a later security assessment can identify symptoms without locating the control point. Conversely, a documented lineage does not make the old baseline safe, but it makes the maintenance obligation visible enough to evaluate.
The diagram emphasizes the direction of dependency. The firmware release is downstream of the SDK even when the product contains substantial original work. The dotted path is not a claim that every product built on the platform is identical. It indicates that a reusable baseline can cross product boundaries. The critical state being carried forward is the kernel line and its relationship to the platform drivers and build environment.
At each handoff, a different question should be asked. The SoC stage asks whether the selected kernel line is supportable. Integration asks whether the device will inherit that line or deliberately change it. Product release asks whether the support promise is backed by evidence about the actual baseline. If none of these questions is answered explicitly, “the SDK already worked” becomes an accidental security policy.
Why reuse turns a local convenience into a system property
The paper’s measurements show the scale that this chain can acquire. In its corpus, researchers identified 102 SoCs across 306 SOHO devices. Fifty-two SoCs were used by more than one device and together covered 70 percent of the devices. Five major SoC vendors accounted for 94.7 percent of the identified SoC set. The figures describe the study’s identified sample rather than the entire router and camera market, and SoC identification covered 86.6 percent of devices. Even with that boundary, the pattern is consequential: security decisions made by a relatively small number of platform suppliers can be inherited by many downstream products.
Reuse creates leverage through two mechanisms. First, it reduces the amount of platform work each downstream team must repeat. A device vendor can build on a known SDK rather than reconstructing hardware support. Second, it makes the kernel baseline persistent across related releases. A new model may change its casing, radio configuration, user interface, or product features while retaining the same platform line. A firmware update may therefore alter the product without changing the foundational kernel choice.
The shared baseline is not the same as shared risk. Two devices using one SoC can enable different kernel components, apply different patches, or expose different interfaces. Hardware revisions may lead to different source and binary relationships. The study’s supply-chain evidence supports the claim that a platform choice can recur; it does not support the stronger claim that every product using that platform has an identical vulnerability set. This distinction is essential when moving from architecture to security measurement.
It is helpful to think of reuse as a common starting condition, not a common endpoint. The inherited line supplies a family resemblance. Product-specific configuration determines which parts of that family are actually built and exposed. That is why the same upstream platform can produce both a repeated maintenance concern and different device-level findings. A supply-chain analysis should identify the common anchor first, then let source and build evidence establish where the products diverge.
It also changes how responsibility should be assigned. A downstream vendor can reasonably say that the hardware-specific drivers and build material came from upstream. That explains a constraint, but it does not settle the decision to ship the baseline. The integrator and device vendor still determine whether they will inherit it, investigate its support status, or invest in a different kernel line. At the same time, it would be incomplete to treat the final vendor as the only actor that matters when the platform’s SDK has already narrowed the feasible choices.
The final firmware image cannot answer all of these questions by itself. It can show what software eventually reached the device, and its build artifacts may reveal a kernel version or platform marker. It may not show why that line was selected, which alternatives were considered, or whether a private patch stream exists. A published source release can provide more lineage evidence, but even source-to-binary matching requires care because model names, hardware revisions, and multiple releases can complicate the relationship.
This is the practical reason to keep the architecture model intact when evaluating a vulnerability claim. If an analyst sees an old kernel version in a router image, the observation identifies a possible maintenance concern. It does not yet establish which kernel code was built, which known vulnerabilities apply, or whether a vendor fix has been backported. The next step is not to count every CVE associated with that version. It is to compare the shipped image with the relevant source and build context closely enough to determine what is likely instantiated.
That comparison also sharpens the meaning of “upstream.” It does not mean that all security work happens at the SoC vendor, nor that downstream engineering is passive. It means that the earliest visible platform choice can constrain later work, and that the constraint becomes more significant when the same SDK is reused. Once the reader can trace the baseline from chip to SDK to firmware, the key measurement problem comes into focus: how to distinguish a general kernel’s historical vulnerability list from code that is actually present in a customized SOHO device.