A Belated Patch Is Better Than None

Smart hubs and digital assistants can make it look like the smart devices in your home work as a single unit. The illusion vanishes when a vulnerability that affects products from different vendors needs patching, as delivery time for the firmware containing the fix varies from one brand to another.

Regardless of their origin, internet-of-things devices in your home share more than just a network connection. Many depend on code and hardware from a handful of third-party makers to fulfill essential functions: chips for wireless connection and processing, and software resources that establish and maintain connections or search for other devices on the network.

A vulnerability in any component is likely to affect more than just the product it was discovered in. Take the BlueBorne vulnerability bundle found in the Bluetooth protocol last year; its impact extended to billions of devices with Bluetooth support. A more recent report revealed the Meltdown and Spectre flaws in CPUs from Intel, AMD and ARM.

Getting all vendors of products affected by wide-reaching vulnerabilities to release new firmware that eliminates the security problem is nearly impossible. The reason is the production process, which gives the vendor varying degrees of control over the firmware, in many cases making delivery of a bug fix a coordinated and collaborative effort.

A vendor may purchase a finished product from a hardware partner according to specifications, and only apply its brand label. Under this model, known as original design manufacturing (ODM), the supplier also provides the firmware, and the vendor has to distribute it to customers. The vendor has an active role in shaping the final product under the joint development manufacturing (JDM) model when the brand owner works with multiple suppliers of hardware and software components to build the final product.

The JDM model also involves the vendor in the process of creating the firmware and choosing the software that goes into the gadget – libraries for specific features; open-source or proprietary components are the usual choice, to keep costs as low as possible.

When a vulnerability for a particular internet-of-things gadget is disclosed to the public, a security-conscious brand usually has a patch waiting in the wings, allowing customers to apply it at their leisure, or it has already pushed it to the connected things. With ODM, the vendor waits for the hardware maker to create the fix, if the agreement with the original supplier includes this service.

The process is more complex in the case of JDM because the vendor is involved in how changes move into the product; it also has to ensure that the new firmware is in agreement with all components. However, the degree of control of the brand owner is greater, and there are better chances to receive fixes, at least for a while.

Thus, in a fragmented production context, you may have to be more patient with some vendors than with others, even if the patch addresses a vulnerability in a common element. Vendors of white-label products lack this type of privilege, and their deal with the supplier may be limited to building and shipping the device, with no obligation for maintenance services.