A warning sign is broad developer adoption with weak permission review and little post-install telemetry. If teams cannot answer which extensions are installed, what they can access, and which are approved for privileged workflows, then the marketplace is functioning as an uncontrolled trust broker.
When marketplace usage starts to outpace control evidence
Marketplace risk is usually underestimated when adoption grows faster than review, inventory, and monitoring. The warning sign is not just that people install extensions, but that the organisation cannot prove which ones exist, what permissions they hold, or whether those permissions are still justified. At that point, the marketplace is no longer a convenience layer, it is part of the trust boundary.
That matters because extension ecosystems often concentrate access to source code, secrets, browser sessions, API tokens, and internal data. A marketplace can look safe at the point of download while still creating a large blind spot after installation. Secrets in VS Code extensions 2025 shows why post-install visibility matters as much as pre-install reputation.
What underestimation looks like in practice
The clearest signal is a mismatch between deployment scale and governance maturity. If extensions are widely approved by individual teams, but there is no central view of installed packages, requested permissions, or privilege-bearing use cases, then risk is being treated as local when it has already become enterprise-wide. A second signal is when approval decisions rely on vendor trust or popularity rather than on access scope and data exposure.
Marketplace risk also becomes understated when teams assume that a benign first install means benign long-term behaviour. Extensions can update, widen scope, or begin interacting with secrets and internal services after initial approval. If security teams are not watching for drift between declared purpose and effective capability, they are evaluating the extension catalogue as a static list instead of a living supply chain.
This is where marketplace review overlaps with software supply-chain security. The issue is not only whether an extension is published, but whether the publishing path, update path, and permission path can all be trusted over time. JetBrains Marketplace AI Plugin Campaign is a reminder that marketplace trust can be exploited at the point of distribution, not only through overt malware.
How to judge whether the trust model is failing
If a team cannot answer three questions quickly, the marketplace has probably crossed from manageable risk to hidden exposure: which extensions are installed, what they can access, and which are approved for privileged workflows. Those answers should be available at least at the level of device, user group, and business function. If they are not, the marketplace is functioning as an uncontrolled trust broker rather than a governed software channel.
- Can security inventory extensions across endpoints, workspaces, and user groups?
- Can the team map each extension to requested permissions and sensitive resources?
- Can the team identify which extensions are allowed in high-risk workflows such as code editing, secret handling, or release operations?
When the answer to any of those is no, the practical risk is not theoretical. It means teams may be allowing broad execution and data access without a reliable way to measure exposure, investigate abuse, or revoke unsafe software quickly enough.
Risk and Threat Considerations
Marketplace ecosystems create a scale problem: one trusted channel can become many distributed trust decisions. The risk is that benign adoption hides a widening attack surface, especially when extensions can access developer credentials, source repositories, or sensitive internal tooling without strong post-install oversight.
Failure mechanism: Attackers and malicious publishers exploit the gap between initial approval and later capability by using updates, overbroad permissions, or hidden data access paths to turn a normal extension into a credential-collection or code-exfiltration mechanism.
Impact: The result can be secret theft, unauthorized code access, compromised developer environments, and repeatable enterprise-wide exposure if the same extension is installed across many users or build paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Software Inventory | Extension marketplaces are governed by software inventory and approval visibility. |
| Recommendation — Inventory all installed extensions and flag unsanctioned or unreviewed packages. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | The question centers on whether installed extensions and their footprint are known. |
| AC-6 — Least Privilege | Marketplace risk rises when extensions hold excessive permissions for privileged workflows. | |
| Recommendation — Maintain a current inventory of extensions and their effective access scope. Restrict extension permissions to the minimum access needed for the approved use case. | ||
| SLSA | SLSA — Supply-chain Levels for Software Artifacts | Marketplace risk is a supply-chain problem when update and distribution trust are weak. |
| Recommendation — Apply provenance checks before trusting extension updates in production workflows. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Marketplace extensions often act as third-party access paths with secret and token exposure. |
| Recommendation — Assess third-party extensions for secret handling, update trust, and blast radius. | ||
Practitioner Guidance
What to verify: Treat extension inventory, permission scope, and privileged-use approvals as baseline controls, not optional enhancements. If you cannot generate a current list of installed extensions and their effective access, your risk view is incomplete.
What to measure: Track the proportion of extensions with access to sensitive workflows, the number of unsanctioned installs, and the time needed to identify and remove a high-risk extension after discovery. Long detection or removal times usually indicate that trust has outrun governance.
Common mistake: Approving extensions by brand reputation or user demand while ignoring permission breadth. A popular extension with weak post-install telemetry is often more dangerous than a niche tool with clear controls.
Practitioner takeaway: The key test is not whether a marketplace is widely used, but whether every installed extension remains observable, bounded, and revocable after it enters the environment.
Related resources from NHI Mgmt Group
- How can security teams tell whether an extension is over-privileged?
- How can security teams tell whether secret exposure has become a propagation risk?
- How can teams tell whether cloud data security controls are actually reducing risk?
- How can security teams tell whether serialization risk is actually controlled?