Open Source / Security

What ‘Security’ Means for Open Source Software

23 Jun 2020 9:24am, by

This story is the latest in a series that we will post that examine the role of the security in the open source software supply chain. Check back throughout the month for updates.

It’s unlikely that any modern enterprise has a tech stack completely free of open source software. Open source is a big part of what helps companies innovate quickly, and use software to create a competitive advantage. But it does come with some unique security challenges when compared to either custom applications or software that comes from a vendor.

The widespread use of open source software, combined with the complicated nature of most software supply chains, raises the stakes for open source security and for the many companies that rely on open source. “Suddenly security mistakes in open source components have huge ramifications,” said Guy Podjarny, founder of security company Snyk.

How does open source security differ from closed-source enterprise software or custom applications? We talked with a couple security experts to understand the unique security challenges that open source presents as well as how organizations can mitigate those risks.

Who Is on the Hook?

The most basic challenge with open source software is that there’s no one with a clear responsibility to help enterprises with security issues, and the process of getting it fixed is different. “If you find a security issue or a security issue is found, you’re not going to a vendor and asking them to fix it, you’re submitting a pull request in an open source repository or you’re expecting one of the maintainers to be looking at the security of the repos and reporting and resolving security issues,” said Hillary Benson, chief product officer at container security company StackRox. That is a very different responsibility model, and means that enterprises need to take more responsibility for managing software security internally than when vendors supply and maintain software for them.

“The maintainers are doing this for free,” explained Podjarny. “They don’t really owe you anything, but it does create that ownership challenge.”

This is all complicated by both scale and complexity of the open source footprint in most enterprises. Software is increasingly assembled rather than built from scratch, and any open source project is likely to include many other open source components. “There are tens of thousands of open source components being used across a typical enterprise,” Podjarny explained. “All of them need tracking for vulnerabilities.”

Organizations might not even be aware of which open source components exist in the complex network of dependencies. “You really need to have tooling that says, okay, I included this library, and then looks at the library and says, ‘What libraries does that library include?’” Benson said.

The reality is that there’s often no one explicitly tracking vulnerabilities for many open source projects. There’s huge variation in open source projects, ranging from a simple project that does one very specific thing and has two maintainers who both have unrelated day jobs to projects like Linux or Kubernetes with robust communities and support. Given the extent of open source software usage, most enterprises have software components along the entire spectrum, from super small to massive user communities.

When a vendor’s software has a vulnerability, it’s always reported to the databases of Common Vulnerabilities and Exposures (CVEs). “The majority of the time, when you have problems with open source software, they don’t ever end up getting a CVE,” Benson explained. As a result, those vulnerabilities are invisible to tools that scan for known problems based on CVE databases.

Of course, there are some examples of companies taking “ownership” of open source security — perhaps the most notable examples are Canonical and Red Hat, both of which take some ownership by providing security and patching support for open source components.

High Payoffs for Hackers

If you’re a hacker, attacking open source software is also very attractive. “If I’m an attacker and I know that tens of thousands of organizations use, for example, MySQL, then writing an exploit that will attempt to break into MySQL based on a known vulnerability is much more likely to succeed statistically, because it’s being used everywhere,” explained Rani Osnat, vice president of strategy and product marketing at cloud native security company Aqua.

It also helps that these vulnerabilities are often public knowledge — even if they aren’t in the CVE databases, they are likely reported as bugs in GitHub. “Very few bad guys go through the effort of actually finding holes in software,” Osnat said. Open source is easier to examine and play around with, too, so the level of sophistication required to exploit it is lower.

Open source is also … open. Because anyone can contribute, attackers can poison the software supply chain by intentionally inserting vulnerabilities into the code, with the intention of exploiting those vulnerabilities in the future. That’s a threat vector that, while not totally nonexistent in a closed-source software project, is substantially less likely to be a problem with either custom code developed internally or closed-source software from a vendor.

Success with Open Source Security

Does this mean that open source software is inherently less secure than bespoke software or closed-source software? Absolutely not.

“Well run open source projects deliver better quality software than what you get elsewhere,” Osnat said. “Good quality software has fewer bugs, fewer bugs means fewer vulnerabilities.”

The main benefit of open source projects, when it comes to security is that so many people are usually looking at and scrutinizing it, Osnat added.

Nonetheless, enterprises that use open source software have to take on a substantial amount of responsibility for security. This has to include tooling that should go beyond scanning for known CVEs. “It’s about knowing what you’re using, and then knowing which vulnerabilities exist in them,” Podjarny said. The complexity of nested dependencies also means that tooling is absolutely essential.

“It’s not something that you would do manually,” Benson said. “I’m not convinced that that would be possible.”

Open source certainly presents unique security challenges, but security pros clearly consider those challenges both manageable and worth it when compared to the advantages open source provides.

“Open source provides a huge amount of value to organizations and is a core driver for the pace of innovation we see today,” Podjarny said. “We just have to take ownership of it to not let it get out of hand.”

Snyk is a sponsor of The New Stack.

Feature Image by Mabel Amber from Pixabay.

At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email:

A newsletter digest of the week’s most important stories & analyses.