Microsoft-owned GitHub, the world’s largest platform for open-source software, has found that 17% of all vulnerabilities in software were planted for malicious purposes.
GitHub reported that almost a fifth of all software bugs were intentionally placed in code by malicious actors in its 2020 Octoverse report, released yesterday.
Proprietary software makers over the years have been regularly criticized for ‘security through obscurity’ or not making source code available for review by experts outside the company. Open source, on the other hand, is seen as a more transparent manner of development because, in theory, it can be vetted by anyone.
SEE: Security Awareness and Training policy (TechRepublic Premium)
But the reality is that it’s often not vetted due to a lack of funding and human resource constraints.
A good example of the potential impact of bugs in open source is Heartbleed, the bug in OpenSSL that a Google researcher revealed in 2014, which put a spotlight on how poorly funded many open-source software projects are.
Affecting a core piece of internet infrastructure, Heartbleed prompted Amazon, IBM, Intel, Microsoft, Cisco and VMware to pour cash into The Linux Foundation to form the Core Infrastructure Initiative (CII).
For the past few years, GitHub has been investing heavily in tools to help open-source projects remediate security flaws via its Dependency Graph, a feature that works with its Security Alerts feature.
The security alerts service scans software dependencies (software libraries) used in open-source projects and automatically alerts project owners if it detects known vulnerabilities. The service supports projects written in Java, JavaScript, .NET, Python, Ruby and PHP.
GitHub’s 2020 Octoverse report fond that the most frequent use of open-source dependencies were JavaScript (94%), Ruby (90%), and .NET (90%).
While almost a fifth of vulnerabilities in open-source software were intentionally planted backdoors, GitHub highlights that most vulnerabilities were just plain old errors.
“These malicious vulnerabilities were generally in seldom-used packages, but triggered just 0.2% of alerts. While malicious attacks are more likely to get attention in security circles, most vulnerabilities are caused by mistakes,” GitHub notes.
As ZDNet’s Charlie Osborne reported, vulnerabilities in open-source projects remain undetected for four years on average before they’re revealed to the public. Then it takes about a month to issue a patch, according to GitHub. In other words, there’s still room for improvement despite GitHub’s efforts to automate bug fixing in open-source projects.
GitHub notes in its report that the “the vast majority” of the intentional backdoors come from the npm ecosystem. ZDNet’s Catalin Cimpanu reported this week that the npm security team had to remove a malicious JavaScript library from the npm website that contained malware for opening backdoors on programmers’ computers. Using this venue to distribute malware to developers makes sense given that JavaScript is the most popular programming language on GitHub.
SEE: Google: Here’s how much we give to open source through our GitHub activity
GitHub notes that only 0.2% of its security alerts were related to explicitly malicious activity.
“A big part of the challenge of maintaining trust in open source is assuring downstream consumers of code integrity and contitinuity in an ecosystem where volunteer commit access is the norm,” GitHub explains.
“This requires better understanding of a project’s contribution graph, consistent peer review, commit and release signing, and enforced account security through multi-factor authentiticatition (MFA).”
GibHub notes that flaws can include ‘backdoors’, which are software vulnerabilities that are intentionally planted in software to facilitate exploitation, and ‘bugdoors’, which are a specific type of backdoor that disguise themselves as conveniently exploitable yet hard-to-spot bugs, as opposed to introducing explicitly malicious behavior.
The most blatant indicator of a backdoor is an attacker gaining commit access to a package’s source-code repository, usually via an account hijack, such as 2018’s ESLint attack, which used a compromised package to steal a user’s credentials for the npm package registry, GitHub said.
The last line of defense against these backdoor attempts is careful peer review in the development pipeline, especially of changes from new committers. Many mature projects have this careful peer review in place. Attackers are aware of that, so they often attempt to subvert the software outside of version control at its distribution points or by tricking people into grabbing malicious versions of the code through, for example, typosquatting a package name.
