Open source software security vulnerabilities exist for over four years before detection
It can take an average of over four years for vulnerabilities in open source software to be spotted, an area in the security community that needs to be addressed, researchers say.
According to GitHub’s annual State of the Octoverse report, published on Wednesday, reliance on open source projects, components, and libraries is more common than ever.
Over the course of 2020, GitHub tallied over 56 million developers on the platform, with over 60 million new repositories being created — and over 1.9 billion contributions added — over the course of the year.
“You would be hard-pressed to find a scenario where your data does not pass through at least one open source component,” GitHub says. “Many of the services and technology we all rely on, from banking to healthcare, also rely on open source software. The artifacts of open source code serve as critical infrastructure for much of the global economy, making the security of open source software mission-critical to the world.”
See also: The biggest hacks, data breaches of 2020
GitHub launched a deep-dive into the state of open source security, comparing information gathered from the organization’s dependency security features and the six package ecosystems supported on the platform across October 1, 2019, to September 30, 2020, and October 1, 2018, to September 30, 2019.
Only active repositories have been included, not including forks or ‘spam’ projects. The package ecosystems analyzed are Composer, Maven, npm, NuGet, PyPi, and RubyGems.
On average, vulnerabilities can go undetected for over four years in open source projects before disclosure. A fix is then usually available in just over a month, which GitHub says “indicates clear opportunities to improve vulnerability detection.”
However, the majority of bugs in open source software are not malicious. Instead, 83% of the CVE alerts issued by GitHub have been caused by mistakes and human error — although threat actors can still take advantage of them for malicious purposes.
In total, 17% of vulnerabilities are considered malicious — such as backdoor variants — but these triggered only 0.2% of alerts, as they are most often found in abandoned or rarely-used packages.
Defining the ‘worst’ open source vulnerabilities of 2020 is not an easy task as it depends on the reach of impact — on users and repositories — exploitability, and other factors. Some bugs may immediately come to mind, including Zerologon (CVE-2020-1472) and SMBGhost (CVE-2020-0796), but when it comes to project maintainers, GitHub has named a prototype
Pollution in lodash as a top vulnerability.
Tracked as CVE-2020-8203 and issued a severity score of 7.4, the RCE security flaw alone has been responsible for over five million GitHub Dependabot alerts due to lodash being one of the most widely-used and popular npm packages.
The open source community now plays a key role in the development of software, but as with any other industry, vulnerabilities are going to exist. GitHub says that project developers, maintainers, and users should check their dependencies for vulnerabilities on a regular basis and should consider implementing automated alerts to remedy security issues in a more efficient and rapid way.
“Open source is critical infrastructure, and we should all contribute to the security of open source software,” the organization added. “Using automated alerting and patching tools to secure software quickly means attack surfaces are evolving, making it harder for attackers to exploit.”
Previous and related coverage
Have a tip? Get in touch securely via WhatsApp | Signal at +447713 025 499, or over at Keybase: charlie0