Open-source robotics is particularly susceptible to hackers and bad actors, potentially jeopardizing projects. A lack of accountability worsens matters, as no one wants to take responsibility for publicly shared resources. How can software developers and robotics engineers protect their builds?
What Is Open-Source Robotics?
Open-source robotics is a field where people use publicly available code, schematics, and components — meaning content anyone can use, copy, modify, or distribute — for projects. These people develop systems and machines using publicly shared information, software, and hardware. Many document their build process, testing techniques, and bill of materials in great detail so others can benefit from their work.
In a traditional setting, software developers and engineers pay a vendor for a license to use proprietary resources or develop their own from the ground up. Rather than relying on a community, they entrust a single entity to maintain their tools. This practice is often more expensive and time-consuming than its open-source counterpart.
Many people — especially those with little capital or experience — prefer open-source resources because they’re easier and cheaper to acquire. These driving forces are why 77% of organizations were more reliant on it in 2022 than in 2021. Plus, they can tweak published code, tailoring it to their needs without paying for a license.
Many robotics startups and for-profit businesses are supporting this field’s growth. While some charge for their resources, most open-source data sets are free. Hobbyists and industry professionals publish free, open-source software (FOSS) to help accelerate innovation and foster interest in their community.
The Security Risks of Open-Source Resources
The reason enthusiasts value open-source robotics is also its biggest weakness. Publicly-available code isn’t just visible to well-meaning engineers — cybercriminals can access it just as easily, searching for weaknesses or bugs to exploit. Since they don’t have to pay for a license, the potential payout for success is larger, which entices them.
Vulnerabilities enable a range of cyber attacks. Bad actors can remotely take over tools, move laterally through a network to infect multiple devices, or overwhelm a system with traffic, depending on what they exploit.
Malware is another common risk of using FOSS. Bad actors can maliciously contribute code while posing as helpful community members. If unsuspecting individuals don’t review it properly, they unknowingly infect their robot in the early stages of the build process.
Those using a Robot Operating System (ROS) — a collection of open-source libraries and application-building tools — risk network infiltration and man-in-the-middle attacks. Unfortunately, it doesn’t offer defenses by default or support encryption, leaving developers responsible for implementing security measures.
Moreover, many ROS hosts are open to the public internet, meaning virtually anyone can remotely access connected robots or any device on the network. It’s one of the easiest — and most effective — attack vectors. One study found there was a 60% increase in the number of exposed hosts from 2018 to 2024.
Unfortunately, isolation from the public internet isn’t enough, as malware can breach isolated networks. Attackers can use network address translation (NAT) slipstreaming to bypass people’s firewalls and remotely access devices by getting their target to visit a malicious website. They can then move laterally through the network, accessing other endpoints.
Little is done about these risks despite their severity. According to a 2020 survey, open-source software developers only spend 2.27% of their time responding to security issues. When asked if they wanted to dedicate more time, the respondents admitted they’d only willingly increase their commitment by 0.6% on average.
The Consequences of Unsecured Robotics
The security issues of open-source robotics have far-reaching consequences, with one of the most concerning being the potential for unpredictable behavior. If bad actors use malware or NAT slipstreaming to access a robot remotely, they can force it to act erratically, misreport diagnostic logs, or shut down.
If attackers gain control of actuators, they can force a robot’s wheels to turn or joints to bend unexpectedly, potentially damaging critical components or their surroundings. It could strike nearby individuals or catch their clothing in moving parts, causing injuries.
Engineers may not realize their robot or other network-connected equipment is being attacked until it’s too late. Hackers can disguise their actions by forcing systems to provide false feedback, meaning everything appears fine even when components are actively failing.
Data theft is another common possibility. Once bad actors infiltrate a network, they can access a robot’s sensors or cameras to intercept readings or images. While intellectual property may not be a significant concern for those using FOSS, privacy and information security should be. While the average hacker may not feel compelled to destroy a random individual’s project mid-build, it’s not out of the realm of possibility for a threat group or competitor to target an open-source company.
The Rise of Open-Source Security Risks
Open-source software vulnerabilities are becoming increasingly frequent. Their number rose to 9,658 in 2020, up from 6,111 prior, representing a 58% increase year-over-year (YOY). While many developers in this field don’t prioritize security, this substantial surge should prompt them to. Otherwise, they may put others at risk and lose the trust of their community.
Notably, risk severity is also increasing. According to one analysis, the number of open-source codebases containing at least one high-risk vulnerability rose from 48% in 2022 to 74% in 2023, representing a 54% YOY increase. These indicators suggest this field may soon become a larger target for hackers.
Engineers should be just as concerned about the rise of FOSS risks since it jeopardizes their work. Considering even a single vulnerability can result in data theft, a cyber attack, or damage to their project, prioritizing defenses would be wise.
Ultimately, the responsibility of maintaining security is shared. No one progresses if developers patch a vulnerability, but users don’t update their software. It may seem simple, but many don’t follow this essential best practice.
In 2023, 91% of the codebases analyzed by one firm contained open-source components that were ten or more versions behind the most current release, meaning multiple updates were available but hadn’t been applied. This is a hacker’s dream and a cybersecurity professional’s nightmare.
Considering experts estimate spending on robot systems will total $66.9 billion by 2025, interest in affordable FOSS solutions will likely surge, meaning this field could become a bigger target for bad actors. Individuals should take action now to prevent losses later.
How to Make Open-Source Robotics Secure
Developers and engineers can take multiple approaches to secure open-source robotics.
1. Inventory Open-Source Components
No one can secure what they aren’t aware of. People building robots should inventory FOSS and their dependencies to understand where their weaknesses are. This act can also accelerate risk assessments, as it provides an overview of high-risk resources.
2. Incorporate Audits into Development
Professionals should leverage automation or schedule manual audits to ensure they get completed. Since 82% of open-source components have inherent security risks due to unpatched vulnerabilities, poor code quality, or maintainability concerns, frequent reviews are necessary for a secure build.
3. Follow Through With Updates
A zero-day vulnerability — a known weakness not yet patched — is a common issue with FOSS, as people are under no professional or contractual obligation to rush fixes. According to one analysis of tens of thousands of open-source projects, developers only patch 10% of vulnerabilities on average.
Individuals must be mindful of these vulnerabilities and frequently check for updates. In the meantime, they should establish temporary security measures to defend against the increased attack likelihood.
Forever-day vulnerabilities — weaknesses developers don’t intend to patch — are another concern. When they appear, it’s no longer a case of if a threat actor will attack but when. Although rewriting portions of code prone to attack can be challenging and lengthen the time to completion, it’s necessary in this situation.
The Bottom Line of Open-Source Robotics Security
Research shows many publicly available resources contain vulnerabilities, most of which the developer will never patch. The only reliable way people in this field can protect their projects from threat actors is to establish a security-first framework where audits, risk assessments, and code reviews become commonplace.
