What is the difference between repository-signing and author-signing in package ecosystems?

Repository-signing means the package registry signs the artifact after upload, so users trust the repository’s controls. Author-signing means the maintainer signs the package before publishing, giving downstream users an end-to-end check that the package came from the maintainer. Author-signing is generally stronger for provenance, while repository-signing depends more heavily on registry integrity.

Why repository-signing and author-signing protect different trust boundaries

Repository-signing and author-signing answer different provenance questions. Repository-signing tells you the registry attested to the artifact after intake, which is useful when you trust the repository’s controls. Author-signing tells you the maintainer attested to the package before publication, which preserves end-to-end provenance from the source author to the consumer.

The practical difference is where trust is anchored. With repository-signing, the registry becomes part of the security boundary and can repair or replace missing origin evidence. With author-signing, the downstream consumer can verify that the published artifact matches something the maintainer intended to release, which is stronger when the registry itself is not the main trust anchor.

What each model proves, and what it does not

Repository-signing can confirm that a package was accepted and signed by the registry, but it does not by itself prove who originally created the contents. It is therefore best thought of as registry assurance. Author-signing can more directly support source provenance, but it still depends on the maintainer’s key protection, release hygiene, and signing workflow.

In practice, the two models are not equivalent. Repository-signing is usually simpler for ecosystems to operate at scale because the registry can standardise issuance and verification. Author-signing is usually more useful when consumers need stronger provenance and want to reduce reliance on a single central signing point. The choice affects how much you trust the registry versus the maintainer, and where compromise would matter most.

How practitioners should choose between them

Use repository-signing when the registry is the authoritative control point and you need a predictable trust model across many packages. Use author-signing when you want a stronger chain of custody from maintainer to consumer, especially for supply-chain sensitive packages or environments that care about origin integrity more than registry attestation.

For supply-chain risk, the key question is whether the signing model preserves the assurance you actually need. If a registry compromise, insider action, or signing-policy weakness would undermine trust, author-signing may be preferable. If maintainer key management is weak, short-lived, or poorly governed, repository-signing may be operationally easier, but it shifts the assurance burden to the registry operator.

Risk and Threat Considerations

Signing model choice changes the attack path. Repository-signing concentrates trust in the registry, so compromise of registry controls can affect many downstream consumers at once. Author-signing spreads trust across maintainers, but stolen maintainer keys, weak release pipelines, or malicious signing can still produce a trusted-looking package.

Failure mechanism: An attacker either compromises the registry signing process or abuses a maintainer’s signing key to create a package that verifies as trusted, while the consumer assumes the signature means the artifact is safe and authentic.

Impact: Consumers may install a malicious or altered package with high confidence, and the resulting blast radius can include credential theft, code execution, or widespread supply-chain compromise across dependent systems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
SLSA	Supply chain provenance	Package signing is a provenance control for build and release trust.
Recommendation — Require provenance evidence that links artifacts to their source and build process.
NIST SP 800-53 Rev 5	SI-7 — Software, Firmware, and Information Integrity	Artifact signing is an integrity control for packages consumed downstream.
	IA-5 — Authenticator Management	Author-signing depends on secure key lifecycle and protection for signing material.
Recommendation — Validate package signatures and integrity before deployment or installation. Manage signing keys with rotation, protection, and revocation controls.
CIS Controls v8	CIS-16 — Application Software Security	Package provenance and signed artifacts are part of secure software intake.
Recommendation — Verify software provenance before approving third-party packages for use.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	Package signing relies on cryptographic signing and verification to establish trust.
Recommendation — Define and enforce cryptographic controls for artifact signing and verification.

Practitioner Guidance

What to verify: Verify which signing step is authoritative in your ecosystem before you rely on it. If the registry re-signs artifacts, confirm whether the repository signature is meant to replace origin proof or only supplement it. If authors sign, verify how keys are issued, rotated, and protected, and whether verification happens at install time or only during publication.

Decision rule: If your use case depends on proving maintainer origin, favour OpenSSF guidance on supply-chain controls and insist on author-signing or equivalent provenance checks. If your use case depends on registry trust and operational simplicity, make sure the registry signing boundary is hardened and monitored as a critical control point.

Practitioner takeaway: Repository-signing mainly proves registry custody, while author-signing mainly proves maintainer origin, so choose the model that matches the trust boundary you are actually trying to protect.