EN 
DE How to properly manage open source (and other) software
Author: Dr. Ralf Huuck, Synopsys
Contribution – Embedded Software Engineering Congress 2018
Recent studies have shown that well over 90% of all new software projects use open source [6]. This is only natural, given the widespread use of open-source standard packages and tools. The question that arises is: How can one ensure that these open-source components meet one's own quality, licensing, and security requirements? This article highlights some of the risks associated with embedding third-party components and presents the results of a global study on security vulnerabilities in open-source components. Based on this, it explains how automated software scanning solutions can be used to automatically detect these vulnerabilities and risks during the development process and prevent their release in the final product.
Introduction
Open-source software is an important component of many products. The security of open-source software is generally comparable to that of in-house developed software. The "many eyeballs" principle helps to meet relevant security standards. Conversely, this also means that attackers can examine the open-source packages used to exploit potential vulnerabilities. A critical issue is that security gaps often only become known after a considerable period of time, once the packages have already been incorporated into the product.
Software security is becoming an increasingly significant challenge in the development of embedded systems. This is especially true for larger software development projects and those that evolve at a faster pace. Current examples include driver assistance systems and Industry 4.0 applications, where the software can comprise millions of lines of code while simultaneously performing safety-critical tasks.
An example of the impact of third-party security vulnerabilities is the MIRAI botnet [1]. This botnet, in its various incarnations, comprises over 130,000 embedded systems, mostly internet-enabled surveillance cameras, which were compromised by hackers through a common vulnerability in a supplied component. Although the surveillance cameras were distributed by different manufacturers, they were based on supply chains with the same board and driver software containing the same vulnerability.
Below, we present some results from our investigation into the risks of embedded software components. We explore the following questions: How frequently do software components have security vulnerabilities, and how critical are these vulnerabilities? Furthermore, we introduce some solutions for automatically detecting and preventing these vulnerabilities during the development process.
Growing number of open-source usages and known vulnerabilities
The use of open-source software is now the norm, and generally, its quality is comparable to internally developed software. However, open-source packages integrated from external sources often lack specific quality controls and reviews. The "many eyeballs" principle is frequently relied upon. This is particularly surprising given that up to 961,000 of all new software projects use open-source software [6].
Vulnerabilities in open-source software are often well-documented as soon as they become known. Patches are frequently available but are often implemented with a delay. The US agency NIST maintains the primary database of open-source software vulnerabilities. This National Vulnerability Database (NVD) [3] comprises approximately 90,000 entries that document known vulnerabilities (CVEs) and assign them a security-critical metric according to the Common Vulnerability Scoring System (CVSS) [4].
Figure 1 (see PDFThe chart shows the number of newly discovered security vulnerabilities each year. This does not mean that open-source software has become worse, but rather that its number has increased and that it is increasingly being examined for vulnerabilities.
Results regarding security vulnerabilities in open-source components
Synopsys regularly publishes investigations into security vulnerabilities in open-source components. These investigations summarize the results of software uploaded to the Protecode platform [2]. Protecode is an analysis software that examines binaries for existing open-source components, determines the version numbers of these components, and compares them with existing NVD entries.
Results for embedded open-source components
The 2016/2017 study encompasses approximately 130,000 uploads to the Protecode platform. Over 16,000 different components and versions were identified. Figure 2 (see PDFFigure 1 shows a breakdown of the most frequently identified components according to their function and area of use. Approximately two-thirds of all components are utilities for Windows and Linux tools, network protocols such as SSL and HTTP, and media libraries for JPG, PNG, or XML.
These components are typically used as open source because they simplify standard functions and generally do not require reimplementation. It is mistakenly assumed that these components are secure or have no safety-critical impact.
However, it turns out that approximately 9,000 security vulnerabilities (CVEs) can be identified from the more than 16,000 different components. This means that a large number of the components are not secure. Furthermore, the discovered vulnerabilities are not new, as shown in Figure 3 (see...). PDF) shows.
This means that approximately 50% of all security vulnerabilities are four years old or older. In most cases, a newer and more secure version exists but has not been used. This time discrepancy is also related to the fact that it often takes some time for security vulnerabilities to be discovered. This means that software considered secure today may have newer findings tomorrow. This is difficult for manufacturers to control and correct.
Automatic integration of open-source scanning into the SDLC
It is unrealistic to forgo components from open-source sources. They are a useful tool for producing products cost-effectively and relatively quickly. Furthermore, it is by no means proven that open-source components are inferior to in-house developed software. In fact, the opposite is often true.
Nevertheless, it is not advisable to install third-party components without prior checks. Fortunately, software solutions such as Protecode, Sonatype, or Black Duck are now available on the market that can perform these checks automatically [5].
Ideally, regular scans are performed to conduct these checks. It is helpful to create a risk model and link the software release to it. An example of this is shown in Figure 4 (see PDF) shown.
The security risk reflects the vulnerabilities found in the reviewed software, the licensing risk the use of inappropriate licenses, and the operational risk consists of a combination of security, frequency of the components used, and project activity.
To ensure this information is always readily available, these software solutions can be directly and automatically integrated into the development process. For example, a DevOps Jenkins process can be initiated that performs an automated analysis during each product build, detecting open-source components and comparing them to their known security vulnerabilities. These results can then be made available to the software development and quality teams in a timely manner.
Summary and Outlook
The findings presented here demonstrate that while open-source software is widespread, security vulnerabilities are also routinely found in these components. Nevertheless, open-source packages are indispensable for modern software development. It is crucial that these components are not used with blind trust, but rather that their security aspects are continuously monitored. Software solutions for open-source scanning analysis now enable this efficiently and cost-effectively.
In the short term, one-off scans are helpful for gaining an overview of your own projects and codebases. In the medium term, however, this scanning process should be integrated into the development cycle to enable timely risk assessment. This then allows for the definition of automatic acceptance thresholds that, for example, halt the CI/CD process or generate automated emails. Furthermore, it is often possible to establish links between existing products with their open-source components and new research findings. This means that an alert is automatically generated if a new vulnerability is discovered in an integrated component.
Furthermore, it is advisable to develop an update strategy. What risks am I taking before updating or patching a component? How do I manage this process within my software lifecycle? Who is responsible, and what kind of security culture do I cultivate? These are often questions that extend beyond the development teams and must be addressed across all groups.
References
[1] Constantinos Kolias, Georgios Kambourakis, Angelos Stavrou and Jeffrey Voas. DDoS in the IoT: Mirai and Other Botnets. IEEE Computers, Volume 50/7, 2017.
[2] Synopsys Software Integrity Group. The State of Software Composition 2017.
https://www.synopsys.com/software-integrity/resources/analyst-reports/state-of-software-composition-2017.html
[3] Harold Booth, Doug Rike, Gregory A. Witte. The National Vulnerability Database (NVD): Overview. ITL Bulletin, Dec. 2013.
[4] Peter Mell, Karen Scarfone, and Sasha Romanosky. 2006. Common Vulnerability Scoring System. IEEE Security and Privacy 4, 6 (November 2006), 85-89.
[5] Millar S. Vulnerability Detection in Open-Source Software: The Cure and the Cause. Queen's University Belfast, 2017.
[6] Synopsys Center for Open Source Research and Innovation. Report: 2018 Open Source and Security Risk Analysis.
author
Dr. Ralf Huuck is a Technical Director at Synopsys, Australia. He works in the tool development division of the Synopsys Software Integrity Group, supporting tool development to ensure standards-compliant products are brought to market safely and quickly. Previously, Dr. Huuck was Managing Director of Red Lizard Software, Sydney, and for many years Head of Research and Development at the NICTA research institute. He is also an Adjunct Associate Professor at UNSW, Australia, specializing in software security.
Open Source – our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Open-Source / Embedded Software Engineering.
Training & coaching on the other topics in our portfolio can be found here. here.
Open-source expertise
Valuable expertise in the field of Open-Source / Embedded Software Engineering is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
