Full Report
Addressing a surge in package registry attacks, GitHub is strengthening npm's security with stricter authentication, granular tokens, and enhanced trusted publishing to restore trust in the open source ecosystem. The post Our plan for a more secure npm supply chain appeared first on The GitHub Blog.
Analysis Summary
# Best Practices: Securing the npm Software Supply Chain
## Overview
These practices are a direct response to increased package registry attacks (like account takeovers and malware injection via package maintenance), focusing on hardening authentication, restricting token usage, and promoting secure publishing methods within the npm ecosystem.
## Key Recommendations
### Immediate Actions
1. **Implement Mandatory 2FA for Publishing:** Immediately configure package publishing and settings modification on all accounts and organizations to **require Two-Factor Authentication (2FA)** for all write and publication actions.
2. **Migrate 2FA to FIDO Standard:** Begin the process to **migrate existing Time-based One-Time Password (TOTP) 2FA setups to FIDO-based 2FA** (e.g., WebAuthn), as TOTP is targeted for deprecation.
3. **Adopt Trusted Publishing:** Immediately prioritize the transition to **npm Trusted Publishing** for all automated build and deployment processes to eliminate the need to store static API tokens in CI/CD systems.
### Short-term Improvements (1-3 months)
1. **Deprecate Legacy Tokens:** Systematically review and **deprecate all legacy "classic tokens"** currently in use across workflows, replacing them with short-lived, granular tokens or trusted publishing mechanisms.
2. **Audit Token Granularity and Lifetime:** For any remaining granular tokens, ensure they are configured with the **shortest possible lifetime** (planned default will be seven days) and strictly limit publishing permissions to only necessary scopes.
3. **Restrict Token Default Access:** Configure publishing access settings to **disallow tokens by default**, requiring maintainers and automation to explicitly opt-in to token usage via 2FA-enforced local publishing or trusted publishing.
### Long-term Strategy (3+ months)
1. **Fully Enforce 2FA for Local Publishing:** Establish policies ensuring that any *local* package publishing that does not use Trusted Publishing requires mandatory 2FA enforcement, **removing the option to bypass 2FA** for such activities.
2. **Expand Trusted Publishing Providers:** Continuously monitor and integrate support for **expanded eligible providers** for trusted publishing to maximize pipeline security coverage across different CI/CD platforms.
3. **Maintain Vigilance Against IoCs:** Establish automated monitoring or scanning processes to routinely check for **Indicators of Compromise (IoCs)** related to known malware strains (like those found in recent attacks) within your imported dependencies and codebase.
## Implementation Guidance
### For Small Organizations
- Focus exclusively on **enabling FIDO-based 2FA** on all developer accounts immediately.
- Switch all CI/CD workflows to use **npm Trusted Publishing** as the primary method for publishing packages, which simplifies secret management.
- If publishing locally, ensure all maintainers follow the strict **2FA requirement** for every publish operation.
### For Medium Organizations
- Develop a **migration plan** to sunset all classic npm tokens within the next quarter, prioritizing high-risk repositories first.
- Implement **mandatory publishing configuration checks** within your repository governance rules, ensuring all published packages belong to registries or accounts requiring 2FA.
- Document and socialize the **security benefits of FIDO over TOTP** for developers to encourage rapid adoption of the superior 2FA method.
### For Large Enterprises
- Establish a **policy for token lifespan limits** across the organization. Even when short-lived tokens are necessary, enforce maximum expirations well below the new default.
- Integrate **supply chain security scanning tools** capable of identifying known malicious patterns (IoCs) injected into dependencies post-install (e.g., malicious post-install scripts).
- Create **dedicated support and documentation channels** to manage the organizational transition away from deprecated TOTP and classic tokens, offering migration guides for internal tooling pipelines.
## Configuration Examples
*Note: Specific command syntax is evolving based on GitHub's rollout plan, but the security posture should adhere to these concepts.*
| Feature | Configuration Best Practice |
| :--- | :--- |
| **2FA Method** | Set default/preferred 2FA method to **WebAuthn (FIDO)**. |
| **Token Limit** | Ensure any generated publishing token is granted a maximum lifetime of **7 days**. |
| **Publishing**| Default CI/CD publishing mechanism: **Trusted Publisher configuration**, bypassing token authentication entirely. |
| **Account Settings** | Enforce a blanket setting disallowing the **bypass of 2FA** for direct account actions (e.g., setting package access). |
## Compliance Alignment
- **NIST SP 800-63B (Digital Identity Guidelines):** Adopting FIDO-based authentication directly supports the higher assurance levels defined for verifying identity and binding authentication factors.
- **ISO/IEC 27001 (Information Security Management):** Implementation of stricter access controls (2FA) and cryptographic measures (FIDO) aligns with A.9 (Access Control) and A.14 (System acquisition, development and maintenance).
- **OpenSSF Supply Chain Levels for Software Artifacts (SLSA):** Trusted publishing directly contributes to achieving higher SLSA provenance levels by securely linking build artifacts to the source code without relying on long-lived secrets.
## Common Pitfalls to Avoid
1. **Ignoring the Deprecation Timeline:** Failing to proactively migrate away from TOTP and classic tokens, leading to unexpected workflow breaks when deprecated features are fully removed.
2. **Over-scoping Remaining Tokens:** Granting existing granular tokens unnecessary permissions (especially broad publication rights), increasing the blast radius if the token is compromised.
3. **Relying on Local Bypass:** Intentionally seeking or allowing exceptions to enforce 2FA for local package maintenance, reintroducing the risk of session hijacking or compromised credentials.
## Resources
- npm documentation on **Requiring 2FA for package publishing and settings modification**.
- npm documentation on **Configuring Two-Factor Authentication (using WebAuthn/FIDO)**.
- OpenSSF documentation on **Trusted Publishers for all package repositories**.