Package Signing

What Is Package Signing?

Package signing is the practice of attaching a cryptographic signature to a software package to verify its author and confirm the package has not been modified since publication. It is a foundational integrity control for software distribution, ensuring that the code developers install from a registry is the same code the maintainer published.

Software package signing protects the link between a package maintainer and the consumer who installs that package. Without signing, developers trust that the registry itself has not been compromised and that no intermediary has altered the package in transit. That trust assumption has been exploited repeatedly through dependency confusion attacks, compromised maintainer accounts, and registry breaches. 

Organizations that enforce signed package verification as part of their software supply chain security programs significantly reduce exposure to these attack vectors.

How Package Signing Works

The mechanics of package signing follow a standard asymmetric cryptography pattern. The package maintainer generates a key pair (or uses an identity-based signing system). After building the package, the maintainer signs it with their private key. The registry stores the package along with its signature. When a consumer installs the package, their package manager verifies the signature against the maintainer’s public key.

If the signature verification fails, the package manager rejects the install. This catches tampering at the registry level, in-transit modification, and substitution attacks where a malicious package replaces a legitimate one.

Different ecosystems implement this differently. npm package signing uses Sigstore-based provenance attestations linked to the publishing workflow’s OIDC identity. Python’s PyPI supports PGP signatures (though adoption is low) and is moving toward Sigstore integration. NuGet, Maven Central, and RubyGems each have their own signing mechanisms with varying levels of enforcement.

The key challenge across all ecosystems is adoption. Signing infrastructure exists, but many maintainers do not sign their packages, and many consumers do not verify signatures. This creates a gap where the mechanism exists but the protection is not consistently applied.

Why Package Signing Matters for Software Supply Chain Security

Supply chain package signing addresses one of the most exploited trust boundaries in modern software delivery: the package registry.

Dependency confusion attacks publish malicious packages to public registries using names that match private internal packages. Typosquatting attacks use near-misspellings of popular package names. Account takeover attacks compromise maintainer credentials to push malicious updates to trusted packages. Each of these attacks succeeds because the consuming build system has no way to verify that the package it is installing is the one the legitimate maintainer intended to publish.

Software composition analysis tools detect known vulnerabilities in dependencies, but they do not verify the integrity of the packages themselves. Package integrity verification fills this gap by confirming that the package content matches what the maintainer signed, regardless of where it was downloaded from.

When combined with dependency management practices like version pinning and lock files, package signing creates a layered defense that protects both the identity of the publisher and the integrity of the content.

Package Signing Standards and Tools

The tooling landscape for package signing includes both ecosystem-specific tools and cross-ecosystem standards. These include:

• Sigstore: Provides keyless signing for multiple ecosystems. npm’s provenance feature is built on Sigstore. Adoption is expanding into PyPI, Maven, and container registries.
• GPG/PGP: The traditional standard for signing packages in Linux distributions (apt, rpm), Maven Central, and some Python packages. Requires manual key management.
• TUF (The Update Framework): A framework for securing software update systems against a range of attacks including key compromise and rollback. Used in PyPI (PEP 458) and several Linux distributions.
• SLSA provenance: Builds on signing by adding attestations about the build process itself, linking signed packages to the source code, build system, and pipeline that produced them.

The most complete implementations combine package signing with provenance attestations and SBOM generation, providing cryptographic proof of both identity (who published it) and lineage (how it was built).

Limitations of Package Signing Alone

Package signing proves that a package was published by a specific identity and was not modified after signing. It does not prove the package is safe, well-maintained, or free of vulnerabilities.

Key limitations include:

• Compromised signers: If an attacker gains access to a maintainer’s signing key or identity, they can produce validly signed malicious packages. Signing proves identity, not intent.
• Signing at the wrong layer: Signing a package that was built in a compromised environment locks in the malicious content with a valid signature. Signing must be paired with build isolation and provenance tracking.
• Inconsistent enforcement: Many package managers do not require signed packages by default. Consumers must explicitly opt into signature verification, and most do not.
• Key management burden: Traditional GPG-based signing requires maintainers to manage long-lived key pairs, which creates operational overhead and key rotation challenges.

Package signing is a necessary but insufficient control. A complete supply chain security program layers it with vulnerability scanning, provenance tracking, build integrity, and runtime verification.

FAQs

Does package signing prevent all supply chain attacks?

No. It prevents tampering and substitution but does not protect against compromised maintainers, vulnerable code, or malicious packages signed with legitimate credentials.

What is the difference between package signing and code signing?

Code signing verifies the identity of the source code author. Package signing verifies the identity of the publisher and the integrity of the distributed package after build and packaging.

Which package ecosystems support signing natively today?

npm (via Sigstore provenance), NuGet, Maven Central (GPG), and most Linux distributions (apt, rpm) support signing natively. PyPI and RubyGems are adding support.

How does package signing relate to SLSA compliance levels?

SLSA Level 2+ requires signed provenance attestations. Package signing provides the identity verification layer, while provenance attestations add build-process transparency.

Can a malicious package still be distributed if it is signed?

Yes. If the signer’s credentials are compromised or the signer is the attacker, the package will have a valid signature. Signing proves origin, not safety.