OSS Security - Avoiding pitfalls in electronics projects
Open Source Software used successfully
If a few years ago you still had to explain the topic of open source software (OSS) in many projects, that's hardly the case nowadays. Thanks to Android, Qt, Flutter, Tensorflow and Co, OSS has found its way into many commercial projects.
As developers, we think that's great, because these open projects can also make commercial product development faster and easier to succeed. But with the great and easily available functionality of open source components also comes great responsibility. Because there are some pitfalls that need to be considered to successfully get to the goal.
Pitfalls on the way to the goal
The first pitfall is to blindly rely on uncontrolled (=not actively maintained) open source components. A second is not actively monitoring for security vulnerabilities in one's production software and thus, as already mentioned in point one, introducing serious security vulnerabilities into the product.
Synopsis published the report "Open Source Security and Risk Analysis" (OSSRA) on these topics. This provides insight into the current state of open source security, compliance, licensing and code quality risks in commercial software projects. Synopsis examined anonymized audit results from over 1,500 commercial codebases (the codebase is the code and libraries that make up an application or service) in 17 different industries. In the report, it quickly becomes clear that open source libraries are the foundation for literally every application in every industry.
Comparing industries, the use of open source libraries looks like this:
Statistics Use of OSS in %:
Energy and Clean Tech: 81
Computer Hardware and Semiconductors: 74%
Internet and Mobile: 82%
Retail and E-Commerce: 48%
It becomes clear: Especially in the core areas Energy and Medical, in which Ginzinger electronic systems is active, the spread of OSS is enormous. E-commerce, which brings up the rear, is an exception. But what does this widespread use mean for the security of the components used? Mixed feelings arise here.
At least one vulnerability was found in 84% of those analyzed. That's an average of 158 open vulnerabilities per codebase, and these had already been known for about two years. As a non-expert, it is difficult to say whether this is fatally bad or still quite okay in comparison. However, it is a fact that the number and criticality of vulnerabilities has been steadily increasing in recent years. This is also shown by the following statistics:
Statistics on at least one vulnerability per codebase:
One gets even more uncomfortable when looking at the evolution of the number of codebases that have a critical vulnerability over the last few years:
Fortunately, some sectors show a clear trend towards improvement. Leading the way here are IoT, Hardware & Semiconductors, and Internet & Mobile, as well as Manufacturing and Robotics. Here, the number of critical vulnerabilities in the codebases has decreased significantly.
A closer analysis of the vulnerabilities (CVEs) quickly makes it clear: The top vulnerabilities come for the most part from the Java Script world. Here, some were simply not upgraded to current versions. Or libraries were used, which are themselves based on old resources. This applies in particular to points one and two of the pitfalls mentioned: relying blindly on uncontrolled OSS components and not actively monitoring for security vulnerabilities in the productive software.
Avoiding vulnerabilities with software BOMs
Solutions to these issues are readily available. A software BOM (Bill of Material), for example, provides an overview of the software components and libraries used. This software BOM can then be compared with vulnerability databases via active monitoring. In this way, you can quickly see whether there are critical vulnerabilities in your own product. Again, what is secure today may be considered insecure tomorrow. The updated software can then be rolled out in a software patch, e.g. via secure over-the-air updates, to all products in the field. Another part of the solution is to keep your software close to the long-term support versions (LTS) and mainline versions. This is usually the most stable way to go and the best way to go in the long term.
GELin as a guarantor for secure products
Ginzinger electronic systems offers a simple solution to the pitfalls described. With GELin, our own Linux operating system, we rely on active monitoring of the software components, on a stable and long-term maintained mainline Linux, and on an easy-to-create software BOM. Thus, a project can be implemented quickly and without much effort. GELin is thus a guarantor of successful and secure products in the long term.
This complements the closing words of the Synopsis report, which sums up as follows:
"To meet the challenge mentioned in the report, development teams need reliable and timely vulnerability information, a comprehensive inventory of the open source dependencies their software uses, accurate guidance on vulnerability severity and exploitability, and clear instructions on how to patch the affected open source software."
Current webinars on the topic can be found here