Key Takeaways
- Most developers store npm and PyPI tokens in plain text config files that attackers can find with a single command.
- GitHub Actions OIDC tokens are not inherently safe. Misconfigured workflows leak them just like hardcoded secrets.
- Environment hardening requires a layered approach: file-level protection, scoped tokens, and runtime monitoring.
You spend hours hardening your production servers. You rotate API keys quarterly. You lock down SSH access with key-based authentication only. Then you leave your development environment completely unprotected.
Here is the uncomfortable truth: attackers do not need to break through your firewall when your credentials are sitting in a text file on your desktop. They do not need to exploit a zero-day in your CI pipeline. They just need to know where to look.
The most common attack path against individual developers and small engineering teams is embarrassingly simple. Someone finds a .npmrc file with a registry token. Or a .pypirc file with a PyPI API token. Or a GitHub Actions workflow that has been leaking OIDC tokens since day one.
This is not about sophisticated supply chain attacks. This is not about compromised npm packages. This is about the credentials you are already storing, sitting in plain sight, waiting for someone to find them.
Where Your Tokens Actually Live
Let us start with the most obvious vulnerability. Your npm token.
When you run npm login, the system creates or updates a .npmrc file in your home directory. By default, it looks something like this:
//registry.npmjs.org/:_authToken=npm_xxxxxxxxxxxxxxxxxxxxxxxxThat token grants full access to publish packages on your behalf. It also gives read access to private packages. If someone gets this file, they can publish malicious packages under your identity or access your private code.
Here is what most developers do not realize. That file is not the only place tokens live. Your CI/CD pipelines store them in environment variables. Your Docker images might bake them in during builds. Your IDE syncs them to the cloud. Your backup software archives them.
The same pattern repeats across every major registry. PyPI tokens hide in ~/.pypirc. RubyGems tokens live in ~/.gem/credentials. Conda tokens sit in ~/.condarc. Docker credentials are in ~/.docker/config.json.
Each file uses the same dangerous pattern. Plain text tokens that never expire unless you manually revoke them. No access controls. No audit trails. No alerts when someone reads the file.
For more on how npm tokens are exploited, check out our npm install malware article which covers attack vectors in depth.
The GitHub Actions OIDC Trap
You might be thinking, I do not store tokens in my repos. I use GitHub Actions OIDC. That is a smarter approach, but it is not foolproof.
GitHub OIDC implementation allows workflows to request short-lived tokens for cloud providers without storing long-term secrets. The theory is sound. The execution is where things fall apart.
Consider a workflow that requests an AWS token to deploy to S3. The OIDC token is only valid for a few minutes. It seems secure, right? Not necessarily.
Attackers can exploit several failure modes. First, if your workflow permissions are too broad, a compromised OIDC token becomes a golden key. Second, token reuse is still possible if you store the OIDC response instead of using it immediately. Third, some cloud providers do not validate the full token payload correctly, which lets attackers craft tokens that look valid.
The 2026 PolinRider campaign demonstrated this exact vulnerability. Attackers compromised GitHub Actions workflows across dozens of repositories. They did not steal long-term tokens. They hijacked OIDC sessions and used them to access cloud infrastructure. The tokens were technically valid, but the workflows were compromised.
Here is what most security guides do not tell you. OIDC is not a silver bullet. It is a tool, and like any tool, it can be misused. The real protection comes from understanding the attack surface and building defenses around it.
See our attack vector comparison article for a detailed breakdown of how token theft compares to other attack methods.
A Practical Hardening Framework
Let us talk about what you can actually do. Not theoretical security. Not enterprise-grade solutions that require budget and headcount. Practical steps that work for individual developers and small teams.
Layer 1: File-Level Protection
Start by encrypting your credential files. Tools like git-crypt or SOPS can encrypt sensitive files while keeping them in your repository. The keys stay with you, and the encrypted files are safe to commit.
Alternatively, use environment-specific configuration. Store tokens in environment variables that are loaded from secure storage. Your .npmrc should never contain actual tokens in a shared repository.
Layer 2: Token Scoping and Rotation
Never use global tokens. Both npm and PyPI support scoped tokens with limited permissions. Create tokens that can only publish to specific packages, or only read from private registries.
Set expiration dates on your tokens. npm tokens created through the web interface can have custom expiry dates. PyPI tokens support the same. Rotation is painless when tokens expire naturally, and it limits the blast radius of any compromise.
Layer 3: Runtime Monitoring
Most developers do not monitor their local environment. That is a mistake. Tools like auditd on Linux or File Integrity Monitoring on macOS can alert you when credential files are accessed or modified.
Set up basic filesystem permissions. Your .npmrc should be readable only by your user account. That is it. No group access, no world access. If someone or something can read that file, they have your npm token.
Layer 4: CI/CD Hardening
If you are using GitHub Actions, audit your workflow permissions regularly. The default settings are overly permissive. Use the permissions keyword to restrict what each job can access. Request the minimum permissions needed for each step.
For OIDC workflows, implement token validation. Before using an OIDC token, verify the audience claim matches your expected value. Check the subject claim to ensure the token is from the right repository. These validations are cheap and they catch most misconfigurations.
Common Mistakes That Leak Tokens
Let us talk about the mistakes I see most often. These are not edge cases. They are patterns that happen regularly in production environments.
Mistake number one: committing credential files to version control. You might think you are the only one who clones the repository. But forks exist. Mirrors exist. Security scanners exist. Someone will find that .npmrc file.
Mistake number two: using the same token across multiple projects. Token reuse multiplies your exposure. A compromise in one project gives attackers access to everything that shares that token.
Mistake number three: assuming environment variables are secure. They are not automatically secure. CI systems often log environment variables. Build tools sometimes dump them to temporary files. Your IDE might sync them to cloud storage.
Mistake number four: ignoring token revocation. When someone leaves your team or a project ends, revoke those tokens immediately. Delayed revocation is a common attack vector. Former team members or compromised accounts can still use old tokens.
Learn more about how CI secrets get stolen in our PR secret theft article.
Building Your Security Checklist
Here is a practical checklist you can implement today. It takes less than an hour and it covers the critical attack surfaces.
- Audit your .npmrc, .pypirc, and other credential files for stored tokens
- Enable filesystem permissions on all credential files (read-only for your user)
- Create scoped tokens with minimum required permissions
- Set expiration dates on all tokens
- Review GitHub Actions workflow permissions and reduce where possible
- Implement OIDC token validation in your CI/CD pipelines
- Set up basic file integrity monitoring on your home directory
- Create a token rotation schedule and stick to it
Each item on this list addresses a specific vulnerability. None of them require expensive tools or dedicated security staff. They just require awareness and discipline.
The Bigger Picture
Security hardening your developer environment is not about fear. It is about understanding that your credentials are valuable, and they are easy targets. Attackers spend their time looking for the path of least resistance. Right now, that path goes through your .npmrc file.
The good news is that closing that path is straightforward. You do not need to overhaul your entire development workflow. You just need to treat your credentials with the same respect you would give your production secrets.
Start with the basics. Check your credential files. Lock down permissions. Rotate your tokens. Review your CI/CD configurations. These steps take minimal time and they significantly reduce your attack surface.
Your development environment is your first line of defense. Make it count.
