Why do dormant maintainer accounts increase supply-chain risk?

Dormant maintainer accounts increase risk because they often have release authority without current monitoring, so attackers only need to regain access once. That creates a long-lived trust gap between account ownership and operational oversight. In practice, dormant accounts let attackers republish legitimate packages, inherit dependency trust, and reach developer systems through normal workflows.

Why This Matters for Security Teams

Dormant maintainer accounts are dangerous because package ecosystems still trust them as if they were active, reviewed, and accountable. Once an account has release rights, signed-update privileges, or ownership over a widely used dependency, that trust can persist long after the person has left, changed teams, or stopped logging in. The result is a long-lived gap between identity status and operational oversight.

Security teams often focus on the package itself and miss the maintainer identity behind it. That is the wrong control point. Supply-chain attackers prefer accounts that already look legitimate, because they can publish malicious updates through normal workflows and blend into routine release activity. NHIMG’s The 52 NHI Breaches Report shows how often trust in non-human identities becomes the entry point for broader compromise, and the same trust pattern applies when human maintainer accounts go stale.

This is not just an account hygiene issue. It is a governance problem that intersects with dependency integrity, code-signing, access review, and incident response. Guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward continuous access validation rather than assuming old access is still safe. In practice, many security teams discover dormant maintainer abuse only after a malicious release has already been trusted downstream.

How It Works in Practice

A dormant maintainer account increases risk because it preserves authority without preserving oversight. In package ecosystems, that authority can include releasing new versions, approving dependency changes, managing ownership transfers, or approving workflow automation. If the account is not actively monitored, an attacker only needs to regain access once, then publish a malicious update that appears routine to consumers.

The practical failure is usually not one control, but several small gaps:

• Accounts remain active after a maintainer leaves a project or stops contributing.
• Release permissions are not revalidated against current project ownership.
• Multi-factor authentication exists, but recovery paths are weak or unreviewed.
• Package consumers trust version numbers and repository reputation more than maintainer activity.
• Automated build and publish workflows inherit privileges that were never re-scoped.

Strong programs treat maintainer access like any other privileged identity: periodic review, enforced step-up authentication, recovery governance, and rapid revocation when activity stops. That should be paired with tamper-resistant release controls, dependency provenance, and alerts when dormant accounts regain session activity or publish rights. The LiteLLM PyPI package breach and the Reviewdog GitHub Action supply chain attack illustrate how trusted delivery paths can be abused when repository identity and release authority are not tightly controlled.

For teams operating at scale, this should be mapped into the same governance stack used for secrets and workload identities, including continuous entitlement review and separation between code contribution and release approval. This guidance tends to break down in large open-source ecosystems where volunteer turnover is high and package ownership transfer is slow, because stale authority can linger longer than any one maintainer’s actual involvement.

Common Variations and Edge Cases

Tighter maintainer controls often increase operational overhead, requiring organisations to balance release velocity against the risk of breaking legitimate contributor workflows. That tradeoff is real, especially in open source, distributed teams, and emergency patch processes where immediate publishing matters.

Best practice is evolving, but current guidance suggests treating dormant accounts differently depending on the ecosystem. For critical packages, inactivity thresholds should trigger stronger review, temporary suspension, or ownership reassignment. For community projects, governance should distinguish between inactive maintainers, archived repositories, and emergency responders with time-bound authority. There is no universal standard for this yet, so policies need to reflect the project’s release cadence and blast radius.

Two edge cases matter most. First, an apparently dormant account may still be a recovery path for a legitimate maintainer, so removal without process can create availability risk. Second, automated publishing identities can look “dormant” to humans while still being required for CI/CD. That is why current practice should separate human maintainer accounts from machine release identities and review each on its own terms, using policy and event logging rather than assumptions. The Mastra npm Supply Chain Attack and the Miasma and Hades Supply Chain Worms show how quickly trusted package paths can be weaponised once release authority is compromised.

Related resources from NHI Mgmt Group

• Why do shared data directories increase supply chain risk in ML pipelines?
• Why do signed releases not eliminate supply-chain risk after maintainer compromise?
• Why do CI runners and developer workstations increase supply-chain identity risk?
• Why do build servers and CI runners increase supply chain risk?