External Components Management: Open Source or Oroprietary Software?
During Embedded World 26 we shared how Linutronix uses Open Source Software for regulated industries at our booth and at the conference as summarized in this blog post. (Download the presentation here)
So why do we need to “manage” anything here at all? Even a minimal Linux-based embedded system pulls in hundreds of packages. Each one is a potential vulnerability, a potential supply-chain attack surface, a potential licensing problem. The question though isn’t whether to use them, but how to manage them responsibly.
The XZ Utils lesson
The 2024 XZ Utils backdoor is a tale that sounds like it may come from a crime show. A malicious actor spent three years cultivating trust as a contributor by submitting innocent patches, but started to apply social pressure on the original maintainer (who publicly mentioned limited resources and mental health difficulties), and ultimately gained commit access. In February 2024, a disguised backdoor was added. It reached Debian’s unstable branch but never hit stable. On March 28, 2024, engineer Andreas Freund noticed SSH logins were taking roughly 500ms longer than expected. Days to detect; hours to revert.
The lesson goes both ways: open source enabled the attack vector (public contributor access), but open source also enabled the response: a broad community with access to source code, not a closed vendor deciding whether to disclose on their own timeline.
Proprietary isn’t the answer either
SolarWinds Orion – a fully proprietary IT monitoring software – had attackers inject a backdoor into official builds around February 2020. It took about ten months to find and publicly disclose the backdoor. Many large and governmental organizations were highly exposed during that window. The Realtek Jungle SDK, a proprietary SDK for network device builders, carried remote code execution vulnerabilities (CVE-2021-35392 through -35395) that spawned millions of botnet attacks and many devices remain unpatched today because there’s no community to push fixes downstream.
Rolling your own isn’t the answer as well
WhatsApp’s custom MP4 parser led to remote code execution (CVE-2019-11931). The DVD Content Scramble System’s custom cryptography was cracked. Sony’s PlayStation 3 used a custom ECDSA implementation that was broken due to a well-known nonce-reuse flaw. Keyless car entry systems have repeatedly shipped weak custom crypto. Cryptography is not a place for bespoke engineering.
The actual answer: Open Source + Support
discovery. Supported open source combines auditability (you can read
and patch the code) with accountability (a vendor who can be held
responsible). Neither proprietary software nor unsupported community
projects offer both.
Evaluating components
The Open Source Security Foundation’s Concise Guide for Evaluating Open Source Software provides a checklist: maintainer diversity, activity level, vulnerability status, release recency, dependency management, static analysis, security audits, repository security, and more. It’s a structured approach to what used to be gut-feel decisions about which packages to trust.
Classification and the management process
IGLOS implemented a four-tier classification system for every external component:
Every development build automatically generates an SBOM (Software Bill of Materials) and compares it against the component database. New components trigger a need statement from the developer, a security analyst assessment using the data collection framework, and a formal classification. Red components are blocked. Yellow and Blue require developer-implemented mitigating countermeasures before passing review. Green (and mitigated Yellow/Blue) components proceed to the release build, after which continuous monitoring catches any new CVEs or community health deterioration.
source — it’s to fund it. Organisations that depend on open source
components should contribute back, financially or in code. It’s not just ethical; it directly reduces the attack surface of your own product.
What This Means for Your Product
The IGLOS Secure Beacon demonstrates that a hardened, certified, fully open-source embedded Linux platform is not only possible — it’s already done. The certification is real, the tools are open, and the methodology is documented. What remains is applying the pattern to your application.
For teams facing the 2027 CRA deadline, the practical implications are:
Treat dependency management as a security process, not a packaging task. Automated SBOM generation and a structured classification process are table stakes for any certified product.
Choose supported open source, not unsupported open source. The audit trail and the accountability structure matter to certification bodies. A vendor standing behind a package is evidence; an abandoned GitHub repo is a liability.
Contribute upstream. Healthy maintainers are resilient maintainers. Contributing to open source components you depend on is supply-chain security, not charity.
Contributing to open source and supporting maintainers is not only fair — it protects your supply chain.
— Linutronix, Embedded World 2026
The era of treating open source as a compliance risk to be managed around is over. With the right process for external component management, the right tooling, and the right community engagement, it is the most defensible foundation you can build on.