Securing Open‑Source Software in IoT: Mitigating Software Risks

There are now 7 billion IoT devices worldwide. CAST’s Lev Lesokhin projects that the count will triple by 2025, reaching 21.5 billion devices. The rapid growth has spurred manufacturers to launch products faster than ever, often at the expense of software quality.

To accelerate time‑to‑market, many firms rely on ready‑made packages from open‑source communities such as GitHub and Apache. Yet, as CAST’s 2018 Software Intelligence Report shows, a large share of these projects fall short of security compliance.

Open‑source code rarely comes with robust, built‑in security. In the rush to ship, companies may forgo thorough security reviews, leaving every one of the seven billion devices vulnerable to attackers.

Unlike enterprise‑grade transaction systems, much IoT firmware originates from embedded‑software engineers whose primary focus is functionality rather than data‑protection. This mismatch means that many developers lack the specialized skills required to safeguard sensitive data.

Because anyone can contribute to open source, ensuring that security and quality standards are upheld is inherently challenging. Inefficient, sloppy, or even malicious code can slip through unnoticed.

Buyers rarely spot these weaknesses. They view IoT devices as tools for business efficiency, not as potential vectors that can be weaponised against their owners.

The eyes of the world are on your code

Proprietary, in‑house code can contain flaws, but only the contracted developers typically see them. Proprietary source is private and shielded from prying eyes. In contrast, open source is publicly accessible—everyone, including potential attackers, can examine it before it is incorporated.

In 2013, Target suffered a credit‑card breach costing $220 million (≈€194 million) after attackers exploited a flaw in its climate‑control system. The vendor’s credentials were stolen and left unchanged at deployment, leaving every installed unit exposed.

Check yourself before you wreck yourself

While vulnerabilities can never be eliminated entirely, their likelihood can be curtailed by following three key steps:

1. Understand your software’s lineage. Manufacturers must know precisely what code they ship. When used responsibly, open source can be invaluable, but its provenance should be traced to the source and cross‑checked against known vulnerabilities.

2. Allocate sufficient time for security. Post‑manufacturing fixes are costly and often ineffective. The Target incident illustrates how easy it is for attackers to exploit lingering flaws once a device is in the field.

3. Perform end‑to‑end analysis. Scan the entire codebase, promptly address highlighted weaknesses, and eliminate technical debt. The goal is a resilient system that protects end users for years to come.

Ultimately, Target’s climate‑control vendor remains under investigation, with ongoing costs around $18.5 million (≈€16.3 million). Such a costly oversight can—and should—be avoided.

The author of this blog is Lev Lesokhin, EVP of Strategy & Analytics at CAST.