In the last few weeks, we have seen campaigns that turned everyday developer workflows into credential harvesters and worm carriers. The Nx “s1ngularity” incident scraped local machines and CI environments for tokens. GhostAction quietly injected malicious workflows that exfiltrated thousands of secrets. Shai-Hulud, a self-replicating worm, spread through compromised maintainer accounts and post-install hooks. Attackers targeted the core of secure systems: credentials and access rights. 

GitHub, which owns npm, responded with a plan to harden the registry to prevent similar attacks in the future. The changes focus on who can publish, how they authenticate, and how long credentials remain valid. Two-factor authentication is becoming a hard requirement as are granular tokens with very short lifetimes. Trusted Publishing, which uses OpenID Connect (OIDC) rather than stored tokens, is being promoted as the default path. 

While the policy changes are aimed at npm publishers, the logic behind them applies to every developer and every team, even if you never push a package to a public registry. If you write code, run CI, or hold the keys to deploy, these are lessons worth adopting.

WebAuthn/FIDO 2FA For Any Account With Write Access

Passwords, combined with one-time codes, were once considered safe enough, but phishing kits and prompt-bombing have eroded their value. GitHub now recommends moving critical accounts to phishing-resistant authentication. 

WebAuthn based authentication binds the login to the site origin and the specific device, which makes common attacks fail by design. When an attacker cannot trick you into approving a code on the wrong domain, they cannot take over your session and publish malware under your name. That same protection matters anywhere an account can change code, pipelines, or releases.

Look across your environment for any identity that can write to a repository, configure CI, or promote a build. This is not about blaming users for clicking the wrong link. It is about removing the chance that a link can ever work, just as GitHub is doing to protect npm’s publishing surface. The goal is to raise the floor so that normal mistakes do not become global incidents.

Remove Long-Lived Secrets From Automation

Shai-Hulud and GhostAction both thrived in places where credentials were accessible in code. If a token sits in a repo, malware only needs a single execution path to read it, copy it, and use it later. Trusted Publishing recommends avoiding the storage of long-lived tokens for automation and instead using short-lived identity assertions that are minted at runtime via OIDC. The workflow requests a scoped credential from the identity provider, the registry verifies the claim, and the credential expires quickly. There is nothing static to steal from a log, a cache, or a misconfigured step.

Even if you never publish to npm, you can bring this model to cloud deployments, artifact uploads, and internal registries. 

Replace static API keys in CI with OIDC roles or exchange mechanisms offered by your platform of choice. Audit pipelines for steps that echo environment variables or write logs that might capture sensitive values. If an attacker compromises a single job or steals a workspace snapshot, there should be nothing reusable in it a day later, or maybe even an hour later. 

Adopt Short-lived Credentials With Fine-Grained Permissions

GitHub’s plan emphasizes granular scopes and aggressive expiration, including a maximum lifespan of seven days for publishing tokens. 

If a credential can do only one thing, for a short time, an attacker who steals it can only do that one thing, for that short time. Compare that to a classic token with broad scopes and no expiry, which becomes a skeleton key that opens the door until someone finally notices. The recent attacks show how fast a stolen secret can become an ecosystem-wide problem. Short lifetimes and narrow scopes cut the blast radius dramatically. 

When you create an access token or service credential, ask what the minimum viable scope can be. Give it only that. 

Set the expiry as low as your automation can tolerate, then tune down as your process matures. Where possible, choose credentials that expire automatically without any human remembering to rotate them. Failing that, schedule rotation on a calendar so that the work is completed before an incident forces it. 

Each reduction in lifetime and scope is a slice off the risk surface, and those slices add up.

Deny-By-Default And Explicit Authorization For Sensitive Actions

Configuration creep is very real. Over time, teams add exceptions sometimes, and those exceptions almost always become the new baseline. 

GitHub is removing the option to bypass 2FA for local package publishing and making the secure path the default one. If tokens are disallowed by default for publishing, you have to opt in with intent and justification. If local publishing requires multifactor authentication every time, there is no silent side door for a compromised password. Defaults are powerful because they are the path of least resistance. Good defaults give you a safety net even on a busy day.

You can also apply this same principle to your work. Set repository rules that require reviews on protected branches. Make administrative actions explicit, traceable events with human approval. Remove legacy settings that allow “just this once” behavior. When an exception is needed, make it temporary with an automatic end date. 

Auditors and responders can then see when something unusual happened because it stands out from the default posture.

How GitGuardian Can Help

You cannot move to short-lived, granular credentials if long-lived keys are still hiding in repos, branches, or build scripts. GitGuardian’s Secrets Detection gives you a clean inventory, including history, so you can remove the skeleton keys attackers love. That means fewer surprises when you flip pipelines to OIDC or start enforcing WebAuthn for writes. You get a baseline, then a way to prove things stayed clean as teams ship.

Treat Release Rights As First-Class Identities

Build and release are powers, not just steps. GitGuardian’s NHI Governance helps you map the workflows and service accounts that can create artifacts, push images, or publish packages. Each non-human identity (NHI) has an intended path and a scope you can explain, mapping to the creator of each identity. Monitoring ties those identities to events, so you can answer who published what, from where, and with which claim. During campaigns like GhostAction, many teams had to build that picture from logs after the fact. With governance in place, you can answer in minutes, not days.

Plant Quiet Tripwires Where Attackers Look

While you migrate to short-lived credentials, GitGuardian Honeytoken can help you buy peace of mind. Place these decoy secrets in places that malware sweeps. If anything tries to use one, you get a high-fidelity signal that something crossed a boundary. That helps you isolate runners, rotate real keys, and review recent publishes with confidence. 

Triage In Plain Language

Incidents create questions that need immediate answers. Logging into and clicking through multiple consoles slows everyone down. GitGuardian’s incident view and natural-language assisted triage enable analysts to request high-severity findings that involve tokens visible in public, tied to workflows with publish rights, within a specified time window. You get structured, filterable results without having to manually search. Developers can quickly be informed about what to fix, and security teams can easily track those changes. 

Everyone moves faster with the same picture.

Bringing npm’s Lessons Into Every Environment

The underlying logic of all of the changes that GitHub has planned for npm publishers reduces standing privilege, shortens the lifetime of power, and makes sensitive actions explicit. You can apply the same logic everywhere you build and release: 

• Map the workflows and service accounts that can create artifacts, push images, or publish packages. 
• Add monitoring that ties identities to events, so you can answer who published what, from where, and with which claim. 
• Remove long-lived secrets from automation and replace them with OIDC exchanges. 
• Default to WebAuthn for any account with write access. 
• Issue least-privilege, short-lived credentials and rotate them as often as feasible. 
• Set deny-by-default so exceptions are temporary and visible. 

Each step you take cuts a slice off the risk surface and makes a stolen token less useful.

GitGuardian can help you see what you really have, govern non-human identities, catch quiet misuse, and triage in the language your team speaks. The goal is not a single perfect control, but instead getting to a posture where normal work stays fast while the power to publish and deploy is precise, short-lived, and owned. Make sure one compromised key does not become a platform-wide or ecosystem-wide problem.

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Take Control of Your Secrets Security authored by Dwayne McDaniel. Read the original post at: https://blog.gitguardian.com/security-lessons-npm-publishing/