Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Glassworm and developer IDE risk: what security teams need to do now


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9788
Topic starter  

TL;DR: CrowdStrike says Glassworm has targeted software developers since at least early 2025, using trojanized VS Code extensions, compromised npm and Python packages, and poisoned GitHub repositories to seed a botnet that can steal credentials and push supply-chain compromise downstream. The takedown buys time, but it also shows that developer workstations have become a primary supply-chain attack surface, not just production build pipelines.

NHIMG editorial — based on content published by Knostic covering CrowdStrike's Glassworm takedown: Disrupting Glassworm and the developer-targeting botnet threat

Questions worth separating out

Q: What breaks when malicious code can run inside a developer IDE or package install?

A: Traditional endpoint and supply-chain controls lose time to the same mechanism they are trying to inspect.

Q: Why do developer workstations increase supply-chain risk so quickly?

A: Developer workstations concentrate source code, cloud credentials, CI/CD secrets, SSH keys, and repository permissions in one place.

Q: How should security teams govern IDE extensions and MCP servers?

A: Treat them as executable trust relationships, not convenience features.

Practitioner guidance

  • Inventory every developer execution surface Build a live list of IDE extensions, package managers, MCP servers, and assistant-connected tools across engineering endpoints.
  • Block install-time code execution by policy Restrict extension activation, postinstall hooks, and setup scripts unless the source is approved and the behavior is explicitly expected.
  • Harden developer identity material on endpoints Separate cloud credentials, SSH keys, and password-manager access from everyday editor processes, and enforce scoped access for repository write operations.

What's in the full article

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

  • The full attacker tradecraft behind Glassworm's extension, package, and repository infection paths.
  • The specific command-and-control infrastructure CrowdStrike disrupted across blockchain, peer-to-peer, and web services.
  • The published YARA rules and hunting indicators for the RAT and downloader stages.
  • The remediation actions for engineering fleets that matched the 164.92.88[.]210 beacon.

👉 Read Knostic's analysis of Glassworm and developer-targeting botnet risk →

Glassworm and developer IDE risk: what security teams need to do now?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 9272
 

Developer workstations are now identity-bearing supply-chain nodes. Glassworm is not just endpoint malware, because it targets the place where human identity, machine identity, and build identity intersect. The developer laptop holds cloud credentials, CI/CD tokens, SSH keys, and source code signing paths, so compromise there becomes both access theft and supply-chain insertion. For IAM teams, this is a reminder that developer endpoints must be governed as part of the identity estate, not treated as ordinary user devices.

A few things that frame the scale:

A question worth separating out:

Q: Who is accountable when a compromised developer credential reaches the supply chain?

A: Accountability usually spans identity, endpoint, and software delivery owners because the failure crosses all three domains. The control gap is often weak lifecycle management for secrets and overly broad repository rights. Frameworks such as NIST CSF, NIST SP 800-53, and OWASP NHI are relevant when compromise turns stolen access into downstream code execution.

👉 Read our full editorial: Glassworm shows why developer IDE security is now a supply-chain issue



   
ReplyQuote
Share: