Open Source, Open Doors to Better Security: How Our Community Is Hardening OpenRemote

Recently, our community helped us identify and resolve a subtle but important cross-tenant authorisation issue in OpenRemote. Someone actively poking around our open-source codebase spotted an edge case where tenant boundaries weren’t quite as watertight as we had designed them to be. In a multi-tenant IoT environment, where different users might be sharing underlying cloud resources or gateway infrastructure, these boundaries are everything. We verified the report, wrote a patch, and rolled out the update.

 

That specific interaction highlights the everyday reality of securing a modern IoT platform. It isn’t about writing flawless, impenetrable code on day one; it is about how quickly you can find, understand, and fix the imperfect bits before someone else exploits them.

 

The OpenRemote platform sits at a messy, fascinating intersection of hardware at the edge, local networks, cloud infrastructure, and user apps. That creates a massive attack surface. An edge gateway sitting in a muddy agricultural field faces entirely different threats than a cloud-hosted instance. At the same time, regulatory frameworks like the European Union’s Cyber Resilience Act (CRA) are rightly making ‘secure by design’ a legal baseline rather than an optional extra. The gap between someone discovering a vulnerability and actively exploiting it has shrunk from months down to hours. We have to catch flaws early.

 

So, how do we keep up with that pace? The answer lies in combining the transparency of open source with AI-assisted white-box testing.

 

In the security world, black-box testing means probing a system from the outside, essentially guessing how it works based on how it reacts. White-box testing, on the other hand, gives the tester full access to the source code, system architecture, and network configurations. It is a far deeper, more comprehensive way to find structural flaws. However, genuine white-box penetration testing is much more than just running automated static analysis (SAST) over a codebase. It requires understanding the business logic, which traditionally takes a huge amount of manual, human effort.

 

With OpenRemote being 100% open source, we are essentially giving everyone the keys to do their own white-box testing. We believe that hiding your architecture is a terrible security strategy. But historically, even with open code, automated scanners produced a lot of noise. They lacked context, often flagging unreachable code paths and drowning developers in false positives.

 

This is exactly where AI is changing the game. Modern AI tools evaluate files by mapping the application’s architecture and understanding how local code actually interacts with internal APIs and databases. When you point these tools at an open codebase, they perform deep analysis rapidly. They trace decision points and data flows to uncover complex business logic flaws or authorisation bypasses that automated black-box tools miss. Put simply: open code makes white-box testing possible for anyone, and AI makes it fast enough to keep up with agile development cycles.

 

In the open-source world, we love to quote the “many eyes” theory—the idea that with enough eyeballs, all bugs are shallow. But history tells a rather different, more sobering story. Critical vulnerabilities like Heartbleed and Log4Shell sat undiscovered in completely open code for years. Having your code out in the open does not automatically mean skilled security researchers have the time, funding, or inclination to read every single line of your repository. Humans get tired, and reading other people’s complex infrastructure code is rarely glamorous work.

 

AI bridges this exact gap by providing the tireless “eyes” that the open-source theory always promised but rarely delivered.

 

However, we also need to be realistic about AI’s limitations. These tools are not magic, and they certainly don’t replace human engineers. AI still produces false positives. It suggests patches that absolutely require human review before we can safely merge them. And, perhaps most frustratingly for project maintainers, AI can easily be used to flood repositories with low-quality, automated bug reports. The maintainer of the widely used curl project recently spoke out publicly about this exact problem—wasting hours chasing down AI-hallucinated security threats that did not actually exist. We are using AI to reduce our security debt, but we cannot pretend it eliminates the need for human expertise, context, and careful review time.

 

At OpenRemote, our approach to security is about finding the right, practical balance. We rely on the transparency of our open-source codebase to let anyone inspect our architecture. We encourage our community and our own team to use AI tools to scan, test, and find flaws at high speed. But most importantly, we rely on human developers and users to verify these findings, contribute practical fixes, and harden the platform.

 

When a community member finds a vulnerability and contributes a fix upstream, the entire ecosystem benefits instantly. A subtle improvement discovered by one user in an edge case becomes instant armour for deployments worldwide.

 

We want you to get involved in that process. You do not need to be a cryptography expert or a seasoned penetration tester to help. Pull our codebase from GitHub, run it through your preferred testing tools, and see what you find. If you spot a flaw, let us know. If you can write the patch, even better. Let’s build a secure IoT ecosystem together.