GitHub’s State of the Octoverse report for 2020, an annual data-driven summary of developer activity on the platform, has found that open source vulnerabilities are continuing to go undetected for very long periods of time. The report finds that it has taken as long as four years to spot vulnerabilities in repositories. The vast majority of these are mistakes rather than malicious attempts, however, and developers have an average patch time of roughly a month once a vulnerability is discovered.
Open source vulnerabilities linger on GitHub
GitHub’s testing ran from October of 2019 to September 2020 and included 45,000 randomly selected repositories that were active and used at least one of the six supported package ecosystems, were not forked or used by GitHub staff, and had a dependency graph enabled (an indication that it is very likely a public repository).
The report indicates that use of any active repository on the site with package ecosystems will lead to a security warning most (59%) of the time. However, the vast majority of these issues (83%) are mistakes in the code rather than knowing and active attempts to exploit users. Additionally, 17% of the open source vulnerabilities that were identified as attack attempts triggered just 0.2% of the security warnings.
So, though there is a non-trivial amount of attempted hacking going on in the repositories, any security warning that pops is overwhelmingly likely to be due to some sort of faulty code. This may be contributing to the fact that open source vulnerabilities tend to go unaddressed for long periods of time. In fact, the report found that the “typical” time for a vulnerability to go unremediated was a whopping 218 weeks, or just slightly over four years. Once a vulnerability is discovered the average time to fix it is 4.4 weeks and it takes an additional 10 weeks to alert all users to the security update.
While four years may initially seem like an excessive and gaudy number, the report notes that it is common for vulnerabilities to go undiscovered by anyone (attackers included) for at least several years. A RAND report cited here indicates that zero-day vulnerabilities are typically not detected by opportunistic exploiters for five years on average.
Vulnerabilities are tracked on GitHub via advisories that are available through the public GitHub Advisory Database. A review of these finds that the Maven and npm package ecosystems had the most open source vulnerabilities overall and the most “critical” and “high risk”-rated vulnerabilities respectively. The NuGet ecosystem had far fewer vulnerabilities than any other package tested; RubyGems also fared well compared to the others, with no critical vulnerabilities and only about half as many overall as the category leaders. The report does note that NuGet’s advisories are not machine readable at this time, though, which is likely contributing to its unusually low numbers.
The report also devoted a great deal of time to the question of automation and its potential to improve security. The ultimate answer is that the question is still complex and evolving, but the authors did find that Dependabot alerts in repositories that automatically generate a pull request to update were resolved 13 days faster on average than those that were not yet automated.
GitHub, which has been a Microsoft property for about two years now, is used by some 56 million developers worldwide who contribute to about 60 million repositories hosted with the platform. Countless organizations in all manner of industries, including those that handle especially sensitive data such as health care and finance, rely on the site’s output. That makes open source vulnerabilities a potential threat to critical infrastructure, and at the very least something that can be used to compromise many different parties in a very short amount of time. Most modern applications rely on at least some amount of open source components, and the onus of tracking and patching these elements ultimately falls to each individual company.
Making improvements
The GitHub Security Lab makes a number of suggestions for developers that make use of the platform. These include checking dependencies for open source vulnerabilities on a regular schedule, having the security team actively participate in the community by sharing search findings, implementing automated alert and patching tools, and maintaining a policy of patching remediations as soon as possible.
Ilia Kolochenko, Founder & CEO of ImmuniWeb, expanded on the importance of patching early and often in regards to open source vulnerabilities: “The root problem is not detection of previously unknown Open Source Software (OSS) vulnerabilities: but well known and unpatched vulnerabilities. Virtually all industry reports and studies converge that a very small number, usually varying from 10% to 30%, of known OSS security vulnerabilities are ever patched. Rapid proliferation of containers – exacerbate the problem – as outdated and vulnerable software transform containers into ticking a time bomb … Today, cybercriminals don’t even bother to search for 0days: they have a myriad of vulnerable web systems accessible from the Internet. One can easily acquire fully automated exploits for them designed to compromise the flaw, backdoor the system and patch the vulnerability – to preclude “competitors” from getting in.”
GitHub report found that #opensource #vulnerabilities are continuing to go undetected for as long as 4 years on average. #cybersecurity #respectdataClick to PostOther strong suggestions related to the security of open source drawn from previous GitHub data breach incidents: never including login credentials in any sort of code or comments, implementing appropriate access privileges on a user-by-user basis, and mandating the use of multi-factor authentication (MFA) for anyone with access to sensitive information.
