Quality assurance in the software supply chain
Author: Dr. Ralf Huuck, Synopsys
Contribution – Embedded Software Engineering Congress 2017
In most development projects, software isn't written from scratch but builds upon existing components. These components can come from previous projects, open-source repositories, or vendors. External sources, in particular, present challenges: How can you ensure that these third-party components meet your 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 composition solutions can be used to identify and automatically prevent these vulnerabilities during the development process.
Introduction
Software security is playing an increasingly significant role in the development of embedded systems. This is especially true as software development projects grow in size and progress rapidly. Current examples include driver assistance systems and Industry 4.0 applications, where software can comprise millions of lines of code while simultaneously performing safety-critical tasks. These challenges are further compounded by extensive supply chains. This means that the final system often consists of additional components supplied by third parties, which may include both open-source software and third-party code.
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.
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 of existing open-source components, determines the version numbers of these components, and compares them against existing vulnerability databases. The primary vulnerability database is the National Vulnerability Database (NVD) of the US National Institute of Security Technology (NIST) [3]. This database contains approximately 90,000 entries documenting known vulnerabilities (CVEs) and assigning them a security-critical metric according to the Common Vulnerability Scoring System (CVSS) [4].
Results for embedded open-source components from 2016/2017
The 2016/2017 study encompasses approximately 130,000 uploads to the Protecode platform. Over 16,000 different components and versions were identified. Figure 1 (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 2 (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 hasn't 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 Composition Analysis into the SDLC
It is unrealistic to forgo components from open-source and third-party sources. They are a valuable tool for developing 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 integrate third-party components without prior checks. Fortunately, software solutions such as Protecode, Sonatype, and Black Duck are now available on the market that can perform these checks automatically [5]. Furthermore, these software solutions can also be integrated directly into the development process. This means, for example, that a DevOps Jenkins process can be initiated, which performs an automated analysis during each product build, detects open-source components, and compares them with 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 security vulnerabilities are routinely found in third-party components. Nevertheless, third-party components and open-source packages are indispensable for modern software development. It is crucial that the supply chain is not accepted with blind trust, but rather continuously monitored for its security aspects. Software solutions in the field of composition analysis now enable this to be done efficiently and cost-effectively.
In the medium term, supply chains can be managed and improved in terms of quality through composition analysis. This can be achieved, for example, by establishing a close feedback process with suppliers, refusing acceptance if safety is insufficient, or requiring automated pre-checks on the supplier side. This can be designed to benefit all parties involved.
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, December 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.
author
Dr. Ralf Huuck Dr. Huuck is a Technical Director at Synopsys, Australia. He works in the tooling division of the Synopsys Software Integrity Group, supporting tool development to ensure standards-compliant products reach market safely and quickly. Previously, Dr. Huuck was Managing Director of Red Lizard Software, Sydney, and a long-time Research and Development Director at the NICTA research institute. He is also an Adjunct Associate Professor at UNSW, Australia, specializing in software security.
Contact
Email: ralf.huuck@synopsys.com
Internet: https://www.synopsys.com.software
Software Engineering Management – 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 Software Engineering Management / process, project and product management.
Training & coaching on the other topics in our portfolio can be found here. here.
Software Engineering Management – Expertise
Valuable expertise in software engineering management / process, project and product management is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
