They need both, but neither is sufficient alone. Code review can miss hidden or obfuscated payloads, while identity controls can fail if tokens are over-scoped, long-lived, or shared across workflows. The safer model is to govern publisher identities, constrain update pathways, and inspect the content and behaviour of extensions together.
Why code review and identity controls both matter against extension worms
Extension worms exploit a blend of software trust and identity trust. Code review is useful because it can catch suspicious payloads, obfuscated logic, or changes in behaviour before publish. Identity controls matter because the real blast radius often comes from publisher tokens, update permissions, and shared credentials that let a malicious extension keep spreading after the first compromise.
The practical mistake is treating this as a single-control problem. A clean review does not help if the attacker can reuse a publishing token or push updates through a trusted account. Strong identity controls do not help if the extension content itself can still carry hidden malware or if a legitimate publisher account is already compromised.
For that reason, the defence model has to cover the full chain: who may publish, what they may update, how long those privileges last, and what the extension actually does at runtime. A useful starting point is to think in terms of supply-chain trust plus identity governance, rather than code quality alone.
What makes extension worms hard to stop with only one control
Extension worms are attractive because they turn ordinary software distribution into a propagation path. Once an attacker gets access to a publishing workflow, a token, or an extension update channel, they can reuse that trust to reach many installs quickly. That is why GlassWorm campaign 2025 is a useful reference point: it combined hidden code with stolen publishing tokens to spread through extension ecosystems.
Code review tends to look at the file or package in front of you, which helps against obvious malicious logic, but it is weaker against staged behaviour, delayed payloads, or code that looks legitimate until a later update. Identity controls, by contrast, reduce the chance that a stolen or over-scoped credential can keep publishing or altering extensions, but they do not inspect whether the signed or trusted package contains dangerous behaviour. The two controls protect different failure modes.
That is why update-path control is so important. If attackers can move from one publish event to many installs through a trusted marketplace or repo integration, the defence must include the identity that authorises that update, not just the source code that gets published. NHIMG’s Secrets in VS Code extensions 2025 illustrates how exposed publishing tokens can turn extension distribution into a high-speed compromise path.
How to build a safer control model for extension ecosystems
The safer model is to govern the publisher identity as carefully as the code itself. That means limiting who can publish, rotating credentials quickly, avoiding shared tokens, and making sure any automation that signs or ships extensions has only the narrow access it needs. Where possible, approvals for publishing should be separate from the build or packaging steps, so a single compromised workflow cannot both create and release a malicious extension.
It also means treating update rights as a high-value privilege. If an extension can be silently updated, the organisation should assume that any compromise of the publishing identity becomes an integrity incident, not merely an account issue. Identity and lifecycle hygiene are therefore part of the defence, not an admin afterthought. NHIMG’s NHI Lifecycle Management Guide is relevant here because the core pattern is the same: provision narrowly, rotate on schedule, and remove access when it is no longer needed.
At the same time, review and inspection still have a role. Static review, behavioural scanning, and package provenance checks can catch attempts to hide downloader logic, token theft, or unusual post-install behaviour. For high-risk ecosystems, a good defence will combine pre-publish review, release-gate checks, and post-publish telemetry so that suspicious extensions can be disabled quickly if the initial review missed something.
For practitioners who want a broader map of the issue, Top 10 NHI Issues helps frame why overprivilege, credential exposure, and weak ownership are recurring failure patterns in machine-operated trust chains.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Extension worms often spread through exposed publishing tokens and credentials. |
| NHI-05 — Overprivileged NHI | Publisher identities and automation often have more update power than they need. | |
| NHI-07 — Long-Lived Secrets | Long-lived tokens let compromised extension pipelines keep publishing over time. | |
| Recommendation — Rotate and protect extension publishing secrets before they can be reused for malicious updates. Reduce publish and update permissions to the smallest workable scope. Shorten secret lifetime and force regular credential rotation for release workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Publisher and release accounts must be inventoried, controlled, and removed when no longer needed. |
| CIS-6 — Access Control Management | Update paths and release permissions need least-privilege enforcement. | |
| Recommendation — Inventory extension publishing accounts and disable stale or shared access. Restrict extension update and publish rights to approved roles and workflows. | ||
| MITRE ATT&CK | T1588 — Acquire Capabilities | Attackers acquire publishing access or tokens to move malicious code through trusted channels. |
| Recommendation — Hunt for stolen publishing capability and revoke it before the worm spreads. | ||
Practitioner Guidance
What to prioritise: Treat the publisher token, signing path, and update channel as the primary blast-radius controls. If any one of them can be reused across projects or environments, assume the worm can spread faster than a review queue can stop it.
What to verify: Check whether every extension publisher identity is unique, short-lived where possible, and separated from ordinary developer access. Also verify that review is not the only gate, since review alone will not catch compromised-but-legitimate accounts or delayed payload activation.
Decision rule: If the main risk is mass propagation through trusted updates, lead with identity and release-path restrictions; if the main risk is hidden malicious behaviour in the package, strengthen content inspection and runtime monitoring as well.
Practitioner takeaway: The right question is not code review versus identity controls, but whether both are strong enough to break the worm’s trust chain at different points in its lifecycle.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they treat patching as the primary defence?
- When should organisations prioritise identity controls over backup tooling for ransomware defence?
- Should organisations treat identity controls as part of application security?
- Should organisations treat application authentication code as part of identity governance?