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.
Related resources from NHI Mgmt Group
- What is the difference between Trusted Publishing and storing package credentials in repository secrets?
- What is the difference between a published package and a package that links directly to a VCS repository?
- What is the difference between package signing and version locking in dependency security?
- What is the difference between a compromised package repository and a socially engineered GitHub delivery path?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
