Threat Actors Targeting Software Developers Guide: fake jobs, poisoned packages and extensions explained

Software developers have become a primary target because one developer laptop holds the tokens that publish packages, push code and reach production cloud accounts. State-backed groups and criminal crews now approach developers directly with fake job interviews, repository collaboration invites, poisoned npm packages, malicious editor extensions and hijacked maintainer accounts, then use what they steal to reach many more victims downstream. This guide maps the actors and the five main routes they use, sets out the controls that break each route, and gives a phased rollout, detection signals and metrics. It is for application security leads, platform and DevOps engineers, engineering managers and SOC teams. The wider supply chain programme is covered in the Software Supply Chain Security Guide; this page focuses on the developer as the point of attack.

Key takeaways

• The target is the credential, not the code. CISA's September 2025 alert on the Shai-Hulud worm describes it scanning for GitHub personal access tokens and AWS, Google Cloud and Azure keys, then using npm credentials to infect more packages.
• Social engineering beats scanners. Unit 42 notes the Contagious Interview malware needs Node.js and a human to run it, which helps it evade automated scanners. The FBI warns of "pre-employment tests" that require running unfamiliar code.
• Every identity that can publish is a production credential. Recent npm compromises used a lead maintainer's account, a former contributor's account and stolen publishing tokens. Trusted publishing with tokens disallowed removes most of that risk.
• Editor extensions run with full user rights. VS Code documents that extensions have the same permissions as VS Code itself, and offers an AllowedExtensions policy to restrict them.
• Isolation is the cheapest control. Run interview tasks and unknown repositories in a disposable virtual machine or dev container with no access to company credentials, as the FBI recommends.

Why developers are worth targeting

A developer workstation is a concentrated store of non-human identities. Each one gives an attacker a different kind of reach.

See the Developer Workstation and IDE Security Guide for workstation baseline controls.

Who is targeting developers

Attribution below is given as the named source states it.

Actor profiles: the Contagious Interview Threat Actor Profile Guide, the Lazarus Group Threat Actor Profile and the APT38 Threat Actor Profile Guide. The North Korea Cyber Operations Guide covers the state context.

The five attack routes

1. Fake jobs and coding tests

• How it works: a recruiter persona, often with a fake company website, invites the developer to an interview and asks them to clone a repository or install a package to review or debug it. Unit 42 describes the malicious package installing BeaverTail, which steals browser credentials and wallet data and loads the InvisibleFerret backdoor.
• Warning signs from the FBI's September 2024 PSA: pressure to run unknown code for a test, insistence on custom software for a video call, scripts that claim to fix a call or video problem, and requests to move to another messaging app.
• Insider variant: the reverse scheme places fake workers inside companies. See the Insider Threat from Fake IT Workers Guide (North Korean IT Worker Schemes).

2. Repository collaboration invites

• How it works: GitHub reported that Jade Sleet personas, some of them hijacked legitimate accounts, invited targets to collaborate on repositories and persuaded them to run the contents. The malicious npm packages were often published only when the invitation was sent, limiting scrutiny.
• Check: GitHub advises reviewing the security log for action:repo.add_member events from suspicious accounts.

3. Registry account takeover and worms

• How it works: the attacker obtains a maintainer's token or account, publishes a version with an install script, and the script harvests more tokens and republishes the victim's other packages. GitHub removed more than 500 compromised packages in the first Shai-Hulud wave.
• Why install scripts matter: preinstall and postinstall hooks run with the installing user's rights. See the npm Install-Time Security Guide and the Shai-Hulud npm Worm Guide.

4. Malicious IDE extensions

• How it works: an extension published to a marketplace, or an update pushed with a stolen publisher token, reads tokens and wallets from the developer's machine. VS Code states that extensions can read and write files, make network requests and run processes.
• Platform defences: the VS Code Marketplace scans new extensions and updates, marks verified publishers, blocks name squatting, and automatically uninstalls block-listed extensions; since VS Code 1.97 users are asked to trust third-party publishers. Other marketplaces, such as Open VSX, have their own processes. See the GlassWorm VS Code Extension Worm Guide.

5. Release and build tampering through a developer account

• How it works: with a hijacked contributor account, an attacker replaces release binaries or commits code that the project's own pipeline then ships with valid provenance. Provenance proves where an artefact was built, not that the commit was legitimate.
• Control: immutable releases, required reviews on release branches and protected workflow files.

Mapping to MITRE ATT&CK

Controls that break each route

npm documents that trusted publishing needs npm CLI 11.5.1 or later and Node.js 22.14.0 or later, supports GitHub Actions, GitLab CI/CD and CircleCI cloud runners, and does not yet support self-hosted runners. See the npm Trusted Publishing and Provenance Guide and the npm Tokens Security Guide.

Where identity fits

• Inventory developer-held NHIs: list every registry token, personal access token, deploy key and cloud key tied to each engineer, with expiry and scope. Most organisations cannot answer "who can publish our packages?" quickly.
• Offboard from registries, not only from the directory: registry and marketplace accounts are often personal accounts outside single sign-on. The Mastra compromise used a former contributor's account that still held publish rights.
• Prefer workload identity in CI: OIDC federation from CI to registries and clouds removes the long-lived secrets that stealers look for.
• Bots are identities too: dependency update bots and auto-merge workflows act on new releases within minutes. Give them cooldowns and require human review for major or new dependencies.

Implementation: a phased rollout

1. Weeks 1 to 2, inventory and quick wins: list who holds publish rights on every package and extension you own; remove inactive maintainers; require WebAuthn 2FA on registry and source control accounts; brief engineers on recruiter lures using the FBI indicators.
2. Weeks 3 to 6, isolation: provide a sanctioned disposable environment (VM or cloud dev environment) for interview tasks and untrusted repositories; enable Workspace Trust by default; publish a one-page rule that external code never runs on a company laptop.
3. Weeks 4 to 8, extension control: collect the extensions in use, build an allowlist, deploy AllowedExtensions to a pilot group first, review breakage for two weeks, then roll out. Rollback is removing or widening the policy value; note that a syntax error means the policy is not applied at all, so check the VS Code Window log after each change.
4. Weeks 6 to 12, publishing: move each package to trusted publishing, confirm a release works, then select "disallow tokens". Keep one documented break-glass maintainer with hardware-key 2FA. Rollback is re-enabling token publishing for that package only while the pipeline is fixed.
5. Quarter 2, credential hygiene: replace plaintext cloud keys on laptops with SSO-based short-lived sessions; set maximum lifetimes on personal access tokens; route dependency installs through an internal proxy with a cooldown for new versions.

Decision guidance

• Allowlist or open marketplace: an allowlist suits regulated teams and teams with production access; a smaller team may start with a blocklist of known-bad extensions and a requirement for verified publishers, then tighten.
• Private marketplace or allowlist only: VS Code's private marketplace is available to GitHub Enterprise customers and supports air-gapped rehosting; the allowlist alone is enough where internet access to the public marketplace is acceptable.
• Small organisations: focus on three things: no external code on work devices, WebAuthn on GitHub and npm, and trusted publishing for anything you ship.
• Large organisations: add an internal registry proxy, centrally managed extension policy, token lifetime limits enforced at the organisation level, and SOC detections on developer endpoints.

Detection and measurement

• Packages using trusted publishing with tokens disallowed: target 100 per cent of those you publish.
• Publish-capable accounts without WebAuthn 2FA: target zero.
• Median age of personal access tokens: trending down, with a maximum lifetime set.
• Developer endpoints with the extension policy applied: target 100 per cent of managed devices.
• Time to revoke all credentials of one developer: tested, target under one hour.

Common failure patterns

• Running the interview task on the work laptop: the FBI's guidance is to run pre-employment tests only in a virtual machine on a non-company device. One run can expose every token on the machine.
• Former contributors keep publish rights: in the Mastra npm Supply Chain Attack 2026, a contributor account that had long stopped contributing still held publish rights across the scope.
• Publish rights on one person's machine: in the axios npm Compromise 2026, a remote access trojan on the lead maintainer's computer was enough to publish, and dependency bots spread the release within minutes.
• Trusting provenance as proof of innocence: the Tensorlake npm Worm 2026 shipped through the project's own pipeline with valid build provenance after malicious code was committed under a maintainer's name.
• Mutable releases: in the OVHcloud CLI Compromise 2026, release immutability was off, so a hijacked contributor account swapped binaries on already published versions. A user who pinned a SHA-256 hash caught it.
• No extension governance: the GlassWorm Campaign 2025 used extensions to steal npm, GitHub and Open VSX credentials, then pushed further malicious updates with them.

Lessons from incidents

Across these cases the initial approach varied (a recruiter, a fake Teams error, a worm, an extension) but the damage always came from a long-lived credential on a developer machine with broad publish or repository rights. The controls that would have changed the outcome were the same: isolation of untrusted code, publishing through OIDC with tokens disallowed, prompt offboarding from registries and immutable releases. The Shai-Hulud npm Worm 2025 page shows how quickly one stolen token becomes thousands of exposed secrets.

Framework mapping

Practitioner checklist

• Publish a rule that external or interview code never runs on company devices, and provide a disposable environment for it.
• List every account and token that can publish your packages or extensions, and remove inactive ones.
• Require WebAuthn 2FA on GitHub, npm and other registries for all maintainers.
• Move releases to trusted publishing and select "Require two-factor authentication and disallow tokens".
• Deploy the VS Code AllowedExtensions policy, piloting first and checking the Window log for syntax errors.
• Turn on release immutability and branch protection for release paths.
• Replace plaintext cloud keys on developer machines with short-lived SSO sessions.
• Add EDR detections for install-time network connections and credential file reads on developer endpoints and CI runners.
• Rehearse revoking all credentials for one developer in under an hour.

Standards and references

• CISA: Widespread supply chain compromise impacting npm ecosystem
• FBI: Public Service Announcement I-090324-PSA on North Korean social engineering of the cryptocurrency industry
• GitHub: Security alert, social engineering campaign targets technology industry employees
• GitHub: Our plan for a more secure npm supply chain
• npm Docs: Trusted publishing for npm packages
• Visual Studio Code: Extension runtime security
• Visual Studio Code: Enterprise extension management
• Palo Alto Networks Unit 42: Contagious Interview and Wagemole, two job-related campaigns linked to North Korea

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · Developer Workstation and IDE Security Guide · Contagious Interview Threat Actor Profile Guide · npm Tokens Security Guide · Threat Actor Groups Guide