The Best Way to Secure Your Open Source Supply Chain is to Participate

Open source software powers 96% of modern applications, but it comes with challenges. Companies can secure their supply chains by actively participating in the open source projects they rely on.

Ben Cotton

December 5, 2024

Open source software powers 96% of modern applications, but it comes with challenges like complex dependencies and inconsistent security practices. Companies can secure their supply chains by actively participating in the open source projects they rely on. Contributions can take many forms:

👩‍💻 Code contributions: Fix bugs, add features, and shape the project’s future.
💰 Funding: Support maintainers financially or through in-kind contributions.
🤝 Non-code efforts: Documentation, testing, and community management keep projects sustainable.
🌟 Visibility: Simply showing appreciation can motivate maintainers and keep projects alive.

Participation isn’t just about security; it’s about building a stronger, sustainable open source ecosystem.

‍

Open source software is a foundation of the modern economy. Modern applications contain 96% open source code. Harvard researchers estimate that companies would need to spend 3.5x more on software development if open source didn’t exist. But this benefit comes with a cost, too: dependency graphs become more complex and the software typically comes without warranty. The quality of the software and the speed of fixing vulnerabilities can vary widely from project to project.

‍

Companies who want to secure their software supply chain need to pay a lot of attention to the open source software they consume. They want those projects to be more secure, but many developers resent what they see as an unfunded mandate from large, profitable corporations. “I am not a supplier” is a sentiment in some circles.

‍

It’s true that open source projects are not suppliers in the way that a traditional supply chain participant, like an auto parts manufacturer, is. But companies aren’t helplessly stuck to deal with whatever open source projects decide to deliver. You have agency because your company can participate in the projects you depend on. There are many ways to do this.

‍

Contribute code

The most obvious way for a company to participate is for software engineers to contribute code. This includes fixing bugs as well as implementing desired features. It will cost time to have developers work around the deficiencies in the upstream project, so they might as well use that time improving the project instead. If more than one application in your portfolio uses that upstream project, you save effort (and therefore money) by fixing the issue upstream.

‍

Participating in the project does more than address your immediate concerns. It can also give you a voice in the future direction of the project.

‍

Give money

Open source maintainers who get paid to maintain software are more likely to implement improved security practices. What better way to combat the “unfunded mandate” argument than to turn it into a funded mandate? Not all projects can — or want to — accept money directly, but you might be able to provide in-kind contributions like a free product or a conference ticket. You can also contribute to foundations that provide broader support to ecosystems, languages, or frameworks.

‍

Contribute other effort

Open source projects need more than code. Some of this work can directly impact security, like testing and fuzzing. But thinking about your supply chain only in terms of vulnerabilities is myopic. You want the projects you depend on to fix bugs and develop new features that you’ll need in the future. To do that, the project needs to be sustainable. Contributing documentation, marketing support, community management, and other skills can help keep the project going in the long term.

‍

Show signs of life

One area of participation that’s often undervalued is the mere act of being seen in the project’s community. An open source project typically doesn’t have a good way to know who uses it, or even how many users there are. Developers can feel like they’re contributing code into the void. This can be demotivating over time, and might result in shifts in project priority — including abandoning the project altogether. Abandoned projects are a major supply chain security risk.

Like what you read? Share it with others.