I spent the first week of April reading three separate threat intelligence reports that, on the surface, had nothing in common. One covered a North Korean campaign that had published over 1,700 malicious packages across five open-source ecosystems. Another detailed a malware operation using a Zig-compiled binary to silently infect every IDE on a developer’s machine. The third walked through a cascading supply chain compromise that turned a trusted vulnerability scanner into a credential-harvesting weapon.

Three different threat actor sets. Three different technical approaches. One shared conclusion: developer workstations are now the highest-value initial access target in enterprise environments.

This is not a supply chain security story, at least not in the way most security leaders think about supply chain risk. This is a story about why attackers have independently arrived at the same strategic calculation and what that convergence should tell us about where our defensive investments are misallocated.

The pattern hiding in plain sight

The Contagious Interview campaign, attributed to North Korean threat actors, crossed a scale threshold in early April when Socket researchers reported that the operation had spread to npm, PyPI, Go Modules, crates.io and Packagist simultaneously. The packages impersonate legitimate developer tooling. Once installed, they function as malware loaders that steal browser data, cryptocurrency wallet credentials and password manager contents. The operation has been running since January 2025, but the expansion to five ecosystems in parallel signals a factory-model approach to developer targeting.

Separately, the GlassWorm campaign evolved from malicious IDE extensions into something more ambitious. Aikido Security researchers discovered a fake WakaTime extension on OpenVSX that bundled a Zig-compiled native binary alongside its JavaScript code. The binary does not operate within the extension sandbox. It runs with full operating system access, scans the machine for every compatible IDE and silently installs a second-stage dropper across all of them. The malware avoids execution on Russian systems and uses Solana blockchain infrastructure for command and control. This is not a smash-and-grab credential theft. It is persistent, cross-platform and designed to survive the removal of any single extension.

Then there is TeamPCP, which executed a cascading compromise that started with Aqua Security’s Trivy vulnerability scanner in mid-March and chained through Checkmarx KICS, LiteLLM and the Telnyx Python SDK. Each compromise provided the credentials needed to reach the next target. The malware ran inside build pipelines and developer machines, stealing cloud tokens, CI/CD secrets and service account credentials. One security tool compromise became the launchpad for four more.

These three campaigns share no infrastructure, no malware families and no apparent coordination. That is precisely why their convergence matters. When unrelated threat actors independently arrive at the same targeting strategy, they are responding to the same structural incentive. In this case, the incentive is straightforward: developer machines are where the keys live.

The economics that drive the convergence

A typical developer workstation holds SSH keys, cloud provider credentials, container registry tokens, Git authentication tokens and CI/CD pipeline secrets. Many developers have administrative access to internal package registries and deployment infrastructure. Their machines often sit outside the hardened perimeter that security teams build around production systems.

From an attacker’s perspective, compromising a single developer is equivalent to a supply chain attack without the complexity of compromising an upstream package registry. You do not need to poison a package that thousands of organizations use. You just need one developer who has push access to a production deployment pipeline. The access-to-effort ratio is simply better than attacking production infrastructure directly. Production systems have monitoring, network segmentation and incident response playbooks built around them. Developer workstations, by contrast, are often trusted implicitly because the people who use them are trusted implicitly.

Google’s Cloud Threat Horizons report for the first half of 2026 documented exactly this pattern: threat actors used a trojanized application to gain a foothold on a developer workstation, then leveraged authenticated sessions and available credentials to pivot into cloud resources. Within 72 hours, they had moved from a developer’s local environment to full cloud administration access by abusing OpenID Connect trust between a CI/CD provider and the cloud platform.

The Security Boulevard analysis of the March 2026 attack wave framed this dynamic as a “Developer Credential Economy,” arguing that these campaigns should not be viewed as isolated incidents but as evidence of a black market for highly privileged developer credentials. That framing is useful because it explains why we are seeing simultaneous but independent campaigns targeting the same environment. The market price for developer access has risen because the downstream value of that access has risen.

What this should change for security leaders

Most organizations treat developer environment security as an extension of endpoint protection. Developers get the same EDR agent, the same patch management and the same access controls as every other employee. Some organizations go further and enforce code signing or require multi-factor authentication for package registry access. But few treat the developer workstation as a distinct attack surface that requires its own security architecture.

The convergence of these three campaigns suggests that distinction is overdue. Developer machines are not just endpoints. They are credential stores, pipeline controllers and trust anchors for the entire software delivery chain. Protecting them requires controls that traditional endpoint security was never designed to provide.

That starts with visibility, which remains the most fundamental gap. Most security operations centers have limited insight into what happens inside IDE extension ecosystems, package manager installations or CI/CD pipeline executions. The GlassWorm campaign exploited OpenVSX, a registry that many security teams do not even monitor. TeamPCP compromised GitHub Actions workflows that run with elevated permissions but often escape the scrutiny applied to production deployments. If your security team cannot tell you which IDE extensions are installed across your developer fleet, you have a blind spot that three different threat actor groups are now actively exploiting.

It extends to architectural decisions about how developer environments are provisioned and isolated. Ephemeral development environments, hardware-bound credentials, restricted network access from build systems and mandatory code review for CI/CD pipeline changes are not new ideas. But they remain uncommon in practice because most organizations have not yet accepted that developer environments require the same defensive investment as production infrastructure.

The most uncomfortable implication is organizational. Developer environment security does not fit neatly into existing security team structures. It sits at the intersection of application security, endpoint security, identity management and supply chain risk. In most organizations, no single team owns that intersection. Application security teams focus on code vulnerabilities. Endpoint teams focus on malware detection. Identity teams focus on access governance. Nobody is watching the IDE extension that just installed a Zig binary with full operating system access. The campaigns of March and April 2026 are exploiting that gap.

Three unrelated threat actors looked at the modern enterprise and independently concluded that the developer workstation offers the best return on investment for initial access. That is not a coincidence. It is a price signal, and the price is set by the gap between the value of developer credentials and the maturity of the controls protecting them. The question for security leaders is whether they will close that gap before the next wave of campaigns arrives to exploit it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?