They often assume human review can catch malicious intent before release. GlassWorm shows that invisible characters, obfuscation, and auto-update paths can bypass that assumption. Teams need automated inspection that normalises content, checks publisher trust, and validates behaviour after installation.
Why This Matters for Security Teams
Extension review fails when teams treat code inspection as a one-time gate instead of a control against actively adversarial software. Modern extensions can hide intent with invisible characters, layered obfuscation, and update channels that change after approval, which means a clean-looking review is not the same as trustworthy behaviour. The risk is not limited to one platform: the broader pattern is supply-chain abuse plus overconfident manual review.
NHI Management Group research on hard-coded secrets in VSCode extensions shows how quickly extension ecosystems can become a credential exposure problem, not just a code-quality issue. That aligns with the wider NHI security gap documented in The State of Non-Human Identity Security, where only 1.5 out of 10 organisations are highly confident in securing NHIs. In practice, many security teams encounter malicious extension behaviour only after a token, session, or developer workflow has already been exposed, rather than through intentional pre-release review.
How It Works in Practice
Effective extension review needs to move from “read the source” to “inspect the artifact, the publisher, and the runtime behaviour.” For extension ecosystems, the code that gets reviewed is often only part of the story. Security teams should normalise text before inspection so hidden Unicode, zero-width characters, and comment obfuscation cannot conceal logic. They should also verify whether bundled dependencies, post-install scripts, and remote fetches introduce behaviour that is not obvious in the manifest.
Current guidance suggests three layers of control:
- Static inspection that deobfuscates code, normalises Unicode, and flags suspicious network calls, encoded payloads, and install-time actions.
- Publisher trust validation, including signature checks, ownership history, and whether the extension has changed its behaviour since prior versions.
- Post-install monitoring that records permissions use, outbound connections, and attempts to read files, tokens, or development tools.
This is where broader security baselines matter. NIST SP 800-53 Rev. 5 Security and Privacy Controls supports monitoring, configuration management, and supply-chain oversight, but it does not remove the need for extension-specific analysis. The lesson from Hard-Coded Secrets in VSCode Extensions is that secrets exposure can originate in the extension itself or in the developer workflow it touches. These controls tend to break down when extension behaviour shifts after publication because auto-update paths can deliver new logic without re-running the original human review.
Common Variations and Edge Cases
Tighter inspection often increases review time and false positives, requiring organisations to balance release speed against the chance of shipping a compromised extension. That tradeoff becomes sharper when teams rely on marketplace reputation alone, because popular extensions can still be updated with malicious logic after trust has been established.
There is no universal standard for this yet, but current guidance suggests treating signed code as necessary but not sufficient. Portable extensions, marketplace packages, and internal developer tools each create different inspection problems. A packaged extension may look safe statically while still making dangerous calls at runtime; an internal tool may bypass marketplace controls entirely; and a trusted publisher account may be the easiest thing for an attacker to hijack.
Security teams should also distinguish between code review and behaviour review. The first answers “what is in the file,” while the second answers “what will this extension do once it runs.” For extension ecosystems that depend on automatic updates, the second question matters more. Where teams cannot continuously re-inspect updated artifacts, they should assume review drift and apply stronger allowlisting, sandboxing, and telemetry. That approach is especially important when extensions have access to source code, secrets, or build pipelines.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-08 | Extension review must detect hidden secret exposure and unsafe NHI handling. |
| OWASP Agentic AI Top 10 | A-04 | Autonomous update and execution paths create agent-like runtime risk. |
| CSA MAESTRO | T.3 | Marketplace trust and post-install control are core to supply-chain defense. |
| NIST AI RMF | Risk management must account for evolving behaviour after initial approval. | |
| NIST CSF 2.0 | PR.DS-6 | Extensions can expose or move sensitive data and credentials. |
Treat extension execution as dynamic behavior and validate tool access at runtime, not just at review.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
