Most supply-chain security programs focus on code: CVEs, SBOMs, and patching timelines. That is necessary, but incomplete.

Open source risk is not just a function of vulnerabilities. It is a function of whether the project has the capacity to respond to them.

At RSAC 2026, OpenJS Foundation Executive Director Robin Bender Ginn outlined a consistent pattern across ecosystems: when maintainer capacity does not scale with dependency usage, security risk increases.

Many critical dependencies are maintained by small teams, sometimes a single individual. As adoption grows, so does the operational burden – triaging issues, reviewing contributions, managing releases, and responding to vulnerabilities – all increasing with AI. When that burden exceeds capacity, response times degrade. Vulnerabilities persist longer. Releases slow or stop. Risk accumulates.

Traditional indicators such as unresolved CVEs appear late in this process. Earlier signals are visible in project operations: reduced maintainer responsiveness, growing backlogs, or the absence of clear governance and security processes. These are indicators of response capability, not just code quality.

The JavaScript ecosystem provides clear examples of how this risk can be managed. Node.js has reduced operational risk through formal security processes, defined end-of-life policies, and shared governance. Express moved away from a single-maintainer model to a Technical Committee structure, distributing responsibility. jQuery and Lodash have reduced maintenance burden and attack surface by pruning functionality as the JavaScript platform matured.

These outcomes were not driven by code changes alone. They were the result of governance, funding, and deliberate scope management.

For security leaders, this requires a shift in approach. Open source dependencies should be treated as part of the security perimeter, the systems you are responsible for securing, even if you don’t control them. That means identifying which projects are critical, evaluating their operational health, and ensuring there is sufficient upstream capacity to maintain them. In some cases, that requires direct participation. In others, it requires funding the ecosystems and foundations that support them.

Several organizations are already operating this way. Bloomberg and IBM help fund Node.js engineers. Capital One participates in OpenJS security efforts. Netflix supports Express and Node.js maintenance. Platformatic dedicates time for Fastify development. These are direct investments in supply-chain resilience and just some of the ways our members support the foundation.

The underlying dynamic is simple. Security failures in open source rarely begin with bad code. They begin when too few people are responsible for too much critical infrastructure.

Because the biggest supply-chain risk isn’t abandoned code.

It’s unsupported ecosystems.