For each open source component in production, you have three support options: buy support from a vendor or service provider, manage it yourself with the help of the community, or accept the risk of having none. The OSPO book says to decide deliberately, since production use has hidden costs.
The three options
The OSPO book's day-to-day operations chapter lists "clarify how to support open source" as a consumer-stage activity. Its purpose is to make sure open source is adopted with an understanding of how it can be supported, and that the organization knows the hidden costs of production use.
It describes the options as follows. External support can sometimes be bought from a vendor or service provider. Alternatively, you can manage support yourself with the help of the community, being realistic about what a community can be expected to support. Or you can go with the risk of not having support, which the book says may be appropriate where the risk is low.
| Option | Good fit | Watch out for |
|---|---|---|
| Buy support | Critical components, regulated settings, small in-house expertise | Scope and response times in the contract |
| Self-support with the community | Components with an active community and in-house skill | Expecting more from volunteers than they can give |
| Accept the risk | Low-risk, replaceable, internal components | Forgetting the decision and never revisiting it |
How to decide per component
Use a short set of questions at intake.
- How critical is it? What breaks if it fails, or if a vulnerability appears and nobody fixes it?
- How replaceable is it? Could you swap it out in a sprint, or would it take months?
- How active is the community? The OpenSSF guide for evaluating open source software suggests checking recent releases, more than one maintainer, and how quickly security issues are fixed.
- Do we have in-house skill? If nobody could patch it, self-support is not real.
- What does the contract say? If you buy support, read what it covers. See what to ask a vendor about support before you sign for a question list.
Record the decision
Write the choice in your inventory next to the component: the option, the reason, the owner and a review date. A decision with no review date turns into a silent assumption. Revisit when the component becomes more critical, when maintainers leave, or when the project reaches end of life.
When support is not enough
Support does not remove the need for monitoring. Even bought support depends on you knowing the component is deployed. Keep the inventory current so you can tell your support provider, or your own team, what you actually run.
The book also notes that sometimes money is not the best fix and that closer partnership or development support may help a project more. If a critical component relies on a single volunteer, consider contributing time as well as paying for support.
Try it yourself
Click through it at your own pace, or open it full screen. Consider who would own each finding if no one supported the component.
How Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis and autonomous remediation with fix PRs, which is off by default with every category on Manual. These help you see what you run and what needs attention. Try gold.safeguard.sh/scan.
Quick check
Is accepting the risk ever reasonable?
Yes, for low-risk, replaceable components, according to the OSPO book. Record the decision and revisit it.
Does paid support mean the component is secure?
No. Support covers what the contract says. You still need an inventory and monitoring.
Sources
- OSPO Book, Chapter 4: Day-to-Day Operations
- OpenSSF: Concise Guide for Evaluating Open Source Software
Last reviewed: 19 October 2026.
