GitHub’s npm security changes add several layers rather than one attack-proof switch: trusted publishing can remove long-lived publish tokens from supported CI/CD workflows, staged publishing adds a human approval step, npm v12 makes install-time scripts and certain dependency builds opt-in, and Dependabot’s three-day package cooldown slows routine uptake of new releases. Maintainers should also review token permissions and prepare for a planned January 2027 change to direct publishing with bypass-2FA granular tokens.
What GitHub changed and why it matters
In its July 28, 2026 update, GitHub described attacks that target package registries and CI/CD systems to distribute malware and steal credentials. The measures address different stages of that chain: obtaining credentials, publishing without authorization, executing code during installation, spreading a newly released package quickly, and responding after suspicious activity is found.
GitHub tied its security roadmap to the Shai-Hulud worm, which entered npm through compromised maintainer accounts and malicious post-install scripts. GitHub said it removed more than 500 compromised packages and blocked uploads containing known indicators of compromise in 2025. In 2026, GitHub said more than 30,000 packages are published each day and that hundreds of newly published packages contain malicious code daily. Those are GitHub’s figures; they describe the scale it cited, not an independently established incident rate.
The practical implication is that no one setting replaces the others. A token-free publishing workflow does not prevent unsafe code from running when a dependency is installed; install-time restrictions do not prevent an attacker from taking over a maintainer account. Treat the controls as layers.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →#1 Best Overall
How the protections differ
| Control | What it changes | Human approval | Credential or workflow trade-off |
|---|---|---|---|
| Trusted publishing | Authorizes a supported CI/CD publisher without a long-lived registry credential. | No separate publication approval is described as inherent to trusted publishing. | Removes stored publish tokens from the supported publishing path; requires configuring a supported identity provider and registry workflow. |
| Staged publishing | Holds an npm package until an additional approval and 2FA step in the npm CLI or npmjs.com. | Yes; the release is not published until that step. | Adds a deliberate release gate; no universal setup path or workflow migration effort is specified. |
| npm v12 install-time restrictions | Makes lifecycle scripts, implicit node-gyp builds, Git dependencies, and remote URL dependencies opt-in. |
Maintainers review and approve trusted scripts; the resulting allowlist can be committed in package.json. |
May require compatibility work and explicit approval for packages that rely on scripts or those dependency types. |
| Dependabot package cooldown | Waits until a release has been available for at least three days before opening a version-update pull request. | Normal pull-request review remains relevant; the cooldown itself is not an approval mechanism. | Slows routine version updates; security updates still open immediately. |
| Interactive 2FA and token controls | Limits token-based administration and reduces the exposure of write-enabled tokens. | Interactive 2FA is required for the sensitive actions covered by GitHub’s July 31, 2026 changelog. | Requires maintainers to replace or adjust automation that depends on bypass-2FA tokens for sensitive actions or direct publishing. |
Move npm publishing away from long-lived tokens
Use trusted publishing where your CI/CD provider is supported
Trusted publishing authorizes publication without storing a long-lived npm credential in a workflow. GitHub’s supply-chain guidance describes support across npm, PyPI, NuGet, RubyGems, Crates, and other registries. npm added CircleCI support in April 2026. Confirm that your registry and CI/CD provider are supported, then configure the trusted-publishing identity for the package and workflow you intend to use. GitHub also says it creates a signal when a package stops using trusted publishing, which can help flag an unexpected change in publishing practice.
This is the strongest default for supported automation because it removes the stored publish token from that publishing path. It does not remove the need to secure the CI/CD workflow itself: a compromised workflow can still misuse the authority available to it.
Use staged publishing if a human release gate is needed
npm staged publishing, shipped in May 2026, holds a package until an additional approval and 2FA step is completed in the npm CLI or on npmjs.com. This separates the credentials used by CI/CD from the final registry publication decision. It is useful when a team wants an explicit human check before a package becomes available, but it adds a release step that must be incorporated into the team’s process.
Replace legacy and long-lived tokens
GitHub’s 2025 rollout revoked legacy classic npm tokens and set a seven-day default expiration for new write-enabled granular npm tokens. The seven-day period is the default lifetime for those new tokens, not a claim that every existing token expires on that schedule. GitHub also disabled new TOTP setup as part of that rollout and encouraged trusted publishing.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →On July 31, 2026, GitHub said bypass-2FA granular tokens could no longer perform sensitive account, organization, or package-management actions without interactive 2FA. GitHub has targeted January 2027 for removing direct publishing by those tokens. If an automated workflow still relies on such a token to publish, plan to move it to trusted publishing or staged publishing ahead of that change. Use interactive 2FA for account and governance actions rather than designing automation around a bypass.
What npm v12 changes during installation
Generally available in July 2026, npm v12 makes lifecycle scripts such as preinstall, install, and postinstall opt-in. Implicit node-gyp builds, Git dependencies, and remote URL dependencies are opt-in as well. This reduces the amount of dependency code that can run automatically during installation, including the kind of post-install execution used in the Shai-Hulud attacks.
For packages whose scripts are trusted, maintainers can review and approve them with npm approve-scripts --allow-scripts-pending and commit the generated allowlist in package.json. Review the allowlist rather than treating approval as a formality: approving a script permits it to run for the project. Teams should test their dependency installation and build process after adopting v12, since projects that rely on lifecycle scripts or the newly restricted dependency types may need explicit approvals or compatibility changes.
Use the Dependabot cooldown without delaying security fixes
Dependabot version updates now wait until a package release has been available for at least three days before opening a pull request. This creates time for problems in a newly published release to become visible before a routine update is proposed. It is a delay on version updates, not a blanket pause on Dependabot activity: security updates still open immediately.
Best Value
Enable Dependabot and keep reviewing its security updates promptly. The cooldown is a buffer against immediate adoption of a problematic release, not a substitute for assessing a proposed dependency change.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Harden GitHub Actions and prepare to respond
Reduce exposure in workflow definitions
- Pin third-party GitHub Actions to full commit SHAs rather than movable version tags.
- Avoid using
pull_request_targetto run untrusted code. - Review workflow expressions and commands for unsafe interpolation of user-controlled input.
These steps address risks in the automation environment itself. They complement registry-side controls: trusted publishing can eliminate a stored npm token, but it cannot make an unsafe workflow safe.
Watch outbound traffic and revoke credentials quickly
GitHub’s Actions network firewall is in technical preview and logs outbound traffic, giving teams a way to look for unexpected downloads or possible credential exfiltration. GitHub has also added self-service enterprise credential revocation and expanded its revocation API to GitHub OAuth and App tokens. These detection and response options matter when preventive controls fail: suspicious network activity can be investigated, and affected credentials can be revoked.
Quick Recap
Maintainer migration checklist
- Inventory publishing paths. Identify packages and workflows that publish to npm, the credentials they use, and whether their CI/CD provider supports trusted publishing.
- Replace stored publish tokens where possible. Configure trusted publishing for supported workflows. If a human must authorize releases, evaluate npm staged publishing and add its approval and 2FA step to the release process.
- Remove unsafe token dependencies. Stop using bypass-2FA tokens for sensitive account, organization, or package administration. Find any direct-publishing workflow that depends on one and migrate it before GitHub’s January 2027 target.
- Test npm v12 installation behavior. Check which dependencies need lifecycle scripts, implicit
node-gypbuilds, Git sources, or remote URL sources. Approve only the scripts the project trusts and commit the generated allowlist inpackage.json. - Review Actions security. Pin third-party actions to full commit SHAs, avoid running untrusted code through
pull_request_target, and inspect user-input interpolation. - Keep dependency updates moving safely. Enable Dependabot, use the package cooldown for version updates, and continue to monitor security updates, which are not held for the three-day cooldown.
- Strengthen maintainer authentication. Consider a FIDO2 security key for phishing-resistant authentication, consistent with GitHub’s FIDO-based 2FA direction.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
