What Lurks Beneath: The Risk of Hidden Open Source

Recently, our CEO Alan Facey published a thought-provoking article titled "Would You Build a Car Without Knowing What’s In It?", which challenges the way we treat software risk in embedded systems. His point was simple but stark: while we meticulously track every physical component in a vehicle, we often treat embedded software that controls critical systems, with a fraction of that scrutiny. This imbalance is no longer sustainable—especially as open source code has become pervasive in automotive systems. 

When engineering a vehicle, no responsible designer would ever ignore the components that go into critical subassemblies. Every sensor, actuator, and line of firmware is scrutinised because even a single fault—whether in hardware or embedded software—can cause a system failure with real-world consequences. Automotive manufacturers demand traceability and verification not because it’s convenient, but because safety, regulatory compliance, and reputational risk leave no room for ambiguity.  

Yet in software more generally, particularly with the increasing use of open source code, the same level of rigour is often missing. Many suppliers rely on Software Bills of Materials (SBOMs) generated from declared dependencies, typically via package manifests. But this approach ignores the reality of automotive development: software is rarely a collection of neatly isolated modules. Instead, it’s an intricate web of direct, transitive, and often undeclared dependencies. In many cases, third-party code—open source or otherwise—is integrated into the codebase in ways that evade detection. Code fragments may be copied and pasted from external sources, suggested by AI tools, or inherited from legacy libraries  and included into software that runs on vehicle ECUs. This reality create hidden risks—and in safety-critical environments, invisible risks are the most dangerous kind. As Alan’s article notes, while hardware components are routinely scrutinised, software is often treated with far less discipline—a mismatch that needs urgent correction.   

This matters because the stakes are very high in automotive, where regulations such as UNECE R155 and R156 tightening the compliance net. These regulations explicitly call for cybersecurity management and software update traceability. But if the codebase includes fragments of open source or third-party code — perhaps introduced years ago, or by AI coding assistants — and those components are not detectable by current tools, then any claim of traceability falls apart.  

“Your organisation’s ability to manage software risk is constrained by the visibility provided by your tooling,”   - Alan Facey, CEO. “From Our CEO: Would You Build a Car Without Knowing What’s In It?” 

This is not a theoretical problem. Many vulnerabilities in modern vehicles originate from transitive or hidden open source code, quietly inherited and never reviewed. These components may contain outdated cryptography, unfavourable licences, or known vulnerabilities, but without source-level scanning, they remain invisible. And unlike in high-level applications, software embedded into vehicle systems tends to live longer. Once burned into a vehicle’s ECU or firmware image, it may remain in circulation for years — unpatched, unmonitored, and unaccounted for. 

“Log4Shell didn’t hit because people declared Log4j—it hit because they didn’t know it was there.”   -Alan Facey, CEO. “From Our CEO: Would You Build a Car Without Knowing What’s In It?” 

Suppliers may hope their Tier 1 customers will handle the risk, but enforcement and liability are shifting upstream. Major automotive brands expect their suppliers to guarantee compliance. If you’re in the supply chain, the responsibility lies with you to prove your code is safe, traceable, and clean. 

Unfortunately, most scanning tools weren’t built for this modern reality. They focus on package manifests and metadata. They struggle in environments where code is transformed or somehow stripped of context. What’s needed are tools that operate at the source level, detecting third party code across languages, and generating SBOMs that reflect the actual code, not just the declared dependencies. 

But more than tooling, a mindset shift is required. Embedded software must be treated with the same supply chain discipline as hardware. That means aligning with standards like ISO 26262—not out of bureaucracy, but because failure carries a real-world cost measured in recalls, safety issues, and reputational damage. 

We would never accept building a car with undocumented components. The same must now apply to embedded software. Traceability must reach into the firmware and down to the source. Because what hides in a few reused lines of code can trigger a failure, a breach, or a recall. In this industry, risk is engineered in—or out. If your code is embedded, your responsibilities are too. 

This is why SCANOSS is investing in source-first scanning: not to replace SBOMs, but to complete them. With a language-agnostic engine and forensic detection of even the smallest third party code fragments, SCANOSS is helping embedded developers and automotive suppliers uncover what’s really in their software. So you don’t just hope it’s clean—you know it is.