A developer’s laptop often holds more privileged access than a production server: cloud keys, package registry tokens, SSH keys, signing keys and a browser logged in to source control.
Attackers have noticed. This guide explains why developer workstation security has become a supply chain issue, how current attacks reach dev machines, and which controls reduce the blast radius without slowing engineers down.
You will find an attack chain walkthrough, a hardening checklist mapped to CIS Controls v8 and NIST CSF 2.0, and detection logic you can adapt for your EDR or SIEM.
Why developer workstation security is now a supply chain problem
Compromising one maintainer’s machine can push malicious code to thousands of downstream users. When the self-replicating Shai-Hulud worm hit npm in September 2025, CISA reported that it compromised more than 500 packages.
It harvested GitHub personal access tokens and AWS, GCP and Azure keys from infected environments, then used stolen npm credentials to publish poisoned versions of the victim’s other packages.
Later variants, covered in reporting on Shai-Hulud stealing npm, GitHub, AWS and Kubernetes secrets, kept the same core loop.
The secrets themselves are often easy to find. GitGuardian counted 23.8 million secrets leaked on public GitHub in 2024, a 25% rise year on year, and found that 70% of secrets leaked in 2022 were still valid. Every one of those started on a developer machine.
What lives on a typical dev endpoint
- ~/.aws/credentials, ~/.config/gcloud, ~/.azure and ~/.kube/config
- ~/.npmrc, ~/.pypirc and registry tokens with publish rights
- ~/.ssh/ private keys, often without a passphrase
- .env files in every project directory
- Browser sessions for GitHub, cloud consoles and CI systems
- For Web3 teams, wallet keystores and Solana id.json keypairs
MITRE ATT&CK tracks harvesting of these files as Credentials In Files (T1552.001).
How attackers reach developer machines
Malicious and hijacked packages
Install-time scripts run with the developer’s full user permissions. Typosquats, dependency confusion and hijacked maintainer accounts all use that access.
Earlier research covered malicious npm and PyPI packages that exfiltrated SSH keys, and the pattern has only grown since.
This maps to ATT&CK Supply Chain Compromise: Compromise Software Dependencies and Development Tools (T1195.001).
IDE extensions
Editor extensions run with the same rights as the editor and are rarely reviewed. Recent incidents include the compromised Nx Console VS Code extension that stole developer and cloud secrets and the breach of GitHub internal repositories via a weaponised VS Code extension on an employee device.
Fake tools and repositories
Attackers publish polished repositories for trading bots, CLI utilities or “AI coding” helpers and promote them where developers look for shortcuts.
Interest in AI coding tools has widened the pool of unfamiliar plug-ins and agents that engineers install with little review.
Crypto developers are a favoured target: someone who checks the SOL price between builds may also keep a funded Solana keypair in the project folder, exactly the file a malicious dependency searches for.
CI/CD pivot
Once a token is stolen, an attacker can move from the laptop to pipelines. The GhostAction campaign injected malicious GitHub Actions workflows to exfiltrate CI/CD secrets, showing how a single personal access token can expose every repository it can write to.
Illustrative attack chain: from npm install to cloud compromise
The following scenario is illustrative and combines techniques seen in public incidents.
- A developer adds a utility package whose maintainer account was hijacked. The new version adds a postinstall script.
- On npm install, the script runs a secret scanner across the home directory and reads environment variables, picking up an npm publish token, a GitHub PAT and AWS keys.
- Secrets are sent to an attacker endpoint over HTTPS, disguised as telemetry.
- With the npm token, the malware republishes the developer’s own packages with the same payload (worm behaviour).
- With the GitHub PAT, it adds a workflow that dumps repository secrets during the next CI run.
- With the AWS keys, the attacker enumerates S3 buckets and creates new IAM access keys for persistence.
Each step after the first depends on a long-lived credential sitting in plain text. Removing those credentials breaks the chain far more reliably than trying to detect every malicious package.
Hardening controls for developer workstation security
The controls below are grouped by the asset they protect. Mappings are to CIS Controls v8 and NIST CSF 2.0.
| Area | Control | Mapping |
|---|---|---|
| Secrets | Replace static cloud keys with short-lived SSO credentials (for example aws sso login, workload identity federation) | CIS 6.x; CSF PR.AA |
| Secrets | Load app secrets from a secrets manager or a password manager CLI at runtime rather than .env files | CIS 3.11; CSF PR.DS |
| Source control | Fine-grained, expiring tokens; phishing-resistant MFA on GitHub and registry accounts; pre-commit secret scanning | CIS 6.5, 16.x; CSF PR.AA |
| SSH | Hardware-backed keys (ed25519-sk) or keys held in an agent; short-lived SSH certificates | CIS 6.x; CSF PR.AA |
| Packages | Lockfiles, pinned versions, install scripts disabled by default, internal registry proxy with quarantine for new versions | CIS 16.4; CSF GV.SC |
| IDE | Extension allow-list managed centrally; block side-loaded VSIX files | CIS 2.5; CSF PR.PS |
| Isolation | Run untrusted code in dev containers or cloud workspaces without access to the host home directory | CIS 4.x; CSF PR.IR |
| Endpoint | EDR on dev machines with rules tuned for build tools rather than exclusions for them | CIS 10.x, 13.x; CSF DE.CM |
Practical configuration examples
Disable npm lifecycle scripts by default and allow them only for packages you trust:
# ~/.npmrc
ignore-scripts=true
# then run trusted builds explicitly
npm rebuild –ignore-scripts=false <package>
Generate a hardware-backed SSH key that requires a physical touch for each use:
ssh-keygen -t ed25519-sk -O resident -O verify-required -C “dev-laptop”
Add a pre-commit secret scan so secrets are caught before they reach a remote:
# .pre-commit-config.yaml
repos:
– repo: https://github.com/gitleaks/gitleaks
rev: v8.18.4 # pin to the version your team has approved
hooks:
– id: gitleaks
Detecting compromise on developer endpoints
Developer machines generate noisy process trees, which is why many teams exclude build tools from EDR.
That is exactly where attackers hide. Instead of broad exclusions, write narrow detections for behaviour that legitimate builds rarely show.
Illustrative hunting query
This KQL-style query looks for package manager child processes reading credential files. Adapt table and field names to your EDR.
DeviceFileEvents
| where InitiatingProcessParentFileName in~ (“node”,”npm”,”npx”,”pnpm”,”yarn”,”python”,”pip”)
| where FolderPath has_any (“.aws”, “.ssh”, “.npmrc”, “.kube”, “.config/gcloud”, “id.json”)
or FileName endswith “.env”
| where ActionType in (“FileRead”,”FileAccessed”)
| summarize Files = make_set(FileName), Count = count()
by DeviceName, InitiatingProcessCommandLine, bin(Timestamp, 10m)
| where Count > 3
Other signals worth alerting on
- Package install processes making outbound connections to webhook services or newly registered domains (CISA specifically advised blocking webhook.site during Shai-Hulud).
- New GitHub workflows or repository secrets created from a personal token outside normal hours.
- Cloud API calls using a developer’s keys from an IP that is not the developer’s usual egress.
- Package publishes to npm or PyPI that did not come from your CI pipeline.
Making secure defaults stick with engineering teams
Controls that slow builds get bypassed. Ship them as defaults in a managed dev image or bootstrap script, so a new laptop arrives with short-lived cloud login, the npm and pip settings above, the pre-commit hooks and the approved extension list already in place.
Track exceptions in the same ticketing system as other security risks and review them quarterly, so a temporary allowance for one package does not become permanent.
Responding when a developer machine is compromised
- Isolate the endpoint and preserve an image if forensics are needed.
- Rotate every credential the machine could reach: cloud keys, registry tokens, GitHub tokens and SSH keys. Assume all of them are exposed.
- Review recent commits, package publishes and CI workflow changes made with those identities.
- Check lockfiles and artifact caches across other projects for the same malicious package versions, as CISA recommended for npm incidents.
- Rebuild the workstation from a known-good image rather than cleaning it in place.
Key takeaways
- Developer workstation security is a supply chain control, because one laptop can publish code and reach production.
- Long-lived secrets in plain-text files are the common thread in npm worms, malicious extensions and CI pivots.
- Short-lived credentials, hardware-backed SSH keys and secrets managers remove most of what attackers steal.
- Disable install scripts by default, pin dependencies and allow-list IDE extensions.
- Tune EDR for developer behaviour rather than excluding build tools, and rotate everything after a compromise.
FAQ
How do I secure secrets on a developer laptop?
Remove static keys where possible by using SSO-based short-lived credentials, load remaining secrets at runtime from a secrets manager, and run pre-commit secret scanning.
How do malicious npm packages steal credentials?
They usually use install-time lifecycle scripts that run with your user permissions, read files such as .npmrc, .env and cloud credential files, and send them to an attacker server.
Should SSH keys have a passphrase?
Yes, at minimum. Better still, use hardware-backed keys such as ed25519-sk or short-lived SSH certificates so a copied key file is useless on its own.
Are VS Code extensions a security risk?
They can be. Extensions run with the editor’s permissions and have been used to steal secrets, so organisations should allow-list approved extensions and block side-loading.
What should I rotate after a developer machine is compromised?
Every credential the machine could access: cloud keys, package registry tokens, source control tokens, SSH keys, signing keys and any secrets in local .env files.
