Why Software Signing (Still) Matters: Trust Boundaries in the Software Supply Chain

TL;DR

The paper argues that hardening centralized software registries does not automatically secure provenance or end-to-end integrity across modern, multi-hop distribution paths. It presents a trust-boundary framework showing how guarantees relax as artifacts cross boundaries such as mirrors, proxies, and air-gapped environments, thereby establishing signing as a portable, baseline defense. Through historical context and threat-model reasoning, the authors show that signing remains essential in decoupled or asynchronous delivery, and even with hardened registries, to enforce verifiable identity and integrity at the point of use. The discussion extends to AI intermediaries, highlighting new attack surfaces and the role of attestations and signatures in maintaining auditable trust. Overall, the work advocates treating software signing as a foundational mechanism that extends trust beyond registry control, guiding practical decisions about where to invest in registry hardening versus portable verification.

Abstract

Software signing provides a formal mechanism for provenance by ensuring artifact integrity and verifying producer identity. It also imposes tooling and operational costs to implement in practice. In an era of centralized registries such as PyPI, npm, Maven Central, and Hugging Face, it is reasonable to ask whether hardening registry security controls obviates the need for end-to-end artifact signing. In this work, we posit that the core guarantees of signing, provenance, integrity, and accountability are not automatically carried across different software distribution boundaries. These boundaries include mirrors, corporate proxies, re-hosting, and air-gapped transfers, where registry security controls alone cannot provide sufficient assurance. We synthesize historical practice and present a trust model for modern distribution modes to identify when signing is necessary to extend trust beyond registry control. Treating signing as a baseline layer of defense strengthens software supply chain assurance even when registries are secure.

Figures (3)

• Figure 1: Typical workflow for software signing. The component author packages (A) and signs (B) their software. The signed package (C) and public key (D) are published. To use a package, a user downloads it (E) and its public key (F) and verifies the signature (G). Figure adapted from Kalu et al. usenix_2025_signing_interview_kalu.
• Figure 2: Evolution of software production and distribution. The left side shows a software-factory pipelineslsaSupplychainLevels, first-party source, third-party dependencies/tools, build, and packaging/publishing, with optional bundling/vendoring of dependencies at release. The right side illustrates distribution paths: historically, project-specific or peer-sharing hubs (Top); modern centralized registries (e.g., PyPIpypi, npmnpmjsHome, Maven Centralmaven_central) that improve access control and metadata integrity but introduce single points of control/failure (Middle); and redistribution beyond the registry via mirrors, enterprise proxies/caches, CDNs, or air-gapped transfer (Bottom). When artifacts traverse beyond the registry’s direct control, software signing is needed to carry integrity and authenticity across those boundaries. The figure distinguishes pre-publish steps (e.g., Bundling and Vendoring) in the software factory, that may influence the need/lack of need for signing, from post-publish delivery via the registry and decentralized post-publish redistribution (mirrors, proxies, air-gaps).
• Figure 3: Trust Consideration in a Peer-to-Peer, a Centralized, and an Asynchronous Distribution Model. A. Peer-to-Peer Distribution. Producers (Entity 1) establish connections and directly distribute software components to downstream users. B. Centralized Distribution. Producers (Entity 1) publish artifacts to a trusted and security-hardened registry (Entity 2), from which downstream users obtain software components. This model improves access control and metadata integrity compared to peer-to-peer sharing, but it also concentrates risk in a single point of control or potential failure. C. Artifacts published to a centralized registry are replicated through secondary infrastructure such as mirrors and caching proxies. This model improves scalability and performance but introduces additional trust boundaries, since distribution may occur outside the direct control of the registry.