![The Edge Logo The Edge Logo](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt530eb1f4e672eb44/653a71690e92cc040a3e9d6d/Dark_Reading_Logo_TheEdge_0.png?width=700&auto=webp&quality=80&disable=upscale)
Cybersecurity In-Depth: Feature articles on security strategy, latest trends, and people to know.
The Truth About Vulnerabilities in Open Source Code
Turns out the problem isn't with the code itself, experts say.
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt280e0f392c30f82d/64f0d0c1e0df3aae3b778afa/5.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
Nearly 60% of all codebases used by enterprises contain at least one vulnerability from open source components, according to the "Open Source Security and Risk Analysis" (OSSRA) report, published by Black Duck by Synopsys.
As worrisome as that might sound, the reality is that whether it's proprietary code or open source code, software will inevitably have vulnerabilities. But experts overwhelmingly agree that open source code libraries are far more secure than commercial software.
The problem isn't in the use of open source libraries. Software vulnerabilities exist because writing secure code is very difficult — which is one reason why so many companies rely on open source projects.
"Open source code isn't intrinsically more secure; it is more securable," says Justin Hutchings, senior product manager, security at GitHub. "If [companies] write less custom code, there's a smaller chance that they'll introduce novel security issues. However, using open source also requires that companies remain as diligent about updating their open source dependencies as they would be about updating their own code."
Driving Innovation with Open Source
To stay competitive, companies need to use open source code, says Bart Copeland, CEO of ActiveState. "Today, in any organization, if you are not using open source, you will be left irrelevant," he says. "The only way to drive innovation, speed, quality, and cost is by adopting open source."
It's about focusing on where you add value, Copeland adds. In areas where an organization itself doesn't add value, it relies on other people. The same is true for developing software applications. "There is a host of applications out there that are not core to your business, and that's where open source comes in," Copeland says.
Where Are the Vulnerabilities?
The problem of seeing the same vulnerabilities over and over again is not in the open source code but in the lack of scanning and monitoring of the different libraries enterprises use to develop products.
"If developers are using open source libraries to develop their products and there is a vulnerability, the risk belongs to the organization," says Chris Eng, chief research officer at Veracode. Because applications are increasingly being assembled from open source components, the potential for vulnerabilities turning into risk is magnified.
Unfortunately, many organizations don't know where their risks are because they are not managing the software or the versions of the software they are running, even though tools are available to help mitigate and manage software risks.
"What it boils down to is that you don't know what you don't know," says Cody Brocious, hacker and head of hacker education at HackerOne. "We haven't done a great job of educating people on managing their networks from a security frame of mind, which includes having audit logs around creating new servers and knowing what software is being used."
Most organizations don't have a clearly defined policy that ensures developers who want to use a piece of software go through an authorization process. "There is not a lot of direct return on that investment,” Brocious says. "People don't think about those processes, and developing and adhering to policies costs money."
Vulnerability vs. Risk
Worth repeating in any conversation about open source code vulnerabilities is that the bugs are from the software libraries, not the applications themselves. And because open source libraries are used in a whole slew of applications, those vulnerabilities can affect a large swath of applications.
"In most cases, though, those library vulnerabilities don't reduce the security of the application. The libraries aren't used in a way that makes them vulnerable,” Brocious says.
While the risk should always be considered in context, it's important to note the difference between the technical aspect and what an attacker can actually do with the vulnerability. Still, bear in mind that users don't care how the software is built.
"When the Equifax breach happened, users weren't lining up to sue The Apache Foundation, but the vulnerability started in their Struts library," GitHub's Hutchings says.
Managing Open Source Risk
Because a lot of enterprises don't know what software they are running in the first place, when a vulnerability is detected, it's difficult to look at their networks and know whether and where they might be running a version of the software.
"The problem here is that many organizations fail to keep track of released updates in third-party components combined with the transparency of the open source community," says Craig Young, computer security researcher for Tripwire's VERT (Vulnerability and Exposure Research Team). "Vendors often use open source as a way of cutting down costs and getting to market faster without realizing the need to closely track these components for security or licensing issues."
In general, Young adds, organizations that have forged ahead without the proper policies are likely lacking the expertise necessary to effectively catalogue and manage their software. While it might be helpful to look outside the organization for help, there are also scanning tools for licensure that are able to go through and search for common code patterns and attribute them back to the original project.
Regularly looking at the list of their open source inventory is a key risk mitigation strategy for organizations, as is knowing which open source components are in different products. Companies need to have a policy for cataloguing the software they are running and managing vulnerabilities in that software.
"It really comes down to first knowing all the applications that they have," Eng says. "Some companies don't even have that. For others, that information is scattered around. There are a lot of different ways for somebody to put up an application that a CISO might not know [is] there."
CISOs are making efforts to move toward a place where they have access to the most up-to-date information so that when something comes out, they can react to it and minimize the risk to the business and the risk to exposure.
"Reliance on open source is only going to get bigger as organizations are asked to innovate more quickly," Eng says. "The speed of innovation is going to make this problem a little harder, and it's probably going to get a little bit worse before it gets better."
Related Content:
About the Author
You May Also Like
Catch the Threat Before it Catches you: Proactive Ransomware Defense
September 5, 2024How to Evaluate Hybrid-Cloud Network Policies and Enhance Security
September 18, 2024DORA and PCI DSS 4.0: Scale Your Mainframe Security Strategy Among Evolving Regulations
September 26, 2024Harnessing the Power of Automation to Boost Enterprise Cybersecurity
October 3, 2024
[Virtual Event] The Essential Guide to Cloud Management
October 17, 2024Black Hat Europe - December 9-12 - Learn More
December 10, 2024SecTor - Canada's IT Security Conference Oct 22-24 - Learn More
October 22, 2024