Why do dormant publisher accounts and old install counts create false trust in extension marketplaces?

Old publication dates and high install counts can look reassuring, but they do not prove current integrity. If an attacker gains control of an established publisher account, they inherit historical credibility, reviews, and subscriber trust. That makes republished malicious updates more likely to bypass casual review, especially when the source repository does not change in parallel.

Why This Matters for Security Teams

Extension marketplaces often reward visible age and popularity, but those signals are weak indicators of present-day trust. A dormant publisher account can still carry reputational weight, while old install counts may reflect a historical user base rather than current code quality. That creates a gap between what reviewers assume and what is actually true about ownership, update hygiene, and supply chain risk. NIST guidance on account security and ongoing access governance, including the NIST SP 800-53 Rev 5 Security and Privacy Controls, is relevant because trust must be continuously revalidated, not inherited from reputation.

The practical risk is that attackers do not need to build trust from scratch if they can compromise an established publisher identity. Once inside, they can republish malicious updates, preserve familiar branding, and exploit review fatigue. Marketplace users, security teams, and procurement functions often focus on download volume and star ratings, even though those signals can lag behind compromise by weeks or months. In practice, many security teams encounter malicious extension activity only after a trusted publisher account has already been reused to distribute a harmful update, rather than through intentional lifecycle monitoring.

How It Works in Practice

False trust emerges when marketplace metadata is treated as proof of integrity rather than as context. An old installation count may indicate legacy adoption, not current maintenance quality. A dormant account may have been abandoned, sold, or simply left without strong authentication controls. Once an attacker acquires control, the account’s historical credibility can reduce scrutiny from marketplace operators and end users alike.

Security teams should evaluate extension marketplaces as a supply chain problem, not a catalog problem. That means checking publisher continuity, update cadence, source repository alignment, signing practices, and authentication strength for the publisher identity. Identity assurance principles from NIST SP 800-63 Digital Identity Guidelines are useful here because the publisher account itself is an identity that needs proofing, authentication, and lifecycle control.

• Review whether publisher accounts have recent administrative activity and enforced MFA.
• Compare package update history against the linked source repository and release pipeline.
• Treat large install counts as a prioritization signal, not a trust signal.
• Look for ownership changes, unusual version jumps, or sudden permission scope changes.
• Require automated checks for signature integrity, dependency drift, and release provenance.

For mature programs, marketplace trust should connect to broader control mapping, including change management, continuous monitoring, and access governance. Controls in NIST SP 800-53 Rev 5 Security and Privacy Controls support the idea that integrity and accountability must be maintained throughout the lifecycle, not only at initial approval. These controls tend to break down when marketplaces lack strong publisher re-verification and when downstream teams rely on popularity metrics because those conditions allow stale trust to mask active compromise.

Common Variations and Edge Cases

Tighter publisher verification often increases operational friction, requiring organisations to balance user convenience against supply chain assurance. That tradeoff is especially visible in ecosystems with many open-source contributors, volunteer maintainers, or rapid release cycles, where heavy-handed review can slow legitimate updates. Best practice is evolving, but there is no universal standard for this yet.

Edge cases matter. Some extensions are intentionally low-maintenance, so a long period of inactivity is not automatically suspicious. In other cases, a high install count may genuinely reflect broad deployment in managed environments. The issue is not age or popularity by itself; it is whether current control evidence supports continued trust. Security teams should also watch for publisher account recovery events, because takeover often follows weak recovery workflows rather than password guessing alone.

Identity governance becomes more important when marketplace identities are shared across teams or delegated to contractors. In those situations, the publisher account may function as a high-value identity, and the absence of lifecycle controls can create NHI-like risk if automation, build tooling, or release bots can publish on behalf of humans. The correct response is to validate current provenance, not to assume historical legitimacy. Where marketplaces do not expose ownership changes or signing history clearly, current guidance suggests treating the package as untrusted until stronger evidence is available.

Related resources from NHI Mgmt Group

• Why do dormant accounts create both cost and security risk?
• Why do stale accounts and old privilege create such a large persistence risk?
• What breaks when organisations rely on install count and ratings for extension trust?
• Why do download counts and popularity scores fail as trust signals for agent marketplaces?