Notifications
Clear all
Topic starter
02/08/2026 11:35 am
TL;DR: GitHub’s recent internal repository access investigation followed a malicious VS Code extension path, according to Aikido, while the Nx Console incident showed credentials could be silently collected within minutes of workspace opening. The pattern shifts attention from package trust to workstation-level enforcement, where traditional EDR and network controls often miss the attack surface.
NHIMG editorial — based on content published by Aikido: GitHub breached via a malicious VS Code extension, why developer devices are the real target
By the numbers:
- The malicious version was pulled within 18 minutes on the VS Code Marketplace and 36 minutes on Open VSX.
Questions worth separating out
Q: How should security teams reduce the risk from malicious developer extensions?
A: Start with installation controls, not just detection.
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.
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.
Practitioner guidance
- 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.
- Inspect developer workstation secrets paths Monitor access to .env files, credential caches, token stores, and package metadata on developer endpoints.
- Separate workstation trust from repository trust Assume a compromised developer device can bridge into private repos, build systems, and cloud consoles.
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.
👉 Read Aikido's analysis of the GitHub VS Code extension breach and developer device risk →
VS Code extension attacks: are developer devices now the weak link?
Explore further
02/08/2026 12:48 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Developer device compromise is the real target in VS Code attacks
