What breaks when organisations rely on install count and ratings for extension trust?

Why This Matters for Security Teams

Install count and star ratings are convenient signals, but they are not trust signals. For browser and IDE extensions, reputation can be accumulated over time, purchased, or manipulated, which means a package can look legitimate long before its behaviour changes. That matters because extensions often run with broad access to code, credentials, and session data, making them a high-value software supply chain target. NHI Management Group’s Ultimate Guide to NHIs shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage.

Security teams often overfit procurement and allowlisting to popularity metrics because they are easy to explain, easy to automate, and easy to defend in a review. The problem is that install count says little about code quality, update integrity, permission scope, or whether an extension has quietly shifted from useful utility to a collection point for secrets. Current guidance from the NIST Cybersecurity Framework 2.0 points toward risk-based assessment rather than reputation by proxy. In practice, many security teams encounter malicious extension behaviour only after token theft, session hijacking, or data exfiltration has already occurred, rather than through intentional trust review.

How It Works in Practice

Trust decisions should move from popularity to evidence. For extensions, that means evaluating publisher identity, permissions, update cadence, supply chain integrity, data handling, and whether the extension can access secrets, source code, or authenticated browser sessions. Reputation can remain a screening signal, but it should not be the approval criterion.

A practical review process usually combines several checks:

• Verify publisher legitimacy and ownership continuity across releases.
• Compare requested permissions against the minimum required function.
• Inspect whether the extension touches credentials, tokens, or development tools.
• Review update history for abrupt feature expansion or unusual release patterns.
• Prefer signed, centrally approved extensions over ad hoc self-service installs.

This is especially important in environments where extensions can read page content, intercept clipboard data, or access local files. The issue is not only initial installation. A trusted extension can later receive an update that changes its behaviour without a corresponding change in ratings or install count. That is why popularity metrics should be treated as lagging indicators, not control evidence. The NIST CSF emphasis on continuous risk management aligns with the broader NHI reality described in Ultimate Guide to NHIs: if an extension can interact with secrets, it needs lifecycle oversight, not just marketplace reputation. These controls tend to break down when extension stores are unmanaged across endpoints because security teams lose visibility into who installed what, where it runs, and what changed after approval.

Common Variations and Edge Cases

Tighter extension control often increases friction for developers and power users, requiring organisations to balance usability against reduced exposure. That tradeoff is real, especially when teams depend on productivity tools that are updated frequently or sourced from multiple marketplaces.

Best practice is evolving for edge cases such as open-source extensions with strong community adoption but limited formal ownership, or enterprise-approved forks that no longer match the original publisher’s reputation. In those cases, current guidance suggests prioritising maintainability, code review, and permission minimisation over raw install counts. Another common exception is offline or internal tooling, where an extension may have few installs but still be high trust because it is signed, reviewed, and tightly scoped.

Reputation can still help with triage, but it should not override technical validation. If an extension has access to secrets, session tokens, or internal applications, it should be treated more like a privileged workload than a consumer app. That is why NHI governance patterns apply here as well: the question is not how popular the extension is, but whether its identity, permissions, and updates are continuously controlled. Organisations that rely on rating signals alone tend to discover the gap only after a trusted extension has already been used as the delivery path for compromise.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on EDR alone for browser security?
• What breaks when organisations rely only on USB blocking for device security?
• What breaks when organisations rely on detection after an agent acts?
• What breaks when organisations rely on video alone to verify participants?