Getty Images
IoT developers can't afford to ignore third-party code
IoT developers must adopt best practices -- such as regular updates -- for incorporating third-party code into IoT devices and addressing potential vulnerabilities.
As ubiquitous internet connectivity creates endless feature possibilities for connected devices, it also accelerates new challenges that IoT developers can't ignore.
Organizations increasingly deploy advanced capabilities such as computer vision and machine learning at the edge, which adds technical complexity and makes solving field issues much more difficult. The operational complexity affects product function and can brick connected devices entirely. Often, it's because of the work of someone else's work.
IoT developers have traditionally focused on hardware, but connectivity requires increasing amounts of embedded software and, generally, a third party creates that software. As the utility and reach of IoT devices grow, there's no doubt that managing and understanding third-party code is something everyone in the industry must consider.
Third-party software components play an increasingly critical role within IoT. From 2015 to 2020, the use of third-party commercial code in IoT products more than tripled, from 17% to 56%, according to VDC Research. In a connected device, developers can build in third-party software as part of communication libraries, encryption libraries, communication protocols or within the communication modules of chips and components.
Widely used third-party code can also introduce major vulnerabilities into IoT device management. For context, imagine a popular wearable device that has implemented a monitoring platform to capture operational data and push over-the-air (OTA) updates. It then experiences an unavoidable vulnerability in the third-party code library, leaving its OS open to potential security breaches. Despite best development practices, rigorous testing and comprehensive management capabilities, seemingly secure connected devices can fall victim to third-party code bugs.
The risk isn't unknown. Nearly three-quarters of IoT developers recently said security was critical to development, according to VDC Research. However, only 56% of organizations have formal policies and procedures for testing the security of IoT devices. It's a huge disconnect.
Leaving it up to the providers of third-party code to mitigate or manage vulnerabilities can be risky. For example, some creators may be committed to regular hardware and firmware updates. Others might be bound by considerations like component licensing, which prevents them from quickly and efficiently root sourcing or addressing bugs. Some may not consider updates at all.
Until industry regulation spells out requirements for third-party code in IoT device development, the onus falls on device manufacturers to follow best practices. Here are three of the most important:
1. Consider third-party code as part of a holistic development program
Especially in a connected world, the decisions developers make across all stages of development have the potential to make large and lasting organizational and operational impacts. Developers should evaluate the effects of third-party code at all stages of the development cycle. Evaluation is necessary when developers are determining requirements and making user interface decisions, when coding a process for risks and compliance, and during regular auditing for both familiar code and code that has been deployed for quick fixes.
2. Devices must be updateable in the case of third-party code
IoT development used to mean writing static firmware for specific device use cases. Once released, developers would have no further interaction or engagement with the product. But connectivity has increased end-user expectations of device longevity and functionality. Now IoT device manufacturers must invest in device design and development, as well as firmware development and ongoing device operations, including accounting for third-party bugs. That requires building devices with a plan for sending OTA updates and integrating observability into devices to measure health and how third-party code impacts the devices.
3. Device manufacturers must know what they're working with
To prepare for unknown issues -- and to preempt known ones -- IoT developers must have a continuous understanding of what third-party code they depend on, the license it is offered under and the author's support. But developers must go a bit further in terms of their third-party code visibility. Most third-party code is provided and deployed as is. It is incumbent on engineers to have a working understanding of what the third-party code does under the hood because they -- not the third-party code authors -- will have to fix it when bugs inevitably come up.
The expanding significance, growing consumer demand and looming industry regulation suggest that IoT device manufacturers must continuously improve and iterate on their products. Having full awareness of how those operations depend on third-party code and avoiding the pitfalls blind dependence could engender ensures better device operation, happier customers and overall better products.
About the author
François Baldassari is the founder and CEO of Memfault, the connected device observability platform provider. An embedded software engineer by trade, Baldassari's passion for tooling and automation in software engineering drove him to start Memfault. Previous to Memfault, François led the firmware team at Oculus and built the OS at Pebble. Baldassari has a B.S. in electrical engineering from Brown University.
