18.1 Package Registry Security Features¶

Package registries occupy a uniquely powerful position in the software supply chain. When a developer runs npm install, pip install, or mvn dependency:resolve, they implicitly trust that the registry will deliver authentic, unmodified packages from legitimate publishers. A compromise at this layer—whether through account takeover, malicious uploads, or infrastructure breach—can cascade to millions of downstream systems within hours. Understanding the security features that modern registries provide, and how to leverage them effectively, is essential for both package publishers and consumers.

The security posture of package registries has evolved dramatically since 2020. High-profile incidents like the ua-parser-js account compromise (October 2021, 7 million weekly downloads affected)¹ and the event-stream malicious contribution (November 2018) exposed fundamental weaknesses in registry security models. In response, major registries have implemented increasingly sophisticated protections. This section surveys these capabilities across the ecosystems you are most likely to encounter.

Authentication and Authorization Models¶

Package registries employ varying authentication models that reflect their history, governance, and threat models.

npm uses token-based authentication with granular scopes. Users can create tokens restricted to specific operations (read-only, publish-only) and IP address ranges. Organization accounts support team-based permissions, allowing fine-grained control over which members can publish to which packages. Since December 2022, npm has offered granular access tokens with restricted scopes. Legacy full-access tokens remained available until 2025, when npm completed the migration to granular tokens exclusively.

PyPI historically relied on username/password authentication with API tokens added in 2019. The transition to API tokens has been gradual but accelerated by security requirements. PyPI tokens can be scoped to specific projects, preventing a compromised token from affecting unrelated packages. The PyPI API Tokens documentation details scoping options.

Maven Central, accessed through Sonatype's OSS Repository Hosting (OSSRH), requires account verification and namespace (groupId) ownership validation. Publishing requires signing artifacts with PGP keys, which adds a layer of publisher authentication beyond account credentials. The verification process, while more cumbersome than other registries, provides stronger assurance of publisher identity.

NuGet uses API keys scoped to specific packages or package prefixes, with support for expiring keys. The NuGet Gallery supports Azure Active Directory integration for organizational accounts, enabling enterprise identity management.

RubyGems employs API keys with configurable scopes (push, yank, add/remove owners). Recent improvements allow keys restricted to specific gems and with mandatory MFA requirements.

Multi-Factor Authentication Enforcement¶

Multi-factor authentication represents the single most effective control against account takeover, which remains the primary vector for supply chain attacks on package registries. Registry MFA enforcement has progressed significantly:

npm's approach has been particularly aggressive. In February 2022, npm began requiring MFA for maintainers of the top 100 packages, expanding to the top 500 and adding a broader "high-impact" category that includes packages with many dependents or high download counts. By 2024, npm expanded MFA enforcement to include any package with significant reach. The registry supports both TOTP (authenticator apps) and WebAuthn (hardware security keys).

PyPI's rollout has focused on "critical projects" identified through a combination of download counts and dependency analysis. The Python Software Foundation announced mandatory 2FA for all maintainers, with enforcement completed by end of 2023. PyPI supports TOTP and WebAuthn, with security keys strongly recommended.

Crates.io (Rust) strongly encourages MFA for all publishers, with ongoing community discussions about mandatory enforcement. This reflects both the Rust community's security-conscious culture and the relatively smaller publisher base compared to npm or PyPI.

We recommend enabling MFA immediately on all registry accounts, using hardware security keys (WebAuthn) where supported. TOTP-based MFA, while better than nothing, remains vulnerable to phishing attacks that WebAuthn prevents.

Namespace Protection and Verified Publishers¶

Namespace squatting and typosquatting occur when attackers register package names similar to popular packages or claim organization namespaces before legitimate owners. See Book 1, Chapter 7 for detailed coverage of typosquatting attacks. Registries have developed various defenses:

npm scoped packages (@organization/package) provide namespace protection by tying package names to verified organization accounts. Scoped packages cannot be published by anyone outside the organization. However, the vast majority of npm packages remain unscoped, leaving them vulnerable to name-adjacent attacks. npm also implements package name similarity detection that flags potentially confusing names during publication.

PyPI lacks formal namespaces but implements project name normalization that treats variations (underscores, hyphens, case) as equivalent. The registry also maintains a list of reserved names for well-known projects not yet on PyPI. More recently, PyPI has explored organization accounts that would provide npm-style namespace protection.

Maven Central uses groupId verification requiring publishers to prove domain ownership or GitHub organization membership before publishing under a namespace. For example, publishing under com.example requires proving control of example.com. This provides strong namespace protection but creates friction for individual developers.

NuGet offers package ID prefix reservation, allowing verified publishers to reserve prefixes like Microsoft.* or Newtonsoft.*. Reserved prefixes display a verification checkmark in the NuGet Gallery, helping users identify authentic packages.

RubyGems does not currently offer namespace protection, though discussions about organization accounts continue. The registry relies on maintainer vigilance and community reporting to address typosquatting.

Package Signing and Verification¶

Signing capabilities vary dramatically across registries, reflecting different security maturity levels and historical design decisions:

npm launched npm provenance in April 2023, using Sigstore to sign packages published from supported CI/CD environments. Provenance attestations link packages to specific source repositories and build configurations. Verification is available via npm audit signatures:

npm audit signatures
# Outputs:
# audited 847 packages in 2s
# 847 packages have valid registry signatures
# 312 packages have verified attestations

The attestations prove not just that npm signed the package, but that it was built from a specific Git commit in a specific repository using a specific workflow.

PyPI added Sigstore attestation support in November 2024 through the Trusted Publishers feature. Packages published via Trusted Publishers can include provenance attestations verifiable using sigstore-python:

python -m pip download somepackage --no-deps
python -m sigstore verify identity \
  --bundle somepackage-1.0.0.tar.gz.sigstore \
  --cert-identity "https://github.com/owner/repo/.github/workflows/publish.yml@refs/tags/v1.0.0" \
  --cert-oidc-issuer "https://token.actions.githubusercontent.com" \
  somepackage-1.0.0.tar.gz

Maven Central has required PGP signatures since its inception. Every artifact must include a .asc signature file, and public keys must be published to a keyserver. While this provides cryptographic verification, PGP's usability challenges mean signatures are rarely verified in practice. Maven does verify signatures automatically during downloads from Central.

NuGet supports optional package signing using X.509 certificates. Microsoft signs all packages it publishes, and the .NET CLI can be configured to require signed packages:

<!-- nuget.config -->
<configuration>
  <config>
    <add key="signatureValidationMode" value="require" />
  </config>
</configuration>

RubyGems supports gem signing using X.509 certificates, but adoption is minimal. The signing infrastructure exists but is rarely used due to usability friction.

Malware Scanning and Security Holds¶

Modern registries employ various mechanisms to detect and block malicious packages:

npm runs automated malware scanning on all published packages using a combination of static analysis, behavioral heuristics, and machine learning. Suspicious packages are placed in a review queue, and confirmed malware is removed with the package name blocked from re-registration. npm also accepts reports through its security team and HackerOne program.

PyPI uses multiple scanning tools including those developed by the Python Software Foundation and contributions from security researchers. The PyPI Malware Reporting page provides a mechanism for reporting suspicious packages. Confirmed malware is yanked (removed from installation) while leaving metadata visible for forensic purposes.

Maven Central relies primarily on the namespace verification and signing requirements to prevent unauthorized uploads. Post-publication scanning is less emphasized, though Sonatype's commercial products (Nexus IQ) provide vulnerability and malware scanning for organizations.

RubyGems implemented malware scanning following incidents like the rest-client compromise (August 2019). The Ruby community also operates RubyGems Advisory Database for tracking known malicious gems.

When registries identify malware, they typically take graduated responses:

1. Security hold: Package remains visible but cannot be installed
2. Yank: Package removed from installation but metadata retained
3. Full removal: Package completely deleted (reserved for severe cases)
4. Name blocking: Package name blocked from future registration

Trusted Publishing: OIDC-Based CI Integration¶

Trusted publishing eliminates long-lived API tokens by allowing CI/CD systems to authenticate directly with registries using OIDC (OpenID Connect) tokens. This represents a fundamental security improvement over traditional token-based publishing.

PyPI Trusted Publishers allow GitHub Actions, GitLab CI, and other supported providers to publish packages without API tokens:

# .github/workflows/publish.yml
name: Publish to PyPI
on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      id-token: write  # Required for OIDC
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
      - run: pip install build
      - run: python -m build
      - uses: pypa/gh-action-pypi-publish@release/v1
        # No token needed - OIDC authentication

The PyPI project must be configured to trust the specific repository and workflow. This configuration binds the publishing capability to a specific source, making token theft irrelevant.

npm provenance works similarly for supported CI environments:

# .github/workflows/publish.yml
jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm publish --provenance --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

While npm still requires a token for authorization, the provenance flag adds Sigstore attestations that cryptographically bind the package to its source.

Registry Transparency and Audit Logs¶

Audit logs provide visibility into account and package activity, enabling detection of unauthorized access and forensic investigation after incidents.

npm provides organization-level audit logs for paid organization accounts, tracking events including package publications, team membership changes, token creation, and access control modifications. Individual users have limited visibility into their own activity.

PyPI offers download statistics and recent activity views but lacks comprehensive audit logging for most users. The PyPI Transparency Logs initiative aims to provide better visibility into package publication events.

Maven Central provides minimal audit capabilities through the OSSRH interface. Publication events are logged but not easily accessible for security analysis.

NuGet offers audit logs for organizations using Azure Active Directory integration, leveraging Azure's logging infrastructure.

For organizations consuming packages from multiple registries, third-party tools like Socket, Snyk, and Phylum provide cross-registry monitoring and alerting for suspicious publication patterns.

Recommendations¶

We recommend the following practices for both package publishers and consumers:

For publishers: 1. Enable MFA immediately using hardware security keys where supported 2. Adopt trusted publishing (OIDC) to eliminate long-lived tokens 3. Use scoped tokens with minimal permissions when tokens are necessary 4. Register namespaces/scopes/prefixes where available to prevent squatting 5. Enable signing and provenance attestations

For consumers and organizations: 1. Configure package managers to verify signatures where supported 2. Monitor for unexpected package publications using audit logs or third-party services 3. Prefer packages from verified publishers or namespaced accounts 4. Implement internal policies requiring MFA for developers with registry access 5. Use tools like npm audit signatures to verify provenance

For registry operators: 1. Require MFA for all publishers, not just high-impact packages 2. Implement namespace protection to prevent squatting 3. Provide comprehensive audit logs accessible to all users 4. Support Sigstore-based signing for interoperability 5. Offer trusted publishing options that eliminate long-lived credentials

Package registry security continues to evolve rapidly. The features described here represent the current state as of 2024, but registries regularly add new capabilities in response to emerging threats. Subscribe to security announcements from registries you depend on, and review your security configurations quarterly to ensure you are leveraging available protections.