An Industry Interview Study of Software Signing for Supply Chain Security

TL;DR

This study addresses the lack of in-depth industry perspectives on software signing by conducting 18 semi-structured interviews with practitioners across 13 organizations. It develops a refined Software Supply Chain Factory Model to map where and how signing occurs, and identifies technical, organizational, and human challenges that hinder adoption. The findings reveal that while final-product signing is common, input- and dependency-signature verification is often neglected, and signing is frequently treated as a checkbox rather than a primary provenance guarantee. External events and standards have limited direct impact on signing adoption, though they influence related practices like SBOMs. The work provides practical recommendations to improve signing workflows, verification, and cross-ecosystem provenance, and lays groundwork for future tooling and empirical studies.

Abstract

Many software products are composed of components integrated from other teams or external parties. Each additional link in a software product's supply chain increases the risk of the injection of malicious behavior. To improve supply chain provenance, many cybersecurity frameworks, standards, and regulations recommend the use of software signing. However, recent surveys and measurement studies have found that the adoption rate and quality of software signatures are low. We lack in-depth industry perspectives on the challenges and practices of software signing. To understand software signing in practice, we interviewed 18 experienced security practitioners across 13 organizations. We study the challenges that affect the effective implementation of software signing in practice. We also provide possible impacts of experienced software supply chain failures, security standards, and regulations on software signing adoption. To summarize our findings: (1) We present a refined model of the software supply chain factory model highlighting practitioner's signing practices; (2) We highlight the different challenges-technical, organizational, and human-that hamper software signing implementation; (3) We report that experts disagree on the importance of signing; and (4) We describe how internal and external events affect the adoption of software signing. Our work describes the considerations for adopting software signing as one aspect of the broader goal of improved software supply chain security.

Figures (6)

• Figure 1: The Software Supply Chain Factory Model SLSA_The_Linux_Foundation_2023.
• Figure 2: Study methodology. Several sources (left) informed our protocol topics (center). We applied thematic and framework analyses (right).
• Figure 3: Our refined software supply chain factory model (compare to \ref{['fig:SoftwareFactoryModel']}), highlighting different points where provenance and integrity of software could be established (PI, PE, PB, PD, PS, PA) and Verified (VI, VE, VB, VD, VS, VA) using software signatures. These points were identified from participants' responses. Note that while signing at PB and PA stages was commonly practiced (in green), verification at VD, VB and VE stages was minimally performed (in red). Abbreviations are defined in \ref{['tab:rq1']}.
• Figure 4: Typical workflow for software signing and verifying signatures. 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 5: Saturation curve. Interviews are plotted in the order in which they were conducted. Each interview covered many topics in detail (orange line, blue line). However, as the green line shows, our results saturated (i.e., stopped observing new perspectives) around interview 11.