29.2: Package Registry Security Improvements¶

Package registries sit at the center of the software supply chain, serving billions of downloads daily and determining what code actually runs in production systems. For years, these registries operated with minimal security controls—anyone could create an account, publish packages, and reach millions of developers with a single command. The wave of supply chain attacks exploiting this openness has driven a fundamental transformation in registry security, with major registries implementing controls that would have seemed impractical just a few years ago.

The improvements happening across npm, PyPI, Maven Central, RubyGems, and other registries represent more than isolated responses to individual incidents. Registries are learning from each other, coordinating through OpenSSF working groups, and converging on a common security baseline that raises standards across the entire ecosystem. Understanding these improvements helps developers take advantage of new security features and anticipate requirements that will become mandatory.

npm Registry Security¶

npm, the JavaScript package registry, serves as the largest package ecosystem with over 2 million packages and billions of weekly downloads. Its scale makes it both a prime target for attackers and a critical leverage point for improving ecosystem security.

Provenance attestations:

npm launched provenance attestations in April 2023,¹ enabling packages to include cryptographic proof of their build origin. When a package is built through a supported CI/CD system and published with provenance, npm records:

• The source repository where the code lives
• The specific commit that was built
• The build platform and workflow that produced the package
• A Sigstore signature binding these claims

Provenance addresses supply chain attacks where attackers publish malicious packages that don't match their claimed source repositories. Users can verify that a package was actually built from the repository it claims to come from.

Provenance is visible on the npm website (look for the "Provenance" section on package pages) and verifiable through the npm CLI:

npm audit signatures

Trusted publishing:

npm's trusted publishing uses OIDC federation to eliminate the need for long-lived npm tokens in CI/CD systems. When publishing through trusted publishing, npm can automatically generate provenance attestations that record the build identity. Instead of storing npm credentials as repository secrets, workflows authenticate using the CI platform's identity:

# GitHub Actions workflow with trusted publishing
jobs:
  publish:
    permissions:
      id-token: write
    steps:

      - uses: actions/setup-node@v4

        with:
          registry-url: 'https://registry.npmjs.org'

      - run: npm publish --provenance --access public

This approach eliminates a major attack vector: compromised npm tokens stored in CI/CD secrets. The workflow identity is tied to the specific repository and workflow, making unauthorized publishing from stolen credentials impossible.

Enhanced authentication:

npm has progressively strengthened authentication requirements:²

• December 2021: Enhanced login verification rollout begins
• February 2022: Mandatory 2FA for maintainers of top-100 packages
• May 2022: Extended mandatory 2FA to top-500 packages, then all high-impact packages
• September 2025: Following the Shai-Hulud worm attack, npm announced major security overhaul
• November 2025: New TOTP 2FA configurations disabled; shift to phishing-resistant FIDO-based authentication (WebAuthn/passkeys)

npm now strongly encourages WebAuthn/passkeys over TOTP authenticator apps. As of late 2025, new TOTP configurations are disabled—existing TOTP setups continue working but are being phased out in favor of phishing-resistant options. This shift was accelerated by the Shai-Hulud attack, where phishing campaigns targeting maintainers demonstrated TOTP's vulnerability to real-time credential theft.

Token management overhaul (2025):

npm implemented sweeping changes to token management in late 2025:³

• November 5, 2025: Classic token creation disabled; granular tokens capped at 90-day maximum lifetime
• December 9, 2025: All existing classic tokens permanently revoked

Granular access tokens with write permissions now enforce a 7-day default expiration and 90-day maximum lifetime (previously unlimited). The npm login command now issues 2-hour session tokens instead of long-lived credentials, with 2FA enforced for all publishing operations.

These changes eliminate a primary attack vector: long-lived tokens stored in CI/CD systems or on developer machines. Organizations must migrate to trusted publishing (OIDC) or implement frequent token rotation.

Malware detection:

npm operates malware detection systems that scan packages upon publication. The registry removes malicious packages upon detection, though the cat-and-mouse nature of malware detection means some malicious packages remain discoverable for periods before removal.

The security team responds to reports through the npm security reporting mechanism and coordinates with the broader security community on emerging threats.

The Shai-Hulud attack (2025):

The September 2025 Shai-Hulud worm attack demonstrated the consequences of compromised maintainer accounts at scale.⁴ This self-replicating malware spread through the npm ecosystem by:

1. Compromising maintainer credentials through phishing campaigns spoofing npm 2FA update notifications
2. Using stolen npm tokens to authenticate as the compromised developer
3. Identifying other packages maintained by that developer
4. Injecting malicious code and publishing new versions automatically
5. Harvesting credentials from infected systems to continue spreading

The attack compromised over 500 packages before containment. A second wave (Shai-Hulud 2.0) hit in November 2025, affecting nearly 800 additional packages. CISA issued emergency guidance recommending organizations rotate all developer credentials and mandate phishing-resistant MFA.

The attack directly catalyzed npm's aggressive security timeline, demonstrating that TOTP-based 2FA and long-lived tokens were insufficient against sophisticated, automated attacks.

PyPI Security Improvements¶

The Python Package Index (PyPI) has implemented substantial security improvements, many enabled by funding from organizations like Google and support from the Python Software Foundation.

Trusted Publishers:

PyPI launched Trusted Publishers in April 2023,⁵ enabling OIDC-based publishing without API tokens. Trusted Publishers support publishing from:

• GitHub Actions
• GitLab CI/CD
• Google Cloud Build
• ActiveState

To configure Trusted Publishers:

1. Navigate to your project on PyPI
2. Go to "Publishing" settings
3. Add a trusted publisher specifying the repository and workflow

Once configured, your CI workflow can publish without stored credentials:

# GitHub Actions workflow with PyPI Trusted Publishers
jobs:
  publish:
    permissions:
      id-token: write
    steps:

      - uses: pypa/gh-action-pypi-publish@release/v1

Trusted Publishers have seen rapid adoption since launch, with thousands of projects configuring OIDC-based publishing.

Attestations:

In November 2024, PyPI launched attestation support using Sigstore,⁶ enabling publishers to include cryptographic attestations with packages. Attestations provide:

• Digital signature binding packages to their build environment
• Verification that packages were built through expected processes
• Audit trail of package publishing events

Attestations complement Trusted Publishers—Trusted Publishers control who can publish; attestations provide verifiable evidence of how packages were published. PyPI exposes these attestations through its Integrity API and web UI so installers and security tools can verify them.

2FA requirements:

PyPI has progressively expanded 2FA requirements:⁷

• 2022: Enabled 2FA option for all accounts; began requiring 2FA for critical projects in July 2022
• 2023: Continued expansion of 2FA requirements
• January 2024: Required 2FA for all PyPI accounts

PyPI supports TOTP authenticators, WebAuthn security keys, and recovery codes. The registry recommends hardware security keys for highest-impact maintainers.

Malware detection improvements:

PyPI has invested in improved malware detection capabilities, including:

• Automated scanning of newly published packages
• Integration with security research community for threat intelligence
• Faster response to malware reports
• Rate limiting and anomaly detection for publishing

The registry has removed thousands of malicious packages in recent years, though the true number of malicious publication attempts is likely higher.

Organization accounts:

PyPI's organization accounts feature (launched 2023) enables organizations to manage package ownership collectively rather than through individual maintainer accounts. This addresses the risk of packages becoming orphaned when individual maintainers leave organizations.

Continued hardening in 2026:

PyPI's security investment has continued on several fronts. In April 2026, PyPI completed its second external security audit—funded by the Sovereign Tech Agency and performed by Trail of Bits—following its first audit in 2023.⁸ The same month, PyPI published a detailed incident report on the LiteLLM and Telnyx supply chain attacks with concrete guidance for maintainers, continuing its practice of transparent post-incident communication.⁹ And in July 2026, PyPI began rejecting new file uploads to releases older than 14 days,¹⁰ closing an attack path in which a compromised publishing token could quietly add malicious files (such as wheels for additional platforms) to an old, already-trusted release without changing the version number.

Maven Central Security¶

Maven Central, the primary repository for Java and JVM ecosystem packages, has historically maintained strict publishing requirements including PGP signing. Recent improvements build on this foundation with modern attestation capabilities.

Existing security controls:

Maven Central has long required:

• PGP signing: All artifacts must be signed with PGP keys
• Namespace verification: Publishers must verify ownership of their namespace (group ID)
• Immutable artifacts: Published artifacts cannot be modified or deleted
• Checksum verification: SHA-1 and MD5 checksums for all artifacts

These requirements have made Maven Central more resistant to certain attack classes than registries that historically lacked signing requirements.

Sigstore adoption:

Maven Central has been integrating Sigstore support to complement existing PGP signing:

• Sigstore signatures can be published alongside PGP signatures
• Build tools are adding Sigstore verification capabilities
• The transition provides modern keyless signing without abandoning existing PGP infrastructure

Improved verification:

Sonatype, which operates Maven Central, has enhanced verification processes:

• Automated scanning for known malware patterns
• Detection of typosquatting attempts
• Improved namespace verification to prevent impersonation
• Better tooling for maintainers to manage credentials

Build verification:

Maven and Gradle ecosystems have been improving build verification capabilities:

• Dependency verification in Gradle (checksums and signatures)
• Maven verification plugins
• Better integration with SLSA provenance

<!-- Maven checksum verification -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <executions>
    <execution>
      <goals><goal>enforce</goal></goals>
      <configuration>
        <rules>
          <requireFilesExist>
            <files>
              <file>${project.build.directory}/dependency-checksums.sha256</file>
            </files>
          </requireFilesExist>
        </rules>
      </configuration>
    </execution>
  </executions>
</plugin>

RubyGems Security¶

RubyGems, the Ruby package registry, has implemented significant security improvements following several high-profile supply chain incidents.

MFA enforcement:

RubyGems launched progressive MFA enforcement beginning in 2022:

• August 2022: Required MFA for owners of gems with over 180 million downloads (approximately top 100);¹⁶ warning prompts begin at 165 million downloads
• 2023: Continued expansion to additional gem maintainers
• UI-level enforcement: Prompts for MFA configuration at login

MFA requirements apply to gem push operations, not just account access, ensuring that stolen session cookies cannot be used to publish malicious updates.

WebAuthn support:

RubyGems added WebAuthn (hardware security key) support, providing phishing-resistant authentication. WebAuthn provides stronger protection than TOTP-based 2FA because authentication requires physical presence of the registered device.

API key improvements:

RubyGems enhanced API key security:

• Scoped API keys limiting permissions to specific gems
• Key expiration settings
• Improved key management interface
• Audit logging for key usage

Scoped keys enable publishing automation while limiting exposure if credentials are compromised.

Trusted publishing:

RubyGems supports OIDC-based trusted publishing from GitHub Actions, allowing configured workflows to obtain short-lived, gem-scoped publishing tokens without storing long-lived API keys in CI/CD secrets.

Malware response:

RubyGems has improved malware detection and response capabilities:

• Automated scanning for suspicious patterns
• Community reporting mechanisms
• Faster response to security reports
• Yanking capabilities for malicious gems

The security team coordinates with the broader Ruby community on threat intelligence and incident response.

Cross-Registry Coordination¶

Package registries increasingly coordinate on security improvements through formal and informal channels.

OpenSSF Securing Software Repositories Working Group:

The OpenSSF Securing Software Repositories Working Group brings together registry operators to share learnings and coordinate approaches:

• npm, PyPI, RubyGems, and other registries participate
• Working group develops shared guidance and specifications
• Registries learn from each other's security implementations
• Coordinated disclosure for cross-registry vulnerabilities

Shared approaches:

Registries have converged on common patterns:

Shared infrastructure:

Registries increasingly use shared security infrastructure:

• Sigstore provides signing and transparency infrastructure across registries
• OpenSSF Package Analysis scans multiple registries
• Shared threat intelligence on malicious packages
• Common formats for provenance and attestations

Cross-registry learnings:

Security improvements often spread across registries:

• npm's provenance approach influenced PyPI's attestation design
• PyPI's Trusted Publishers informed npm's OIDC implementation
• RubyGems' MFA enforcement patterns were adopted by other registries

This cross-pollination accelerates ecosystem-wide improvement.

Beyond Package Registries: IDE Extension Marketplaces and CI/CD Platforms¶

The registry security improvement pattern is extending beyond traditional package registries to adjacent distribution channels:

IDE Extension Marketplaces:

The Eclipse Foundation's January 2026 announcement of pre-publish security checks for Open VSX represents the extension marketplace ecosystem adopting the same "shift left" trajectory that package registries followed. The initiative was catalyzed by the GlassWorm incidents (October 2025 self-propagating worm; January 2026 publisher credential compromise) and commits to quarantining suspicious uploads before publication, with staged enforcement beginning March 2026.¹¹ This mirrors the pattern seen across npm and PyPI, where high-profile incidents drove mandatory security controls.

GitHub Actions Supply Chain Controls:

GitHub expanded action allowlisting to all plan tiers in February 2026, enabling any organization to restrict which third-party actions can execute in their workflows.¹² Combined with the introduction of the runner scale set client (preview), which provides a non-Kubernetes path to custom runner autoscaling, these controls reduce exposure to compromised upstream actions — a recurring attack vector demonstrated by the tj-actions/changed-files compromise and the Shai-Hulud GitHub Actions campaign.

GitHub also introduced Dependabot OIDC authentication¹³ in February 2026, enabling OIDC-based authentication for dependency update automation and reducing static secret use in Dependabot configurations. Complementing this, new audit log events for Dependabot configuration changes improve forensic traceability for dependency update automation.

In July 2026, GitHub described a coordinated set of measures—rolled out across npm, GitHub Actions, and Dependabot between April and July 2026—explicitly organized around the phases of a supply chain attack.¹⁴ To prevent initial compromise, npm now places high-impact accounts in a 72-hour read-only mode after risky account events such as email changes or 2FA recovery code use, and actions/checkout gained safer defaults against untrusted fork code execution. To protect credentials, CircleCI joined the trusted publishing providers, and an Actions network firewall (technical preview) logs outbound traffic for anomaly detection. To block propagation, npm introduced staged publishing requiring an additional 2FA approval before a package goes live, npm v12 disables install scripts by default, and Dependabot adopted a three-day default cooldown before opening non-security version-update pull requests. For incident response, GitHub expanded self-service and API-based credential revocation to cover OAuth and GitHub App tokens. Taken together, the changes directly answer the attack techniques of the preceding year: install-script malware, account takeover after recovery-flow abuse, and worm-speed propagation through automated updates.

Some researchers argue these measures, while valuable, still treat symptoms of a structural design choice. Andrew Nesbitt observes that language registries are "unstable by default": any authenticated publisher can push any version at any time, the index updates within seconds, and resolvers pick up new versions immediately—the equivalent of running Debian's sid unstable branch in production, except that language ecosystems offer no stable channel to choose instead.¹⁵ Client-side cooldowns push the integration burden onto every individual consumer; the registry-level alternative—separate release channels where new versions reside for a defined period before promotion, as the community registry gem.coop has implemented with a 48-hour channel—would apply the testing-to-stable promotion model Linux distributions have operated for decades. Whether major registries adopt channel semantics remains an open question, but the direction of travel (cooldowns, staged publishing, quarantine-before-publication) suggests convergence toward exactly that model.

These improvements reflect a broader convergence: the same security principles driving package registry hardening (eliminate long-lived credentials, verify identity, enforce allowlists, log everything) are being applied to the CI/CD and developer-tooling layer.

Emerging Common Baseline¶

A common security baseline is emerging across major registries—one that closely aligns with the OpenSSF OSPS Baseline. The OSPS Baseline formalizes many of the security controls registries are now requiring, providing a unified framework that maps to regulatory requirements like the EU Cyber Resilience Act and NIST SSDF.

Authentication (OSPS-AC-01):

• Multi-factor authentication for all maintainers
• Hardware security key support
• Phishing-resistant options (WebAuthn)

Publishing (OSPS-BR-01 through BR-06):

• OIDC-based trusted publishing
• Elimination of long-lived tokens in CI/CD
• Scoped credentials with minimal permissions

Transparency (OSPS-BR-06, OSPS-QA-02):

• Sigstore-based signing and transparency logs
• Provenance attestations linking packages to source
• Publicly verifiable build origins

Verification:

• Checksum verification by default
• Signature verification capabilities in package managers
• Tooling for verifying provenance and attestations

Malware defense:

• Automated scanning at publication
• Community reporting mechanisms
• Rapid response capabilities

This baseline represents expectations that all major registries will meet within the next few years, with leading registries already implementing most capabilities. Organizations can use the OSPS Baseline to assess registry security practices and set expectations for package management security.

Timeline of Improvements¶

Key milestones in registry security:

The pace of improvement has accelerated significantly since 2021, driven by high-profile incidents—most notably the 2025 Shai-Hulud attacks—and coordinated investment.

Developer Actions¶

Developers should take advantage of new registry security features:

For all developers:

1. Enable 2FA on all package registry accounts using hardware security keys if possible
2. Verify package provenance using npm audit signatures or equivalent
3. Update tools to versions supporting verification features
4. Monitor for security requirements that may become mandatory

For package maintainers:

1. Configure Trusted Publishers to eliminate stored credentials:
2. npm: Configure provenance in GitHub Actions
3. PyPI: Set up Trusted Publishers in project settings
4. RubyGems: Configure trusted publishers for GitHub Actions releases

5. Plan for OIDC publishing as it becomes available on other registries

6. Enable strongest authentication available:

7. Register hardware security keys
8. Remove or scope down API tokens

9. Enable audit logging where available

10. Publish with provenance:

# npm with provenance
npm publish --provenance

# PyPI with attestations (via Trusted Publishers)
# Happens automatically with gh-action-pypi-publish

1. Review organization account options for team-maintained packages

For organizations:

1. Inventory registry accounts used by your organization
2. Enforce 2FA requirements for all maintainer accounts
3. Migrate to trusted publishing for all CI/CD pipelines
4. Monitor registry security announcements for new requirements
5. Verify provenance in your dependency management processes

Recommendations¶

We recommend the following actions to take advantage of registry security improvements:

1. Enable hardware security key 2FA on all registry accounts immediately—this provides the strongest protection against account compromise

2. Migrate to trusted publishing (OIDC-based) for all packages you maintain, eliminating long-lived credentials from CI/CD systems

3. Publish with provenance enabled on npm and PyPI, providing verifiable build origins for your packages

4. Verify provenance for critical dependencies, using registry verification features and tools like npm audit signatures

5. Monitor for mandatory requirements as registries expand security mandates to additional packages

6. Participate in registry security programs by reporting suspicious packages and providing feedback on security features

7. Plan for the emerging baseline where 2FA, trusted publishing, and provenance become universal expectations

Registry security improvements represent one of the most impactful supply chain security advances of recent years. By adopting these features proactively, developers and organizations benefit from improved security while positioning themselves for requirements that will become mandatory.