SaassyCode shows how VS Code extensions became a sleeper supply chain

At a glance

What this is: SaassyCode is a coordinated VS Code extension campaign that grew to nineteen extensions, combining sleeper publishing, update-based weaponisation, and heavier obfuscation after disclosure.

Why it matters: It matters because developer IDE extensions sit inside high-trust environments that often contain credentials, source code, and pipeline access, so NHI and supply chain governance must extend beyond first install.

By the numbers:

• Continued investigation has confirmed they are part of a coordinated family of nineteen extensions, published over a 19-day window from May 20 to June 7, 2026 and still growing.
• StudioBoard had accumulated 1,281 installs by the time of detection and pushed four versions in a single day.

👉 Read Knostic's full SaassyCode analysis of the nineteen-extension campaign

Context

SaassyCode is a supply chain campaign hidden inside a developer workflow problem: malicious VS Code extensions can behave like trusted tooling until they update, restart, or reach out for payloads. In this case, the primary identity risk is not human sign-in, but the non-human extension identity that runs inside a privileged development environment.

The pattern matters for NHI governance because package registries, extension marketplaces, and update channels are all identity-bearing distribution points. Once an extension can silently change behaviour after installation, publication-time review no longer describes the actual runtime trust state, which is the point most teams still treat as stable.

The article shows a campaign that adapted quickly after disclosure, moving from straightforward payload delivery to heavier obfuscation and sleeper positioning. That is a typical failure mode for modern developer supply chain abuse, not an edge case.

Key questions

Q: How should security teams handle VS Code extensions that change after installation?

A: Treat the extension as a versioned trust relationship, not a one-time approval. Revalidate when a publisher updates code, especially if the extension auto-activates, downloads remote content, or can execute on startup. The safest model is continuous review of the installed version, the publisher’s behaviour, and the endpoint context where the extension runs.

Q: Why do sleeper extensions create a governance gap for developer environments?

A: Sleeper extensions break the assumption that a trusted package stays in the state that was reviewed. Once a clean version accumulates installs, a later update can introduce malicious behaviour without a new installation event. That makes lifecycle governance, update gating, and behavioural monitoring more important than first-publish scanning alone.

Q: What do security teams get wrong about extension marketplace scanning?

A: They often treat marketplace approval as proof of runtime safety. In practice, static review only captures the package state at submission time, while the real risk may emerge after restart, update, or code obfuscation. Teams should use scanning as one control, not the control that closes the case.

Q: What should organisations do when developer tooling can execute code on startup?

A: Put the tool inside the same governance boundary as other endpoint-executing identities. Restrict who can install it, require re-review for privilege-changing updates, and monitor for hidden process creation or outbound retrieval. If startup execution is allowed, then its trust must be managed like an active workload, not a passive plugin.

Technical breakdown

Sleeper extensions and update-based weaponisation

A sleeper extension is clean at first publication and becomes malicious later through a normal update path. In VS Code, that matters because the user’s trust decision is anchored to the original install, while the runtime identity of the extension can change without a fresh approval event. The SaassyCode family demonstrates that a benign first version can accumulate installs, then deliver a payload in a later release. That breaks the assumption that publication-time scanning captures the real risk state. For identity security, this is a versioning problem as much as a malware problem: the trusted subject is mutable after onboarding.

Practical implication: govern extension updates as identity changes, not just code changes, and re-evaluate trust whenever a publisher releases a new version.

Why marketplace trust and static analysis are insufficient

Marketplace controls usually evaluate what is present at submission time, but not what an extension may do after update, restart, or obfuscation. SaassyCode shifted infrastructure repeatedly, from custom domains to GitHub, Netlify, Cloudflare Workers, and then code obfuscation, which reduced the value of simple URL and signature-based checks. That progression shows an attacker optimising for the weakest link in the review path. The technical lesson is that static inspection can identify known bad artefacts, but it cannot fully establish behavioural intent for packages designed to delay activation or alter delivery after trust has already been granted.

Practical implication: combine static review with behavioural monitoring, publisher reputation controls, and update gating for developer tooling.

Windows-only payload execution inside the developer IDE

The campaign’s payload chain affects Windows only, which reduces blast radius but does not reduce governance importance. A developer on Windows who restarts VS Code after install can trigger download, execution, and in some cases persistence from within the extension lifecycle itself. That makes the IDE an execution platform, not just a code editor. The BloxyTask variant goes further with an HTA loader, obfuscated batch logic, and in-memory PowerShell injection into Windows processes, showing how an extension can become an initial foothold for broader endpoint compromise.

Practical implication: treat IDE extensions as endpoint-executing non-human identities and apply platform-specific controls on Windows developer workstations.

Threat narrative

Attacker objective: The objective is to gain durable execution on developer systems and pivot into code, credentials, and delivery-chain access that extend far beyond the IDE.

1. Entry via trusted marketplace publication and install, with some family members published clean first and weaponised later through an update.
2. Escalation occurred when the extension activated on startup, fetched remote payloads, and in advanced variants used obfuscation, HTA loading, and in-memory injection.
3. Impact includes persistence on developer workstations, access to source code and credentials, and a widened supply chain blast radius if the extension reaches pipeline or repository trust.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Sleeper extension publishing is the real governance failure in this campaign. The extension was trusted at install time, then changed behaviour later through an ordinary update path. That means the real identity object is the versioned extension lifecycle, not the marketplace listing, and lifecycle governance must follow the object after onboarding as well as before it.

Publication-time scanning no longer describes runtime trust for developer tooling. SaassyCode moved from clean installs to delayed payload delivery, then to obfuscation and serverless hosting after detection pressure. Static checks still matter, but they only tell you what was visible at a point in time, not what the extension can become after the next update. Practitioners need to treat update channels as active trust surfaces, not administrative plumbing.

Identity blast radius is the right concept for developer extensions. A browser extension, IDE plugin, or package registry account is not just code distribution. It is an identity that can inherit trust, alter behaviour, and reach into source control, credentials, and build systems. That makes the governance problem broader than malware containment: it is about constraining how much downstream access a single trusted extension can accumulate.

Windows-only payloads expose a control gap that many software teams ignore. The campaign was not uniformly exploitable across operating systems, which means risk was environment-specific and control-specific. Teams that assume cross-platform tooling has uniform behaviour will miss the reality that the same extension can be harmless on one endpoint class and dangerous on another. The practitioner conclusion is to segment developer-tool policy by host operating system and execution capability.

Developer extension lifecycle review: The SaassyCode family shows that onboarding controls are weaker than offboarding and revalidation controls when an extension can be weaponised later. The point is not simply to block bad code, but to preserve continuous trust alignment between the installed version, the publisher, and the runtime behaviour.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why developer environments remain exposed to extension-driven abuse.
• DeepSeek breach shows how embedded secrets and exposed records can turn a software trust problem into a data exposure event at scale.

What this signals

Developer-tool governance now needs lifecycle controls, not just allowlists. Extensions can be clean at install and malicious at update, so the trust decision has to follow the object over time. That is the same structural problem seen in secrets governance, where the control gap is usually not absence of policy but failure to revalidate changing trust boundaries.

Identity blast radius is expanding into the IDE. When a plugin can execute on startup, the security question is no longer whether the package is on a marketplace, but what downstream systems the package can reach once it is installed. Teams should expect extension review to become part of endpoint, code, and supply chain governance rather than a niche developer tool control.

With 43% of security professionals already concerned that AI systems learn and reproduce sensitive patterns from codebases, according to The State of Secrets in AppSec, developer environments are becoming both a source and a target of higher-order data exposure. That raises the bar for inspection, because trust drift in one plugin can cascade into source, secrets, and build pipelines.

For practitioners

• Reclassify IDE extensions as executable trust objects Inventory every approved extension as a managed non-human identity with publisher, version, install base, and update cadence. Revoke or quarantine extensions that change behaviour between versions without a re-review trigger.
• Gate updates for high-risk developer tooling Require extra review for extensions that can auto-activate, spawn processes, or reach external hosts. Treat automatic update channels as a change-management event, not a routine maintenance action.
• Segment controls by endpoint operating system Apply tighter policy to Windows developer workstations because the observed payload chain executes there. Do not assume a cross-platform extension has equivalent risk on macOS, Linux, and Windows.
• Monitor for post-install behavioural drift Look for new outbound requests, hidden process launches, and startup activation after an extension has already been approved. Behavioural drift is the signal that a sleeper has crossed from benign to weaponised.

Key takeaways

• SaassyCode shows that trusted developer extensions can become malicious after installation, which makes lifecycle revalidation a core control problem.
• The campaign grew to nineteen extensions and over 17,544 combined installs, proving that marketplace scale can outpace publication-time review.
• Teams should manage IDE extensions as executable non-human identities, with update gating, behavioural monitoring, and OS-specific policy.

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.
• Extension Lifecycle Governance: Extension lifecycle governance is the practice of managing publisher trust, version changes, update cadence, and revocation for IDE or marketplace packages. It treats the extension as an identity-bearing object whose behaviour must be revalidated across its entire lifespan, not only at initial approval.
• Identity Blast Radius: Identity blast radius is the amount of downstream access and damage a trusted identity can reach once it is compromised or weaponised. For developer extensions, it includes code, secrets, CI/CD access, and other systems reachable from the IDE environment.
• Startup Activation: Startup activation means code begins running automatically when the host application starts, before a user explicitly opens or invokes the extension. That makes the extension’s behaviour closer to an always-on workload than to a passive add-on, which changes governance and containment requirements.

What's in the full report

Knostic's full research covers the operational detail this post intentionally leaves for the source:

• Full extension-by-extension breakdown of the nineteen-family cluster, including install counts, versions, and publication dates.
• Static analysis notes for the obfuscated Cluster F variants and the BloxyTask infection chain.
• Indicators of compromise and family fingerprints that defenders can use to hunt for exposed developer workstations.
• Remediation guidance for removing sleeper extensions and reporting them through the VS Code Marketplace process.

👉 The full Knostic post covers the extension family map, payload stages, and defender indicators.

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.