The open-source maintainer burnout problem

The event-stream attack in 2018 (Section 3) was made possible by one specific condition: the original maintainer had stepped back from the project and was looking to hand off the work. He transferred maintainership to a stranger because he didn't have time to maintain the package.

This scenario is not unusual. It is, in fact, one of the most common conditions in the open-source ecosystem.

The scale of the problem

A 2023 analysis of npm packages found that approximately 34% of packages in the top 50,000 by download count had received no updates in over two years. A separate analysis found that 8% of packages in the top 10,000 had maintainer accounts that had been inactive for over five years.

These packages are not abandoned in the sense that no one uses them — they're downloaded millions of times per week. They're abandoned in the sense that no one is actively watching them. The security implications are direct:

• No one is reviewing dependency updates for new vulnerabilities
• No one is responding to security reports
• The maintainer accounts may have stale credentials (no recent password changes, possibly no 2FA)
• Transfer of maintainership is more likely, and the original maintainer is less likely to vet the new one carefully

Why maintainers step back

Open-source maintenance is unpaid labor for most maintainers. The work involves: fixing bugs, reviewing pull requests, triaging issues, writing documentation, maintaining CI pipelines, handling backward compatibility, and responding to security reports. For popular packages, this can represent tens of hours per week.

The return on this investment is typically: GitHub stars, community appreciation, and the satisfaction of contributing to software that millions of people use. For many maintainers, this is enough for years. Eventually, it often isn't.

Burnout is compounded by the dynamics of open-source entitlement. Popular package maintainers frequently receive demanding issue reports, entitled pull request feedback, and pressure to implement features for large companies that contribute nothing back. The costs increase; the returns don't.

Why this is a supply chain security issue

Stale maintainer accounts are easier to compromise. An account where the maintainer logs in every few years is more likely to have a reused password, no 2FA, and a stale session token. The account itself becomes a target.

Handoff moments are high-risk. When a maintainer transfers a package to a new account, there is usually minimal vetting. The new maintainer may be who they say they are, or they may not. The event-stream attack was exactly this scenario.

Zombie packages accumulate. A package that was actively maintained five years ago may be deeply embedded in the dependency trees of thousands of modern projects. As a direct or transitive dependency, it gets installed millions of times per week — with no active security monitoring by anyone.

What the ecosystem is doing about it

npm has introduced "package archival" — a status that packages can receive if they haven't been updated in an extended period. Archived packages can still be installed but are flagged as potentially unmaintained.

GitHub's dependency security alerts (Dependabot) now flag when a package's primary maintainer account has been inactive for an extended period.

Some package registries are experimenting with "maintainer health scores" that incorporate account activity, response time to security reports, and dependency freshness.

None of these fully solve the problem.

How Veln addresses it

Veln's publisher reputation signals include publisher account age and package portfolio size — but the more relevant signal for abandoned packages is key continuity. When a package changes hands, the signing key changes. When event-stream was transferred to right9ctrl, the new version was signed with a key that had never been associated with event-stream before.

Veln flags key changes:

veln  ⊘ warn    npm:event-stream@4.0.0        signing key changed
                                             previous key: fingerprint abc123
                                             new key: fingerprint def456 (age: 47 days)
                                             new key is < 30 days old: review required

A package where the signing key changes — especially where the new key is young — is a package that deserves a second look before installation. This doesn't prevent all handoff attacks, but it creates a mandatory pause at exactly the moment when a package is most likely to have changed hands for non-security-reviewed reasons.

---

Maintainer burnout creates the conditions for supply chain attacks. Veln's key continuity checks flag the handoff moment.