SaassyCode shows how VS Code extensions became a sleeper supply chain

At a glance

What this is: Knostic's analysis of SaassyCode shows a nineteen-extension VS Code campaign that used sleeper publication, update-based weaponisation, and heavy obfuscation to evade conventional marketplace scanning.

Why it matters: It matters because developer-tool marketplaces can become supply chain attack surfaces where trust, update cadence, and extension lifecycle controls shape real exposure for CI/CD, source code, and cloud access.

By the numbers:

• StudioBoard had accumulated 1,281 installs by the time of detection.
• The family expanded to nineteen extensions over a 19-day window from May 20 to June 7, 2026.

Context

VS Code extensions are now part of the developer supply chain, not just a productivity layer. When an extension can arrive clean, sit in the marketplace, and later change behaviour through an update, publish-time review misses the real control point.

SaassyCode illustrates that the governance gap is lifecycle-related: approval, trust, and revocation all need to follow the extension after installation. That is a machine identity and software supply chain problem at the same time, because the code path that executes is not the same as the code path that was initially reviewed.

The campaign's post-disclosure evolution also shows how quickly adversaries adapt when scanning improves. The starting position was already atypical in scale and persistence, but the update-driven model made it especially resistant to static detection.

Key questions

Q: What breaks when a VS Code extension is clean at install time but malicious after an update?

A: The trust model breaks because approval was granted for one version, while users later receive a different one through silent update. That means publish-time scanning, manual review, and install-time allowlisting can all miss the weaponisation step. Governance has to follow the version stream, not just the package name.

Q: Why do sleeper extensions create more risk than obvious malicious packages?

A: Sleeper extensions exploit the gap between initial trust and later behaviour. They can accumulate installs while appearing harmless, then activate malicious code after defenders have moved on. That delays detection and can bypass controls that only inspect new submissions or first-run behaviour.

Q: How do security teams know if extension governance is actually working?

A: Measure whether unapproved extensions can be installed, whether dormant packages are being reviewed after sudden updates, and whether malicious listings can be blocked before execution. If a dangerous package can still reach a live workspace, governance is failing at the point that matters most.

Q: What should teams do after a malicious extension is detected?

A: Contain the endpoint, remove the extension, and rotate any secrets that were available in the user session when activation occurred. Then review repository access, package registries, and cloud control planes for follow-on activity. The key question is not only whether the machine is clean, but whether reachable identities have already been abused.

Technical breakdown

How sleeper extensions weaponise the trusted update path

A sleeper extension is published with benign or inert behaviour, then turns malicious in a later version that reaches installed users through the normal update channel. That matters because marketplace controls typically evaluate the version that is visible at submission time, while endpoint trust often assumes an installed extension remains equivalent to the version originally approved. In SaassyCode, users who installed the clean version could receive a weaponised update without reinstalling or reauthorising the tool. The technical pattern is less about initial compromise than about trust continuity across versions.

Practical implication: move review and detection from publication time to version lifecycle control, including post-install change monitoring.

Why static analysis loses value against obfuscated extension payloads

Static analysis inspects code without running it, which works well when URLs, import paths, or execution chains are visible in the package. SaassyCode's later wave hid command-and-control details through heavy JavaScript obfuscation and dynamic string assembly, making simple signature matching and URL extraction unreliable. The more the code builds its payload path at runtime, the less a scanner can infer from the package alone. This is a classic defender problem: the artefact still exists, but the malicious logic is deferred until execution or deobfuscation.

Practical implication: pair static inspection with detonation, behavioural telemetry, and version-diff analysis for extension updates.

How extension lifecycle control becomes a supply chain boundary

Developer extensions are not isolated add-ons. They can inherit the workstation context of a developer who has source repositories, cloud credentials, CI/CD access, and local trust relationships. Once an extension is installed, the governance question is no longer only whether the package was clean at day zero, but whether the publisher, version stream, and execution context remain trustworthy over time. SaassyCode shows that lifecycle governance is the boundary, because the attacker used publishing cadence and update mechanics as the delivery system.

Practical implication: inventory extensions, track version changes, and treat update rights as an access-control decision.

Threat narrative

Attacker objective: The objective was to establish persistent developer-workstation access that could be used to reach source repositories, credentials, and broader build or cloud environments.

1. Initial entry occurred when malicious VS Code extensions were installed from the marketplace under seemingly ordinary developer-tool descriptions.
2. Credential and payload access expanded when a clean version later received a malicious update through the standard extension update mechanism.
3. Escalation followed when the extensions executed payloads on Windows startup, hid their activity, and in advanced variants staged multi-step loaders and shellcode injection.
4. Impact was achieved through persistent developer-workstation access, with the family positioned to reach source code, cloud credentials, and other downstream infrastructure.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• GlassWorm campaign 2025: GlassWorm hid in VS Code extensions with invisible Unicode and stole npm, GitHub and Open VSX publishing tokens to spread.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Sleeper update governance is the real control boundary: This campaign worked because marketplace trust was anchored to publication time instead of version lifecycle. A benign first release can become malicious later, so the trust decision cannot stop at install approval. Practitioners need to treat post-install version drift as the event that matters.

Version continuity assumptions fail when extension authors can reissue payloads silently: The usual assumption is that a trusted extension stays aligned with the reviewed package long enough for periodic scanning to matter. SaassyCode breaks that premise by using the update channel as the weaponisation step. The implication is that developer-tool governance must be version-aware, not package-aware.

Developer IDEs are part of the attack surface because they concentrate downstream privilege: Extensions on a developer workstation can bridge into source control, build systems, and cloud credentials without needing a separate foothold. That makes IDE security a supply chain issue, not a niche endpoint issue. The practitioner conclusion is that extension governance belongs in the same conversation as CI/CD and repository trust.

Heavy obfuscation shifts the balance from detection to evidence quality: Once a campaign starts assembling URLs and module names at runtime, the static review model loses much of its value. That does not eliminate detection, but it changes the evidence standard required to justify trust. Teams should assume that post-disclosure adversaries will change packaging faster than manual review cycles can react.

Lifecycle control for developer tooling is now an identity problem as much as a malware problem: The named concept here is update-based supply chain trust debt. It describes the growing gap between the trust granted at install time and the behaviour that emerges after silent updates. Teams that do not govern that debt will keep discovering malicious behaviour only after it has already reached user machines.

What this signals

Update-based supply chain trust debt: The core governance problem is that an extension can remain installed under an approved identity while its code path changes later. That means the control point is not initial acceptance but continuous version governance, especially for tools that can touch source code or credentials.

Developer-tool marketplaces need the same kind of lifecycle thinking applied to service accounts and secrets. If update channels are not governed, a benign package can become an approved delivery path for payloads without a fresh trust decision.

The campaign also shows why static review alone is a weak boundary once runtime obfuscation appears. When payload assembly moves into JavaScript string building and hidden execution paths, defenders need behavioural evidence, not just package inspection.

For practitioners

• Inventory every approved VS Code extension Build a complete catalogue of installed extensions, publishers, versions, and auto-update settings so you can see which developer tools can change behaviour without reapproval.
• Require review on extension version changes Treat a new extension version as a fresh trust event, especially when the package can fetch code, spawn child processes, or change payload hosting after installation.
• Monitor for sleeper behaviour after installation Add telemetry for extensions that are initially inert but later gain network access, command execution, or obfuscated runtime assembly of URLs and modules.
• Restrict auto-update on high-trust developer tools For extensions that touch repositories, build systems, or credentials, make update cadence and publisher trust part of access governance rather than a convenience setting.
• Validate suspicious extensions in a sandbox Detonate unknown or newly updated extensions in an isolated environment so you can observe startup behaviour, process creation, and hidden payload execution before broad rollout.

Key takeaways

• SaassyCode shows that a clean-looking extension can become a delivery vehicle later, which turns version management into the real security boundary.
• The campaign reached nineteen extensions and more than 17,544 installs, showing that marketplace scale can amplify a trust problem quickly.
• Teams need lifecycle control for developer extensions, because publish-time scanning does not stop a malicious update from reaching already trusted endpoints.

Key terms

• Sleeper Extension: A sleeper extension is software that appears benign at first publication or installation and becomes malicious later, often through an update. In identity terms, the subject is mutable after trust has already been granted, so onboarding controls alone do not describe the true runtime risk.
• Update-based Weaponisation: Update-based weaponisation is the use of a normal software update mechanism to introduce malicious behaviour after the original release has been approved. It breaks review models that assume the first published version is the only one that matters, and it turns version control into a security control.
• Extension Supply Chain Risk: The risk that a browser extension appears trustworthy in a marketplace but later performs data collection or other malicious behavior. This combines publisher trust, permission scope, and update control, and it matters because the extension can become an identity-bearing channel into sensitive browser sessions.
• Static analysis: Static analysis is the inspection of source code or configuration without executing it. It helps identify insecure patterns early, but its value depends on accuracy, timing, and whether the output is usable enough for developers to fix issues while they are still working on the code.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.