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.
#open source #security #feature
