You inherit a dependency graph you never chose. Somewhere inside it is a package maintained by one unpaid person, and your release schedule depends on how their year is going.
The mistake is the zero-cost fallacy: free code stays free and maintained forever. In open source, ‘free’ means free to use; it says nothing about who carries the risk.
This is one corner of the broader open source funding crisis: infrastructure held up by unpaid maintainers whose labour is priced at zero. Assess it on two axes: funding risk (is anyone paying for the labour?) and governance risk (who decides when a key person leaves?). Get both right and you turn an invisible open source supply chain risk into a board-legible decision: fund, fork, vendor, or replace.
How should you assess the funding and governance risk of a critical dependency?
Map your dependency footprint through an SBOM and dependency graph. Then score each critical dependency on maintainer concentration, funding model, governance, and continuity signals. Cross-check against the OpenSSF Criticality Score and Scorecard, then make the call: fund, fork, vendor, or replace.
You cannot assess what you have not mapped. Generate a machine-readable SBOM and the transitive dependency graph before an incident occurs. Regulators already demand it: the EU Cyber Resilience Act, the CISA and DHS Cyber Safety Review Board, the FDA, and the SEC all circle the same artefact.
Maintainer concentration is the primary signal. The bus factor is how many people could cut an emergency release tomorrow. Census III found 40% of projects had one or two developers writing more than 80% of commits.
Separate genuine maintenance from the appearance of it. Read the last twenty closed issues to see whether they were closed with an answer or by a stale bot. Release cadence that halves and halves again is an early warning of fatigue. Ask who merges and cuts releases, rather than counting committers.
Treat the scorers as inputs, and weigh them against maintainer and funding signals. The OpenSSF Criticality Score ranks how critical a project is, while the OpenSSF Scorecard ranks how healthy it looks. Both can be gamed (Goodhart’s Law: a measure that becomes a target stops being a good measure) and both measure what is easy to measure rather than what predicts failure (the Streetlight Effect). That is the free-code equilibrium: cheap metrics rarely predict failure.
Decide fork-versus-fund deliberately, because forking moves continuity risk onto your own team and compounds your own bus factor. It is only right when continuity is unrecoverable. The xz backdoor as a burnout case study is what happens when one exhausted maintainer has no second reviewer.
Write the result into a Critical Software Risk Register with a named owner and a review date.
How do you evaluate a foundation as a governance home for a critical project?
Evaluate a foundation on four axes: neutrality, IP control, funding durability, and who holds the seat. Foundation stewardship like the Linux Foundation or OpenSSF distributes commit rights so the project survives individual departures. Corporate patronage keeps a vendor in the seat, preserving alignment but reducing neutrality. A foundation can de-risk governance without solving funding.
A foundation’s job is continuity. It moves control off one person or one vendor, which raises the effective bus factor. Foundations are companies paying to steer, not companies paying the people who row.
Neutrality asks whether competitors can safely rely on the project, or whether one vendor owns the roadmap and trademark. Who holds the seat asks whether the board is elected or vendor-appointed. A vendor-neutral foundation owns the trademark and the legal entity. The C4 framework‘s Community and Conduct categories are the lens here: how many maintainers, and who is required to review a merge.
The catch is the residual. A foundation improves continuity, but the funding gap, who pays the maintainers, remains unsolved. This is one of the funding models under comparison, and it handles governance while leaving payroll open.
Supply chain vendors vs direct maintainer funding: who should the money go to?
Supply chain vendors monetise the risk surface by selling supply chain auditing, scanning, SBOMs, and SLAs. That buys assurance at scale, but the money stays outside the project. Direct maintainer funding through GitHub Sponsors and patronage budgeting reaches the people who cut releases. Vendors scale process across many dependencies; direct funding scales resilience in the few your product cannot run without. Use vendors for the long tail and fund those maintainers.
Vendors like Snyk, Black Duck, and Sonatype sell process, audit, and support across hundreds of dependencies. That is assurance, and paid support resolves vulnerabilities up to 45% faster. But almost none of that money reaches the maintainer, so it buys certainty but leaves the continuity problem untouched.
The problem is reach. GitHub Sponsors has moved more than $100 million to over 70,000 maintainers, but that money cannot cover a whole dependency tree.
So split the budget by reach. Fund maintainers of the critical few directly and on a recurring basis, and use vendor tooling for the long tail. You can see the whole set of options in the funding models compared.
Conclusion
Assessment is only valuable if it ends in a decision. The four honest responses to a bad-scoring dependency are fund, fork, vendor, or replace; the dishonest fifth is deciding nothing, which turns a manageable decision into an emergency two years later.
So name an owner and set a date. An abandoned dependency handled deliberately is a managed risk; the same dependency handled by silence becomes a postmortem. That is turning awareness into a plan: moving from a scan to an owned, dated action on the dependencies that matter.
Frequently Asked Questions
Do I need to worry about my open source dependencies as a new CTO?
Yes, any CTO inheriting a product also inherits a dependency graph they never chose, and the zero-cost fallacy means it is usually under-budgeted. You do not need to panic about every package. You need to map the footprint, identify the few dependencies your product cannot run without, and assess who funds and governs each one. Worry proportionately, then act deliberately.
Where can CTOs find authoritative data on which open source projects are at risk?
The OpenSSF Criticality Score ranks how critical a project is, while the OpenSSF Scorecard ranks how healthy it looks. Your own SBOM and dependency graph tell you which projects matter to you. Treat all three as inputs rather than verdicts, because both scorers are vulnerable to Goodhart’s Law and the Streetlight Effect. Combine them with maintainer and funding signals before you rank anything.
What signals tell me whether a project is genuinely maintained or just looks active?
Look past commit cadence and check depth of work. A genuinely maintained project has recent releases, timely security responses, reviewed pull requests, and a shrinking or triaged issue backlog. Apparent activity shows lots of commits but little review, stale releases, and issues that pile up unanswered. The sharper question is who actually merges and cuts releases, not who merely commits.
What is a bus factor, and what number should worry me?
Bus factor is the number of people who would have to disappear before a project stalls, and specifically how many could cut an emergency release tomorrow. Any project resting on one person is a concentration risk, regardless of how healthy the code looks. There is no safe universal number, but if the answer is one or two and you rely on the project critically, treat that as an active risk to mitigate.
Is it safe to depend on a single-maintainer project?
It can be safe, but only if you have priced the concentration risk. A single-maintainer project means one illness, burnout, or dispute can stall the security fixes you depend on, as the xz backdoor case showed. Mitigate by funding that maintainer directly, monitoring release and response latency, and holding a contingency plan. If continuity is irrecoverable and the dependency is critical, replace or fork it deliberately.
How do I know if a dependency is about to be abandoned?
Watch the continuity signals rather than an announcement, because most projects fade without one. Warning signs include lengthening gaps between releases, slow or absent security responses, unanswered issues, maintainers stepping back publicly, and no documented succession plan or second maintainer. When several appear together on a critical dependency, treat it as funding or governance risk and start your fund, fork, vendor, or replace decision.
How do I decide whether to fork an at-risk dependency or fund it?
Fund first, fork last. Funding a maintainer, directly or through patronage, keeps the project alive and raises its effective bus factor. Forking transfers all continuity risk onto your own team and compounds your own bus factor, so it is only justified when continuity is genuinely irrecoverable. If you do fork, budget for the ongoing maintenance you now own, not a one-off copy.
How should I structure an open source contribution and patronage budget?
Split the budget by reach. Fund maintainers of the few dependencies that are critical to your product, directly and on a recurring basis, so the money reaches people who cut releases. Use vendor tooling and supply chain auditing for the long tail, where you cannot fund everyone but still need assurance at scale. Name an owner and a date for each commitment so it survives the next reorganisation.
Does buying commercial support or a supply chain vendor contract reduce my dependency risk?
It reduces your exposure, not the project’s risk. A vendor contract buys scanning, auditing, SLAs, and someone to call during an incident, which is real assurance at scale across many dependencies. But that money usually stays with the vendor and never reaches the upstream maintainers doing the work. Use vendors for the long tail and fund maintainers directly for the critical few.
What is an SBOM, and do I actually need one?
A software bill of materials is a machine-readable inventory of every component in your software, including transitive dependencies several levels down. You need one because you cannot assess what you have not mapped, and because regulators are turning it from preference into obligation through the EU Cyber Resilience Act, the CISA and DHS Cyber Safety Review Board, the FDA, and the SEC.
What is the difference between a dependency being critical and being healthy?
Criticality means how much you would be hurt if the project stalled, while health means how likely that is to happen. A project can be highly critical and poorly funded, or lightly used and thriving. The OpenSSF Criticality Score speaks to the first, the OpenSSF Scorecard to the second. Assess both, because a fund, fork, vendor, or replace decision depends on where the two meet.
How often should I reassess a critical dependency?
Reassess on a schedule, not only when something breaks. An annual review is a reasonable baseline, but trigger an out-of-cycle check when a key maintainer steps back, a funding source dries up, a release goes stale, or the dependency moves into a foundation. Assessment only matters if it ends in an owned, dated decision, so keep the register current rather than archived.
