The Mend database continuously aggregates information from across the open source and security ecosystems, collecting data from the NVD, dozens of security advisories, peer-reviewed vulnerability databases, and popular open source issue trackers. It currently includes over 270M open source components and 13 billion files. Our comprehensive data enables us to gain valuable insights into the state of open source security and learn how to keep up with the rapid pace of software development without leaving security behind.
This is part of an extensive series of guides about open source
New Challenges to Application Security in 2020
2020 was a particularly challenging year with the pandemic turning the world – the software development industry included – upside down. Within days, companies were forced to adjust to remote work, which introduced new types of security threats. In the early days of the pandemic many organizations’ budgets were put under scrutiny, causing some concern that investment plans for application security would be put on the back burner.
The Number of Known Open Source Security Vulnerabilities Continues to Skyrocket
According to Our database, the number of published open source software vulnerabilities in 2020 rose by over 50%.
A number of factors contributed to the significant rise in reported vulnerabilities. Some have to do with the open source community, and others in the security research community:
The addition of CVE Numbering Authorities (CNAs), including Mend, also contributed to the increase in published vulnerabilities.
Extensive use of automated scanning and detection tools to find vulnerabilities enabled security researchers to find and fix security issues quickly and at a greater volume.
In some cases, researchers found multiple CVEs where a common problem affected many projects. Sometimes a single CVE was applied to many projects, but other times it was correct for them to each have their own CVE.
Most Common CWEs in Open Source Components
We also looked for the most common CWEs in vulnerable open source components detected in 2020, in order to gain insights on secure coding with open source components.
Some of the most common CWEs in 2020 are consistent with previous years, while others are new to the list. One of these is CWE-787, which might seem like it came out of nowhere, but it’s actually a descendent of the common CWE-119 (buffer overflow), which saw a decrease this year.
These changes are a result of a large remapping effort of over 10,000 CVE entries, which included mapping CVEs directly to weaknesses like CWE-787 and CWE-125 instead of categories like CWE-119. Improper Input Validation and Information Exposure are other examples of categories that are being remapped into more precise weaknesses.
Open Source Vulnerabilities in Top Programming Languages
Continuing our research into secure coding, we also looked at some of the top programming languages, and how many and what type of open source security vulnerabilities were disclosed per language.
The biggest shifts in the number of reported vulnerabilities happened in C, PHP, and Go. The increase in buffer overflow related issues is one of the reasons that C saw so many new vulnerabilities in 2020. The decrease in the number of vulnerabilities in PHP is probably a result of decreased popularity and community interest.
Go is a relatively young language, and the rising number of vulnerabilities discovered in Go might also be because many Go projects are written from scratch, rather than using open source libraries and components that have been under the security microscope for years.
Open Source Vulnerabilities: Severity Breakdown
As the number of reported open source security issues continues to rise and alert fatigue becomes an increasing challenge for security and development teams, how can organizations make sure that the biggest security threats are addressed first?
Prioritization of vulnerabilities has become a challenge for organizations battling security debt, and many choose to rely on vulnerabilities’ severity score — CVSS to determine which vulnerabilities demand immediate remediation.
Unfortunately, this doesn’t help teams narrow down the extensive list of vulnerabilities that require remediation. The research report shows that over 50% of new open source security vulnerabilities are rated high or critical – leaving teams with a long list of vulnerabilities that need to be addressed.
Fixing all high and critical issues is an unrealistic plan for teams that want to keep up with the rapid pace of development. Organizations need to leverage prioritization and remedian tools that target the vulnerabilities that will most impact their systems and business if they want to manage their security debt wisely.
Addressing Open Source Security in 2021
The challenge of staying on top of open source security in today’s software development ecosystem might seem like a daunting task. As the pace of development and delivery continues to accelerate, software development environments become more layered and complex, relying on a multitude of third-party applications and platforms.
As organizations continue to adopt application security testing tools, it’s important that they don’t stop there in their journey to achieve DevSecOps maturity. Open source security tools and processes need to be put in place as early as possible in the development lifecycle, and developers should be given the automated tools that they need in order to address security without slowing them down.
It’s also important to remember that in order to achieve application security in general and open source security in particular, vulnerability management needs to go beyond detection to address prioritization and remediation so that issues are fixed as soon as possible, rather than added to a laundry list of security alerts.