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 (called "provenance" in npm terminology) uses OIDC federation to eliminate the need for long-lived npm tokens in CI/CD systems. 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
• 2024: Continued expansion of 2FA requirements

npm supports multiple 2FA methods including TOTP authenticator apps, security keys (WebAuthn), and the npm mobile app. Security keys provide the strongest protection against phishing attacks.

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.

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. Recent versions of pip automatically verify attestations when available.

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.

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.

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.

Emerging Common Baseline¶

A common security baseline is emerging across major registries:

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

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

Transparency: - 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.

Timeline of Improvements¶

Key milestones in registry security:

The pace of improvement has accelerated significantly since 2021, driven by high-profile incidents 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. Plan for OIDC publishing as it becomes available on other registries

5. Enable strongest authentication available:

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

8. Enable audit logging where available

9. Publish with provenance:

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

10. 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.