New Research Shows Secure Usage of Open Source Remains Problematic
If I told you that the average number of vulnerabilities in commercial software was up 93% in the past year, you’d start questioning my source. Yet that’s precisely what the sixth iteration of the Open Source Security and Risk Analysis (OSSRA) report produced by the Synopsys Cybersecurity Research Center (CyRC) shows. This increase comes as the number of open source components in an application also grew, by close to 19% in a year. Put another way: as open source usage grows in a codebase, the number of vulnerabilities explodes. But why?
To answer that, we need to look at the data itself. In this year’s OSSRA report, our data consists of 1,546 audits of commercial software performed in 2020, as part of a technical due diligence effort during a merger or acquisition. This diligence effort is part of the core business of the Black Duck® Audit Services team, and they have a very long track record and stellar reputation for accuracy in this space. The Synopsys Cybersecurity Research Center takes the data from these audits and builds the OSSRA report to highlight trends in open source usage within commercial applications; as well as to provide insights that help development teams better understand the software ecosystem they’re a part of.
Of the codebases audited last year, we found that 98% of them contained open source and a whopping 84% had at least one vulnerability (with an average of 158 per codebase). This is a 9% increase from 2019 and it’s the second-highest increase we’ve seen since 2017.
Similarly, the percentage of codebases containing high-risk open source vulnerabilities increased to 60% in 2020, a dramatic 11% increase from 2019.
It should be noted that when we speak of a “high-risk” vulnerability, this indicates that a vulnerability has been actively exploited in the wild, or has documented proof-of-concept exploits, or has been classified as a remote code execution vulnerability. Four of the top ten open source vulnerabilities that appeared in codebases audited in 2019 re-appeared in our most recent research, all with significant percentage increases as well.
Interestingly, 91% of the codebases audited contained open source components that hadn’t seen any development activity in the past two years — meaning there were no code improvements and no security fixes. This tells us that while the open source community does an exemplary job of addressing security issues, an alarming number of companies simply aren’t applying those patches.
Beyond the likelihood that security vulnerabilities exist in older code, one of the biggest risks of using outdated open source components occurs when the eventual update is applied. Unlike commercial software where targeted hotfixes are the norm, a security update to an open source project is far more likely to be a simple point release. In other words, if you are running version 1.2.5 and it’s been some time since you updated that component, the fix to a high-severity vulnerability patched in version 1.2.26 will require you to take all the functional changes between these versions. Such a gap is likely to cause issues elsewhere and will require additional testing to ensure that your applications function correctly with the update.
In terms of open source licensing, over 90% of the audited codebases contained at least one open source component with license conflicts, customized licenses, or no license at all. In fact, 65% of the codebases audited in 2020 contained open source software license conflicts, typically involving the GNU General Public License. Twenty-six percent of codebases were using open source with no license, or a customized license. All three of these issues often need to be evaluated for potential intellectual property infringement and other legal concerns, in the context of a merger and acquisition transaction.
Tips to Secure Your Usage of Open Source
So, what can your organization do to better secure your usage of open source?
Inventory
Can you say with confidence that you know all the open source components used anywhere in your business? Do you know where they came from and how the project owners communicate updates? Do you have the same visibility into open source in commercial applications, or even firmware? If you can’t answer these questions, then it’s highly likely you have a patch management blind spot — because you simply can’t patch what you don’t know you have.
Monitor for Updates
Unlike commercial software, where fixes, patches and updates can be pushed to users, open source communicates using a pull support model. You are responsible for keeping up-to-date on the updates for the open source you use. With the growth in open source use, that’s a task far beyond spreadsheets, manual tracking and periodic inventories.
Focus Your Security Scans
If you’re not running software impacted by a vulnerability disclosure, then you can’t be exploited by it. Focus scanning efforts using your open source inventory plus triage remediation and mitigation activity based on CVSS (Common Vulnerability Scoring System) scores, paying particular attention to temporal metrics. Exploits may not exist on day zero of a vulnerability disclosure, but could appear days later — something that is captured in the CVSS scores.
Conclusion
In the end, I have a challenge to issue. We know that open source usage is going to continue to grow. It is an innovation engine. What we don’t have to accept is the growth of unpatched vulnerabilities. The open source community does its part by quickly addressing security bugs. You need to do your part by applying those patches as soon as they’re issued. It’s the only way we can reduce the number of unpatched vulnerabilities in software.