Addressing third-party risk in open source software
Once you've discovered the third-party risks in the open source projects you consume, how do you address those risks without having a vendor relationship with the projects?
Parth Patel
Ben Cotton
February 27, 2025
Your business depends on third parties — your suppliers, utility companies, possibly delivery services, and so on. Your business’s software depends on third parties, too. Even if you have an in-house development team, they’re probably using software-as-a-service and infrastructure-as-a-service platforms, open source and vendor supplied libraries, operating systems, and so on. If you’re not already managing your third-party risks, CSO Online says this is the year to start.
In our previous post, we covered how you can analyze open source software as part of your third-party risk activities, even when you don't have a vendor relationship with the projects. This post covers how you can address the risks you find.
Addressing risks
With proprietary software, you would address many risks in contract language. For example, you could require the vendor to follow a set of security controls or have a certification like SOC2. You can insulate yourself from the risk of a vendor going out of business by requiring code to be placed in escrow. Requiring no vulnerabilities ever is unreasonable, but you can include language that requires a specific level of response, with penalties for missing the requirements or compensating for damage incurred. Even though open source software doesn’t come with a contract, you still have options for mitigating risks.
The most impactful way to manage the third-party risk of open source software is to participate in the projects. You can’t just show up with a list of demands, but you can work with the community to improve secure development practices, fix vulnerabilities, add the new features you need, and so on. It’s critically important that you don’t solely focus on your organization’s immediate needs. Give your developers time to work on the “chopping wood and carrying water” kinds of maintenance tasks that keep a community healthy. This will, in turn, help keep the project more sustainable.
If you’re worried about code disappearing, or want to avoid rapid churn, you can choose to “fork” the software and use an internal copy. The tradeoff here is that you become fully responsible for keeping it up to date. If the project releases a new version with features or fixes that are important to you, you need to update your fork. Depending on how closely you’re tracking the upstream, this could end up being a significant amount of work.
One advantage of open source software compared to its proprietary counterpart is the ability for consumers to verify secure development practices. Because development happens in the open, you can see if the project requires code review, runs automated test suites, and other activities. You can also see how sustainable the project’s governance structure is. Tools like OpenSSF Scorecard and the Best Practices Badge give you a way to quickly evaluate the security and sustainability practices of the projects you depend on.
Of course, you can and should check for existing vulnerabilities before selecting a new open source dependency. You can also run code quality tools to get an idea of how likely future vulnerabilities may be.
Similarly, license scanning tools will examine a project to make sure it correctly reports the licenses of its own dependencies. Once you know what licenses exist, you can check that they meet your business requirements. When choosing between multiple projects that provide the functionality that you need, prefer ones that use a widely-used open source license. There are hundreds of licenses available, but the common ones are better-understood by the legal and development communities.
Tie it all together
Third-party risk management is not a one-time activity. Code changes, communities evolve, and business & technical requirements shift over time. Successfully managing risk means continuously tracking risks across the dependencies in your entire portfolio for a holistic view. You should start with a full review of a potential dependency before you bring it into your application to evaluate the risk against your organizational requirements. Once you have accepted the new dependency, the Kusari Platform helps put key information about your dependency graph at your fingertips.
Additional resources:
- NIST SP 800-161 Rev. 1 (Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations)
- NIST SP 800-53 Rev. 5 (Security and Privacy Controls for Information Systems and Organizations)
- OpenSSF Scorecard
- Best Practices Badge
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
Previous
No older posts
Next
No newer posts
Want to learn more?