Security flaws in open source software have increased and can take a long time to be added to the National Vulnerability Database, says RiskSense.
Open source software offers certain benefits over commercial products. As the source code is publicly available, developers can modify and tweak OSS applications to enhance their capabilities. Plus, the huge number of people who use these programs serve as a crowdsourced way to test their reliability and security. However, that doesn’t mean OSS applications are immune from flaws and vulnerabilities.
SEE: SQL injection attacks: A cheat sheet for business pros (TechRepublic Premium)
In fact, when a security hole emerges in an open source product, the damage can be widely felt throughout all uses and reuses of the source code. A report released Monday by vulnerability management firm RiskSense describes the impact of security vulnerabilities on OSS.
For its report “The Dark Reality of Open Source,” RiskSense found that the total number of CVEs (Common Vulnerabilities and Exposures) in OSS are on the rise, more than doubling to 968 in 2019 from 421 in 2018 and 435 in 2017. The increase doesn’t seem to be an anomaly as the number of new CVEs has stayed at a high level (178) during the first three months of 2020.
Further, OSS vulnerabilities often take a long time to get added to the US National Vulnerability Database (NVD), a valued resource for information on security flaws. RiskSense discovered that the average time between the public disclosure of a vulnerability and its inclusion in the NVD was 54 days. A total of 119 CVEs had lag times of more than a year, while almost a quarter had lag times of more than a month. The longest lag time seen was 1,817 days for a critical PostgreSQL vulnerability.
The lags were observed across all severities of vulnerabilities, with critical vulnerabilities having some of the longest average lag times, according to the report. The long waits create a risk for organizations and users who rely on the NVD as a primary source for data on security bugs.
Some OSS applications are plagued with more vulnerabilities than are others. The Jenkins open source automation server had the most CVEs with 646, while MySQL came in second with 624. These two OSS products tied for the most weaponized vulnerabilities (those exploited in the wild) with 15 each. HashiCorp’s Vagrant had only nine CVEs, but six of them were weaponized. Such OSS products as Apache Tomcat, Magento, Kubernetes, Elasticsearch, and JBoss all had security flaws that were popular in real-world attacks.
Among the vulnerabilities found in OSS, cross-site scripting (XSS) and input validation were among the most common and the most weaponized. XSS issues were the second most common but the most weaponized, while input validation issues were the third most common and the second most weaponized. Other vulnerabilities that were much less common yet still popular in cyberattacks were deserialization issues (28 CVEs), code injection (16 CVEs), error handling issues (2 CVEs), and container errors (1 CVE).
On the plus side, of the 978 vulnerabilities seen in 2019, only 15, or 1.5%, were weaponized. And among the 2,694 total vulnerabilities that RiskSense tracked over the past five years from 2015 through the first three months of 2020, only 89, or 3.3%, of them were weaponized. Still, OSS vulnerabilities can be a “blind spot” for many organizations who may not be aware of all the open source projects and dependencies found in the applications they use.
“While open source code is often considered more secure than commercial software since it undergoes crowdsourced reviews to find problems, this study illustrates that OSS vulnerabilities are on the rise and may be a blind spot for many organizations,” RiskSense CEO Srinivas Mukkamala said in a press release. “Since open source is used and reused everywhere today, when vulnerabilities are found, they can have incredibly far-reaching consequences.”
Source of Article