Every organization's dependency tree contains projects whose continued health depends on the continued availability of one person, and every security team that has done the exercise of mapping that fact has been mildly horrified by the result. The honest framing is that single-maintainer projects are everywhere, that some of them are extremely well-run by people who treat the responsibility seriously, and that some of them are one bad week away from a CVE-2024-3094-class incident. The goal of a risk framework is not to flag every solo project as unacceptable — that would force you to either ban most of npm or live in denial — but to give you a defensible way to prioritize which solo projects deserve attention.
This post is a working framework that we have refined with operators across regulated industries over the past two years. It deliberately avoids the trap of producing a single number, because single numbers tend to be either ignored or over-trusted, and it deliberately includes qualitative signals that automated scanners cannot produce on their own. The framework is structured around four questions a reviewer can ask about any project in their tree, and the answers feed into a prioritization model that an organization can act on with whatever resources it has.
How concentrated is ownership, really?
The classic truck factor metric counts the number of contributors who would have to disappear before a project lost half its institutional knowledge, and it is a useful starting point but a poor stopping point. Real ownership concentration is about three things: who has commit access, who has historically made the consequential decisions, and who has the tribal knowledge that does not show up in commit history. A project with five committers but where one person has authored 90 percent of commits in the last two years is structurally a one-person project, regardless of what GitHub's contributor page suggests. Equally, a project with one committer but with extensive public design discussion, thoroughly documented architecture, and an active community of long-time reviewers has more resilience than the surface metric would imply.
The honest measurement is to look at recent commit history — the last twelve to twenty-four months, depending on the project's cadence — and ask who would actually be able to ship a security fix if the headline maintainer were unavailable for six weeks. Sometimes the answer is "no one, and the maintainer knows it, and they have published a documented succession plan with named alternates." Sometimes the answer is "no one, and the situation is fragile." Those two outcomes look the same in a truck-factor metric and require very different responses, which is why the metric alone is not sufficient.
What does response cadence tell you about the project's actual capacity?
Response cadence on issues and pull requests is one of the most informative public signals about maintainer capacity, but it has to be read carefully. A project that closes every issue within a week may look healthy on a dashboard while actually being a place where the maintainer is reflexively closing without engagement because they are overwhelmed. A project where issues sit open for months may look unhealthy while actually being a place where the maintainer is deliberate about scope and uses issues as a long-running design backlog. The distinction is visible if you read a sample of the maintainer's actual responses: thoughtful engagement is a different shape from triage-driven closing.
The cadence that matters most is the cadence on security reports specifically. Projects that have a documented security disclosure policy, a published advisory history, and a track record of shipping fixes within reasonable windows are demonstrating organizational capacity even when only one person is doing the work. Projects that have no security policy, where the only contact channel is a generic issues page, and where past CVEs took weeks or months to resolve are demonstrating something different. The first category includes many high-functioning single-maintainer projects that are entirely acceptable as dependencies. The second category includes projects that should be flagged regardless of their other metrics.
What does the trust graph around the project look like?
The xz-utils incident made it clear that the social structure around a project is part of its security posture. A project where new committers come from a stable community of known contributors, where commit access is granted gradually and only after demonstrated technical investment, and where the maintainer has a stable identity tied to verifiable affiliations is meaningfully harder to attack than a project where commit access can be obtained through patient politeness alone. None of those properties is a guarantee, and good projects can have inexperienced contributors, anonymous maintainers, and informal access policies. The framework is about reading the totality rather than scoring on any single dimension.
A practical check that takes ten minutes per project is to read the commit history around any recent grant of commit access. How long was the new committer active before being granted access. How many other community members vouched for them, publicly or in mailing-list traffic. What is their identity attestation — a real name on commits, a known affiliation, a long-standing handle with cross-references on other platforms — and how confidently can the project itself answer that question if asked. The xz-utils case is informative because Jia Tan's identity was effectively a fiction that everyone in the loop had accepted, and the patient social engineering that produced that acceptance is something the framework should make visible rather than ignore.
How does the framework actually feed into decisions?
The output of the framework is not a binary judgment but a prioritization. Projects with strong concentration of ownership, slow security cadence, weak trust graphs, and high blast radius in your tree are the ones to invest in first. Investment can take several forms: funding a security audit, sponsoring additional maintainers through a foundation, contributing engineering hours to onboarding new committers, or in the most severe cases, identifying alternatives and beginning a measured migration. The goal is to be doing this work before an incident forces it, because incident-driven migrations are expensive and rushed in ways that planned migrations are not.
The framework also feeds into procurement and architecture decisions upstream of dependency adoption. When evaluating a new commercial product, asking what its critical open-source dependencies look like under this framework can change a buying decision, and asking whether the vendor has any plan to sustain those dependencies should be a standard part of a security questionnaire. Most vendors do not have an answer ready, and the absence of an answer is itself a useful signal about how seriously the vendor takes its own supply chain. The framework gives you a vocabulary for that conversation that is more specific than "we depend on a lot of open source."
What are the failure modes of the framework itself?
The framework can fail in two opposite directions, and both are worth naming. The first is false-positive paralysis: an organization that takes the framework too literally can find itself unable to use any small project, which forces it back toward the largest dependencies for every problem and concentrates risk in a different way. Large projects have their own failure modes — the OpenSSL Heartbleed-era underinvestment is the canonical example — and depending only on them is not actually safer. The second failure mode is theatre: a framework that produces scores but never produces investment is just paperwork, and the discipline is to wire the framework into a budget and a roadmap so that high-risk projects actually get help.
The framework is most useful when it is applied as an ongoing process rather than as a quarterly review. Maintainer status changes, response cadences shift, trust graphs evolve, and the projects in your tree change as your own engineering changes. The organizations that get value out of this work treat it the way they treat vulnerability management — continuous, automated where possible, human-reviewed where needed, and connected to a workflow that turns observations into action.
How Safeguard Helps
Safeguard implements this framework as a continuous scoring layer over the open-source dependencies in your SBOMs, combining commit-history analysis, response-cadence telemetry, trust-graph signals, and blast-radius computation into actionable prioritization. Griffin AI can answer questions like "which of our production-critical dependencies are single-maintainer projects with degrading response cadence" and recommend specific investments — audits, alternates, sponsorships — based on the shape of the risk. Our TPRM scoring extends this analysis to the open-source projects underneath your commercial vendors, so procurement and engineering have a shared view of where the real fragility lives. Policy gates can require a minimum maintainer-health score for new dependencies entering production and trigger structured review when an existing dependency degrades. If you want this framework operationalized across your tree, get in touch.