Our lives are increasingly conducted in a digitized, data-driven world built on infrastructure that depends upon open source software (OSS). Despite its considerable merits, open source poses a security threat, as its growth in adoption is accompanied by a corresponding increase in related security vulnerabilities. Many organizations do not effectively address these threats due to a lack of visibility into, or the difficulty of tracking, OSS usage through their complex software supply chains. More security-conscious organizations deploy sophisticated tools to identify and manage the relevant issues in their codebase. But even these more prepared organizations are at risk, as these tools rely on government-sponsored, centralized vulnerability databases that are characterized by incomplete coverage and delayed publication of information. The economic and public safety impact of OSS-related risks is growing exponentially as open source usage expands beyond general purpose servers to devices embedded in homes, cars and public infrastructure.
Consequently, there is an urgent need to increase visibility into open source security; to create new financial incentives for users to find, report and address vulnerabilities – and maintain a democratized database of vulnerabilities that is both secure and committed to the full disclosure of information. Leveraging blockchain technology and cryptocurrency appears to be a cornerstone to effectively address these issues.
The pace of open source software development and use is increasing at a staggering rate. The Linux Foundation estimates that more than 31 billion lines of code have been committed to open source repositories. According to research conducted by OSS risk management company Synopsys, in a span of just 12 months that comprised part of 2017 and 2018, the average percentage of codebases comprised of open source software jumped from 36 percent to 57 percent. This indicates that most applications now contain more open source than proprietary code.
So who’s using all that open source software? According to findings from the same Synopsys study, the answer is – everyone. The audit, which examined more than 1,000 commercial applications, detected open source components in 96 percent of scanned commercial applications. Additionally, the average application contained 257 unique open source components. This growth in OSS adoption is, unfortunately, a double-edged sword. Though a valuable engine of innovation and efficiency, OSS code (like its proprietary counterpart) harbors well-known security vulnerabilities with the potential to debilitate entire IT infrastructures. The Synopsys audit revealed that 78 percent of analyzed applications using open source components contained at least one security vulnerability. Fifty-four percent of the detected vulnerabilities ranked as “High Severity.”
In late 2017, the general public saw a large-scale example of this problem with the Equifax security breach. Hackers exploited a vulnerability in the Apache “Struts” component, using it to expose the private information of more than 148 million users. Despite of having more than two months to execute preventative measures, Equifax failed to address the issue. The data breach not only reminded everyone that OSS-related security vulnerabilities are a common target for hackers to exploit, but also demonstrated the difficulty enterprises face in monitoring and mitigating these types of risk.
These vulnerabilities are also present in popular mobile applications. In April 2018, Insignary, an open source security company focused on binary-level scanning, published a study testing the security of the 700 most popular Android apps on the Google Play Store. Based on the scans of their APK files, the company found that approximately one in five apps contains security vulnerabilities. The results from another study conducted by Insigary in early-2018, demonstrated that popular home, small-to-medium (SMB), and enterprise-class Wi-Fi routers are not exempt from OSS-related security vulnerabilities. The study revealed that the router firmware from the 10 largest router manufacturers were vulnerable, with 50 percent of the firmware using OSS components containing “Critical Severity” security risks.
These findings indicate that it is not just the software running on enterprise servers that is exposed to the risks posed by OSS security vulnerabilities; in fact the device world — with its plethora of hardware configurations and software versions, deployed to the everyday consumer — carries the same, or even higher level of risk.
These facts point to growing risk that must be addressed – and quickly. New vulnerabilities, such as the one that led to the Equifax breach, are found every day. In 2017, 14,712 new vulnerabilities were listed on the National Vulnerability Database (NVD). The same year, 4,800 new OSS-related vulnerabilities were reported. Addressing this issue is particularly critical as the IoT industry expands from a history of monitoring and managing individual, simple mobile devices to a future of intelligently automated industrial networks of devices across all industry verticals – not to mention in homes, automobiles, office buildings, medical devices and core infrastructure. The risks of both financial liability and public safety demand that the current situation must be resolved. While individual innovators can develop stronger tools for organizations to mitigate the risk of publicly-known vulnerabilities, it takes a different approach to create the stronger knowledge base to find and publish the as-yet unknown security bugs.
There are two challenges that must be addressed so that responsible organizations can protect their servers and devices from the risk represented by open source vulnerabilities. The first is the difficulty organizations face when trying to gain visibility into and control over the OSS components in their code base. Security technology innovators such as Synopsys and Insignary are addressing this issue by providing software composition analysis (SCA) tools to help users identify and manage their open source usage. They also equip customers with a customized security report so that organizations can practice effective OSS risk management. This is where the second problem arises. To produce this report, SCA tools leverage external databases of known OSS-related vulnerabilities, against which they map the customer’s individual risk. However, these databases are managed by a centralized and limited group, inadequately equipped to address the escalating number of OSS projects and associated security risks. As a result, the information found in these databases is incomplete, inaccurate and not up-to-date – preventing organizations from addressing security vulnerabilities as efficiently and effectively as possible.
The most popular (yet still problematic) vulnerability database is the National Vulnerability Database (NVD), a database funded by US-CERT, an organization within the US Department of Homeland Security. The NVD uses the Common Vulnerabilities and Exposures (CVE) reference-method system, which assigns each publicly disclosed security vulnerability with a CVE identification number. CVE IDs are provided to researchers, vulnerability disclosers, information technology vendors, and are used to communicate with software development teams. These IDs are assigned by the CVE Numbering Authority (CNA), a group of less than 100 qualified organizations around the world that includes large corporations like Google and Microsoft.
The centralized nature of CNA’s management means that vulnerability reporting is oriented towards security issues specific to software built and managed by organizations that comprise the CNA. Google will focus on finding potential security vulnerabilities in Google products, as will Facebook and Microsoft. This bias in vulnerability detection leaves many important OSS projects lacking in corporate support underserved.
Due to the CNA’s closed management, there is often a significant time lag between the first discovery of a vulnerability and the publication of this vulnerability on the NVD. Recorded Future, a Boston-based security research firm, discovered that out of 12,517 observed vulnerabilities – open, deep or dark web coverage revealed 75 percent of these vulnerabilities prior to their inclusion on the NVD. The firm reported an average of 33 days between the initial announcement of the problem and its subsequent publication on the NVD. This time lag presents a huge problem, as it not only slows down the response time of support organizations to address gaps, but also extends the window of opportunity during which malicious actors can hack enterprise servers and personal devices.
In comparison to NVD, China’s National Vulnerability Database (CNNVD) demonstrates better efficiency in reporting vulnerabilities, with an average of 13 days between the first reporting of a vulnerability and its inclusion in the database. Thanks to this shortened time lag, the CNNVD houses more up-to-date information about software vulnerabilities than does its U.S. counterpart on any given day. But this is still far from optimal.
Moreover, there are underlying problems concerning cybersecurity issues which may be considered even more critical than the described above. The second part of the article will describe these issues and the possible solutions.