How an OSPO Can Help Secure Your Software Supply Chain
It’s nearly impossible these days to build software without using open source code. But all that free software carries additional security risks.
Organizations grapple with how best to secure their open source software supply chain. But there’s another problem: Many companies don’t even know how many open source applications they have — or what’s in them.
The worst-case scenarios include debacles like 2021’s Log4j security vulnerability, or what happened with SolarWinds’ proprietary Orion network monitoring product, which was infected with malware in 2020.
For companies that build and ship software, the best practice is to “ship what you know and know what you ship,” according to Suzanne Ambiel, director of open source marketing and strategy at VMware Tanzu. And that “shipping manifest” applies to open source and proprietary code equally.
“Your customer and user community is trusting that what you are providing to them is good and clean and secure,” she said. “They trust you to have done the hard work, and that you know what’s in your software.”
In order to get a handle on the potential risks involved with using open source, companies need to have a clear understanding of what open source code is used in their environment, stay up to date on patching, and even conduct their own vulnerability scans and assessments if necessary.
An open source program office (OSPO) — a bureau of open source experts within your organization dedicated to overseeing how your company uses, creates and contributes to free software — can help coordinate all these efforts.
An OSPO can help a company get a handle on the open source code it uses and establish visibility into open source projects and tools, said Liz Miller, vice president and principal analyst at Constellation Research.
“Fundamentally, the purpose of an open source program office is to centralize the understanding of dependencies, implementation and utilization of open source code across an enterprise,” Miller said. “There is a significant security benefit to an OSPO.”
What’s In Your Open Source Code?
Today’s software is made up of components from a variety of sources. “It’s never 100% one thing,” said VMware’s Ambiel.
“There’s some code that you have written for the first time, so you obviously know what’s in there. But you may have used some containerized software. And you are going to be reusing some code. And everyone uses open source code.”
Recent studies differ on exactly how much open source code enterprises use, but it’s a lot:
- A survey by The Linux Foundation, the TODO Group and The New Stack, published in September, found that 81% of respondents use open source software in their non-commercial or internal products at least sometimes, and 67% use it in their commercial or external products.
- Last April, application security testing company Synopsys reviewed the code of more than 1,500 enterprise software projects, both internal and commercial, and found that 98% of them contained some open source code. For an average application, 75% of the codebase was open source.
Here’s the scary part: In Synopsys’ analysis, 84% of the codebases had at least one vulnerability. And 91% of the open source components used hadn’t seen any maintenance of the past two years.
Even open source code that has been in circulation for years and has been seen and used by millions can include vulnerabilities lurking layers deep in the code, said Miller.
“The reality of open source is that for the security professional, hearing that a software supply chain is filled with unchecked, unknown and completely invisible open source code is the stuff nightmares are made of,” she said.
That’s why software needs to come with a “bill of materials,” said Ambiel, a complete inventory of all the components that go into a software package, and their versions and license terms.
And there’s a lot happening on that front. An OSPO can help companies stay on top of the latest recommendations, she said.
For example, last May President Biden issued an executive order requiring a software bill of materials (commonly known as an SBOM) from vendors that provide software to the federal government.
Two days later, the Cloud Native Computing Foundation (CNCF) released a best-practices white paper recommending that all vendors provide an SBOM where possible, with clear and direct links to dependencies.
The CNCF white paper also recommended that companies scan their software with software-composition analysis tools to detect vulnerable open source components, and use penetration testing to check for basic security errors or loopholes and resistance to standard attacks.
Companies need to have a clear understanding of what open source code is used in their environment, stay up to date on patching, and even conduct their own vulnerability scans and assessments if necessary. An OSPO can help coordinate those efforts.
And more recently, the Linux Foundation published a report that provides additional insights and recommendations for best practice management of your software supply chain.
With an in-house OSPO in place, the professionals in that office can help educate developers on the best practices for creating SBOMs and also help establish Software Data Package Exchange (SDPX) standards, which is how SBOM information is communicated.
It can also help devs keep abreast of emerging concepts like the new framework for software supply chain integrity, called Supply-Chain Levels for Software Artifacts, or SLSA, introduced by Google in collaboration with OpenSSF in 2021.
Keeping up to date with these best practices is a challenge, said Ambiel. “Being a developer is hard enough, and asking them to take on that challenge pulls them away from the applications or products they’re trying to build.”
An OSPO “can bring in the best practices and apply them in the best way possible, given the company you are and the software development that you do,” Ambiel said.
Protecting Open Source Software from Attack
Attacks on the open source software supply chain increased 650% last year compared to 2020, according to Sonatype‘s state of the software supply chain report, released in September.
And that’s before the Log4J vulnerability came to light, called the most dangerous Java exploit in years by security researchers.
An OSPO can help developers stay abreast of new developments in open source security and build more secure applications, while also staying on top of required updates and patches.
Software is constantly changing, and it’s a constant challenge for companies to keep up with those changes. An OSPO can also help create and maintain connections to open source communities that keep track of the latest changes in software, and these connections can help companies stay on top.
“What’s current today is technical debt tomorrow,” said Ambiel. “It’s a big job. But when it comes to these big ecosystem challenges, that’s where the open source community really shines and can step up.”
Keeping on top of code changes is a problem that everyone has, she said: “No one is excluded. Everybody has to pay attention to this.”
When companies open themselves up to new ideas from beyond their corporate borders, that’s when the best solutions come to bear, she added.
For example, the open source community has been working on supply chain security and compliance for years. The Linux Foundation’s Tern project, which inspects container images, is part of its Automated Compliance Tooling initiative.
“What’s current today is technical debt tomorrow. It’s a big job. But when it comes to these big ecosystem challenges, that’s where the open source community really shines and can step up.”
—Suzanne Ambiel, director of open source marketing and strategy, VMware Tanzu
An OSPO can also tap outside expertise through the OpenSSF, which is working on system solutions and ways to combat increasing attacks like typosquatting and malicious code.
All of this is important because attackers are getting proactive, said David Wheeler, director of open source supply chain security at the Linux Foundation.
They directly inject malware into software source code or installable packages — sometimes, just submitting an update with malware in it and hoping nobody notices, or by stealing a developer’s password.
“Malicious code injection is the kind of attack that most people think about, yet in practice, it’s less common in open source software,” said Wheeler. “Still, it can be devastating when it happens.”
The most common way to replace legitimate code with malicious code is by creating a duplicate package on a different repository. A developer might think they’re loading a trusted package from their in-house repository but load a package with the same name from a different, public repository because it has a later release date.
“Typosquatting is another common attack,” said Wheeler. This is when the malicious package has almost the same name as the real one. “The developer uses the malicious package instead — often because the developer makes a typo.”
OSPOs and Open Source Communities
To guard against these kinds of attacks, Wheeler recommends that companies engage more with open source communities.
Having an OSPO helps companies do just that. Fifty-six percent of participants in the Linux Foundation survey felt that engaging with the developer community was a chief responsibility of an OSPO, and almost 69% said promoting an open source culture in-house was a chief responsibility of an OSPO.
If an open source project is important to a company but the project doesn’t have multiple people reviewing code upgrades, then it might make sense to join the project.
“The costs of doing so are typically far less than trying to independently develop and maintain your own software,” Wheeler said.
He also suggested that companies get involved in the OpenSSF, a consortium of many organizations working on systemic solutions, such as distributing multifactor authentication tokens to software developers.
“Different organizations may choose to resolve these challenges differently,” Wheeler said. “But OSPOs are often well-placed to help.”