Developer device compromise is the real target in VS Code attacks

At a glance

What this is: This is an analysis of how malicious VS Code extensions can turn trusted developer tooling into a credential-harvesting path and expose internal assets.

Why it matters: It matters because developer workstations increasingly hold the credentials and tokens that connect source code, build systems, and cloud control planes across both human and non-human identity programmes.

By the numbers:

• The malicious version was pulled within 18 minutes on the VS Code Marketplace and 36 minutes on Open VSX.

👉 Read Aikido's analysis of the GitHub VS Code extension breach and developer device risk

Context

Developer tooling is now part of the identity attack surface. When extensions, package managers, and local development environments can read secrets, tokens, and workspace files, the compromise path is no longer limited to phishing or server-side intrusion. The first failure is often trust in the software supply chain around the workstation, not in the codebase itself.

This is relevant to IAM and NHI governance because developer endpoints frequently store the secrets that bind human access to non-human access. A malicious extension that harvests environment files or cached credentials can bridge human identity compromise into service account abuse, CI/CD access, and broader repository exposure. That starting position is increasingly typical, not exceptional.

Key questions

Q: How should security teams reduce the risk from malicious developer extensions?

A: Start with installation controls, not just detection. Enforce a minimum-age policy for new extensions and updates, inspect package reputation before approval, and limit which developers can install tooling from public marketplaces. Pair that with endpoint visibility into secret access so suspicious extension behaviour is connected to identity events, not treated as a standalone device issue.

Q: Why do developer workstations create NHI risk as well as human identity risk?

A: Developer workstations often store or reach cloud keys, API tokens, SaaS sessions, and service-account paths used by automation. If malicious code runs in that context, the attacker can move from a human session into non-human identities and production controls without needing a separate breach.

Q: What breaks when EDR is the only control on developer devices?

A: EDR mainly catches suspicious binaries and process behaviour, so it can miss interpreted payloads inside extensions, scripts, and package installs. That leaves a gap where malware can read workspace files and secrets without looking like classic endpoint malware. Teams need controls that inspect software supply chain content, not only executable behaviour.

Q: Who is accountable when a developer tool leads to credential exposure?

A: Accountability sits across endpoint security, identity governance, and the engineering team that approved or installed the tool. If the exposed material includes secrets or delegated access, the issue becomes an identity incident, not just a malware event. Frameworks such as NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 support that shared ownership model.

Technical breakdown

Why malicious extensions are a supply chain problem

VS Code extensions sit inside a developer’s trusted execution environment and inherit access to files, terminals, environment variables, and workspace context. When a publisher is verified or a package is widely installed, developers are less likely to inspect permissions or delay installation. That creates an abuse path where the malware does not need sophisticated obfuscation; it only needs to run long enough to read secrets and send them out. The real security issue is that trust signals in developer tooling are now part of the attack surface.

Practical implication: treat extension trust as a supply chain control, not a usability preference.

Why EDR misses plain-text developer tool malware

Traditional EDR is tuned for compiled binaries, suspicious processes, and endpoint behaviours that fit classic malware models. Extension payloads, npm packages, and Python scripts are often interpreted text and can blend into ordinary developer activity such as reading .env files or workspace metadata. That means the malicious action happens inside trusted tooling, not as an obvious executable drop. The gap is architectural: the detection layer is too low-level or too coarse for software supply chain attacks that live in source and package ecosystems.

Practical implication: add package and extension inspection at the workstation layer, not only binary detection.

How workstation-level enforcement reduces the attack window

A short-lived malicious package can still succeed if installation is immediate. Minimum-age policies change that by forcing a delay between publication and installation, which creates a window for community detection, reputation checks, and malware feed updates. Combined with real-time blocking, this shifts control from retrospective cleanup to preventative enforcement on the endpoint itself. For distributed developer teams working from home networks or personal hotspots, device-based policy is often the only reliable place to apply that control consistently.

Practical implication: enforce delayed installation and fallback-to-safe-version logic on developer devices.

Threat narrative

Attacker objective: The attacker aims to harvest developer-held credentials and use them to reach private code, build assets, and connected systems.

1. Entry occurred when a trusted VS Code extension was tampered with and installed on a developer workstation through normal marketplace workflows.
2. Credential access followed as the malicious extension silently read workspace content and environment files to collect secrets.
3. Impact emerged when stolen credentials enabled unauthorized access to private repositories and associated internal development assets.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• 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

Developer tooling has become a non-human identity trust boundary. Extensions, packages, and local agents often hold the same secrets that underpin service accounts and CI/CD access. Once those tools can read workspace files and environment variables, the workstation becomes part of NHI governance whether teams model it that way or not. The control failure is not just malicious code, but ungoverned trust at the point where human and non-human identities intersect.

Short-lived supply chain compromises expose a standing credential assumption. A malicious extension that survives for minutes can still extract usable secrets before community takedown or after-install detection. That means incident response alone is too late when the real issue is persistent credential availability on developer devices. Organisations should assume that any trusted developer tool can become a credential collection point unless installation and execution are bounded tightly.

Minimum-age enforcement is a governance control, not a convenience feature. The practical value is not merely blocking unknown software, but creating time for validation before code reaches a machine that can reach source, cloud, and production pipelines. This is a useful model for identity security because it treats trust as revocable and temporary rather than implicit. Practitioners should frame this as blast-radius reduction for the developer estate.

Secret exposure on endpoints is now a cross-domain identity problem. A workstation compromise can hand an attacker the tokens needed to impersonate users, services, and automation. That collapses the separation between human identity compromise and NHI abuse. Security teams should align endpoint policy, secrets governance, and IAM reviews around shared credential exposure rather than treating them as separate programmes.

From our research:

• When attackers exposed AWS credentials publicly, they attempted access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• Forward pivot: See The State of Secrets in AppSec for how secret sprawl and remediation lag shape the developer compromise window.

What this signals

Developer workstation compromise is becoming a first-class identity risk because the endpoint often stores the credentials that link human access to NHI access. Once that boundary is crossed, repository theft, cloud login abuse, and pipeline access can all follow from a single malicious extension. The governance implication is clear: device trust, secrets handling, and IAM policy now need a shared operating model.

Workspace trust debt: the longer organisations allow immediate installation of newly published tooling, the more they accumulate exposure that community detection must later unwind. That creates a predictable window in which reputation, not control, decides whether a malicious package lands. The better response is to shift from retrospective cleanup to policy-driven delay and inspection on the device.

Developer security programmes should now measure how many secrets are reachable from standard workstations, how quickly a compromised tool could access them, and whether identity logs can be joined to endpoint events fast enough to contain abuse. If those answers are unclear, the environment is already relying on trust signals rather than enforceable controls.

For practitioners

• Enforce minimum-age controls for extensions and packages Block newly published extensions and packages for a defined hold period, then allow installation only after reputation and malware checks have stabilised. Apply the same policy to updates, not just first-time installs, so a trusted tool cannot become malicious through a silent version swap.
• Inspect developer workstation secrets paths Monitor access to .env files, credential caches, token stores, and package metadata on developer endpoints. Focus on the places where extensions and interpreted packages can read secrets without spawning obvious malware processes.
• Separate workstation trust from repository trust Assume a compromised developer device can bridge into private repos, build systems, and cloud consoles. Reduce that bridge by limiting long-lived credentials on endpoints and by tying sensitive actions to just-in-time approval where feasible.
• Correlate endpoint telemetry with identity events Join device activity with repository access, cloud logins, and token use so unusual extension behaviour can be linked to identity abuse quickly. This is especially important when the initial compromise is a plain-text script that EDR is unlikely to flag.

Key takeaways

• Malicious developer extensions turn trusted tooling into a practical credential-harvesting path, especially where workstations hold secrets for code, cloud, and automation.
• The exposure window can be measured in minutes, while remediation often takes far longer, which makes prevention at the device level more important than post-detection cleanup.
• Security teams should govern developer devices as part of identity security, because workstation compromise can become both human identity abuse and NHI abuse in one chain.

Key terms

• Developer device trust boundary: The point where a personal or managed workstation becomes part of the organisation’s security perimeter because it can reach repositories, cloud consoles, and secret stores. When that boundary is weak, trusted tools on the device can become direct paths to identity and data compromise.
• Extension supply chain attack: A compromise in which a trusted browser, editor, or IDE extension is altered to perform malicious actions after installation. The attack succeeds by abusing legitimacy and convenience, often collecting secrets or altering behaviour inside software developers already trust.
• Minimum-age policy: A control that delays installation of newly published software until it has existed long enough for reputation checks, community review, and malware detection to stabilise. In developer environments, it reduces the chance that a short-lived malicious package reaches a machine before it can be flagged.
• Plain-text payload malware: Malicious code delivered as scripts or interpreted source rather than compiled binaries. It can evade conventional endpoint detection because it blends into normal development activity, yet still read files, tokens, and workspace data needed for credential theft.

What's in the full article

Aikido's full blog post covers the operational detail this post intentionally leaves for the source:

• The specific Device Protection enforcement logic for blocking newly published extensions and packages before install.
• The fallback behaviour that returns developers to the most recently published safe version when a package is held back.
• The product’s coverage across npm, PyPI, VS Code Marketplace, JetBrains, Cursor, and Windsurf ecosystems.
• The implementation detail behind real-time malware feed checks on workstation installs and updates.

👉 Aikido's full post covers the Nx Console attack pattern, developer-device enforcement, and the protection model in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programmes that depend on them.