Almost two years after the infamous Equifax breach, many organizations still struggle to identify and manage open source risk across their application portfolios.
Meanwhile, the latest report tracking open source security shows a 40 percent rise in the average number of open source components detected in each codebase analyzed. The scanned software includes commercial applications.
Black Duck by Synopsys on Tuesday released its annual Open Source Security and Risk Analysis, which examines the open source audit results of scanned codebases to identify insightful trends and patterns in open source usage. The report also looks at the prevalence of insecure open source components and software license risk.
Titled “Understanding Open Source Risk and Why It’s So Important to Manage,” the report compiles research backed by the Synopsys Cybersecurity Research Center (CyRC). It provides an in-depth look at the state of open source security, license compliance and code-quality risk in commercial software.
The CyRC Belfast team examined findings from the anonymized data of more than 1,200 commercial codebases reviewed by the Black Duck Audit Services team in 2018. The 17 industries represented in the report range from aerospace to virtual reality. The audit services team reviewed an average of 71 codebases per industry during 2018.
The continued growth of open source components in commercial codebases is mitigated by the report’s finding that many of open source vulnerabilities detected were first disclosed more than a decade ago.
The percentage of codebases containing vulnerable components has decreased, the report notes. The percentage of codebases containing license conflicts also has decreased.
The least surprising trend identified is that open source adoption has continued to rise, and the majority of codebases contain more open source than proprietary code, according to Tim Mackey, senior technical evangelist at Synopsys.
“One trend that is concerning is that the majority of codebases (60 percent) contain at least one vulnerable open source component, and 40 percent contain at least one high-risk vulnerability. Similarly, open source license compliance continues to be a challenge, with 68 percent of codebases containing some form of open source license conflict,” he told LinuxInsider.
Results Highlights
Audits found open source in more than 96 percent of codebases scanned in 2018. That percentage is similar to the figures from the last two OSSRA reports.
Most of the codebases that contained no open source consisted of fewer than 1,000 files. More than 99 percent of the codebases scanned in 2018 with more than 1,000 files contained open source components.
In most industries, the year-to-year difference in the percentage of codebases containing open source was negligible, according to the report. The audited codebases generally were from companies whose business is building software rather than from enterprises for whom software supports their main business.
The audits found, on average, 298 open source components per codebase in 2018 versus 257 in 2017. Open source represented 60 percent of the code analyzed in 2018, up from 57 percent in 2017.
“The main takeaway from this report is that the security and license compliance risk associated with the use of open source is very real, but it is the risk that can be managed with a proactive open source governance policy, automated tools like software composition analysis and an effective patching strategy,” said Mackey.
Encouraging Indications
This year’s report shows signs of an improving situation. There definitely are encouraging data points suggesting the industry may be turning the corner in terms of organizations’ ability to manage open source risk, noted Mackey.
For example, while 60 percent of codebases contained at least one vulnerable open source component, that number is down significantly from the 78 percent observed in the 2018 OSSRA report, he said. Likewise, the 68 percent of codebases containing some form of open source license conflict is slightly better than the 74 percent seen in last year’s report.
“This is a good thing, as it shows how teams are continuing to leverage open source to accelerate innovation,” Mackey observed, “but more open source also means more open source risk that needs to be managed.”
Enterprise IT and corporate security workers should not be concerned that the rise in open source code may create greater security risks, suggested Tobie Langel, principal at consulting firmUnlockOpen.
“There is no reason to believe that open source software is inherently less secure than closed source software,” he told LinuxInsider. “However, when a security issue is found in open source software that is used across the industry, the impact can be greater, as it is ubiquitous.”
Sustaining and securing open source is the industry’s biggest challenge right now — but open source also is where the most innovation is happening.
“I am confident we will get there,” Langel said. “Open source is by far the most effective means of building software and innovating at scale, once we find the right set of solutions to provide long term maintenance. It will also be the most secure solution by far.
Common Code Risk Critical
Numerous components were commonly used across different codebases, researchers found. For example, jQuery, open source software using the permissive MIT License, was found in 56 percent of the scanned codebases and in virtually every industry covered in the OSSRA report.
Other notable open source components found in the scans include Bootstrap, an open source front-end Web framework; jQuery UI, a curated set of user interface interactions, effects, widgets and themes built on the jQuery JavaScript Library; and Font Awesome, an open source font and icon toolkit based on CSS and LESS.
Despite using so much open source, few companies accurately track the components they use in their code. Most lack the policies, processes and tools to keep up with the choices made by their developers, according to the report. As a consequence, all the good functionality that comes with open source also brings along a variety of risks.
“Open source libraries are a double-edged sword,” remarked Manish Gupta, CEO of ShiftLeft.
Widely used open source software tools are generally more stable and more robust than custom code, he told LinuxInsider, because they are deployed in a variety of environments and have been battle-tested.
Bugs and vulnerabilities potentially are reported and fixed much faster than in custom-code that is leveraged by only one organization. However, the documented system of CVEs means that attackers know how your libraries are vulnerable, Gupta cautioned, and they can create an exploit much more easily.
“This means that consumers of OSS must stay on top of patches, which is not always easy to do,” he said. “The security industry hasn’t provided effective solutions to the developers to deal with this dilemma. The tools merely tell developers which OSS libraries being used are vulnerable.”
Clarifying Risk From Use
A key takeaway in the report is the care it takes not to mischaracterize the findings as an attack on the use of open source technology itself. Open source is not less secure than proprietary code. Nor is it more secure.
All software has weaknesses that are potential vulnerabilities, whether the code is proprietary or open source, the report warns. Organizations that use open source must identify and patch.
That management process is challenging, since most organizations have thousands of different pieces of software, ranging from mobile apps to cloud-based systems to legacy systems running on-premises. Software in general is a mix of commercial off-the-shelf packages, open source software and custom-built codebases — and vulnerabilities affect all of them, the report emphasizes.
“The use of any software comes with inherent risks, but open source software presents a few unique challenges,” said Mackey.
The first challenge concerns license obligations that can be opaque and easy to overlook compared to commercial software. The second challenge is the responsibility for identifying and patching open source security vulnerabilities, which falls solely on the organization using the software.
“Commercial software vendors can proactively urge, or in some cases, force their customers to update or apply security patches,” Mackey said. “Managing open source security and license risk should be viewed as an accepted cost of otherwise free open source software.”
Attack Vectors Persistent
An alarming number of companies fail to patch the software they use, whether proprietary or open source, the report said. That makes them targets.
Unpatched software vulnerabilities are one of the biggest cyberthreats organizations face. Unpatched open source components in software add to security risk. Certain characteristics of open source make vulnerabilities in popular components attractive to attackers.
Makers of commercial software can push fixes, patches and updates to users automatically. Open source has a pull support model. That makes the users responsible for keeping track of both vulnerabilities and fixes for the open source software they use.
The pervasiveness and ubiquity of open source pose management tasks that extend far beyond many organizations’ capabilities, as they do not do manual tracking of components, their versions and their vulnerabilities, according to the report.
Assistance Required
Organizations using open source must establish management strategies to identify and patch known vulnerabilities in open source components, notes the report. Vulnerabilities are disclosed through sources such as the National Vulnerability Database (NVD), mailing lists, GitHub issues and project homepages.
The widespread use of open source makes it imperative for organizations to keep accurate, comprehensive and up-to-date inventories of the open source components used in their applications. An incomplete inventory makes it extremely difficult to maintain adequate software asset management procedures, according to the report.
The increase in open source vulnerability age, despite a decrease in the number of codebases containing open source vulnerabilities, is interesting, said Synopsys’ Mackey, “but our audits often reveal that organizations are tracking less than half the open source in use. You can’t patch what you aren’t aware of.”
Sample Solutions
One solution for organizations using open source code is to tap into readily available sources tracking vulnerabilities, suggested Gabriel Bianconi, founder of Scalar Research.
“Large projects often have mailing lists announcing bug fixes and vulnerabilities,” he told LinuxInsider. “There are several vendors providing software to monitor security risks in open source libraries and dependencies used by your company.”
More often than not, the biggest problem is that the company is using an outdated version of the codebase that does not contain the latest security patches.
“Professionals must ensure that their dependencies are consistently updated,” Bianconi said.
Breaking Breaches
“POODLE,” “Heartbleed” and “Spectre” are not just cute monikers for security vulnerabilities. They are very real and potentially dangerous holes, noted Steve Tcherchian, chief product officer at XYPRO.
When an application vulnerability is identified, it typically is followed by a patch or new version to remediate the vulnerability, he explained, and with the proliferation of free and open source software, this activity becomes critically important.
“Oftentimes procrastination takes over, and the application is not timely patched for a variety of reasons,” Tcherchian told LinuxInsider. “This now leaves the application wide open to a published, and in most cases, publicized vulnerability.”
As for how to change the mentality within a development organization to be more security-focused, education and reinforcement are key, Tcherchian said.
“Security cannot be left for the end. Introduce security into your development processes early and re-introduce them often,” he added.
More Action Needed
The report cites a conclusion by the U.S. Senate Permanent Subcommittee on Investigations declaring that Equifax’s lack of a complete software inventory was a contributing factor to its massive 2017 data breach.
A number of reliable strategies exist to ensure that open source components used in applications are up-to-date with crucial patches applied, noted Matt Wilson, chief information security advisor at BTB Security.
“The good news is that they aren’t terribly complicated. What is important is that teams are aware of what you run in your environment, which can be hard for less mature organizations,” he told LinuxInsider.
The process involves maintaining awareness of updates to the code you run, applying patches as quickly as possible, and ensuring you conduct regular testing of your application/environment as a catch-all, Wilson explained.
Several industries, such as government, healthcare and automotive, have started to adopt standards that require organizations to inventory and track their use of open source components in a software bill of materials, according to Synopsys’ Mackey.
“This is a good first step,” he said. “After all, you can’t manage risk you don’t know exists.”
Loading ...
