An Industry Interview Study of Software Signing for Supply Chain Security

This is a brief for the research paper “An Industry Interview Study of Software Signing for Supply Chain Security”, published at the 2025 USENIX Security Symposium. This work was led by Kelechi Kalu. The full paper is available here. Kelechi Kalu wrote this brief, which I have lightly edited.

Motivation

Most cybersecurity-oriented folks have heard or read about the SolarWinds attack of 2020. SolarWinds affected many high-profile organizations, including the Department of Defense (DoD). This incident is often regarded as the poster child of software supply chain attacks. In response, new regulations (e.g., NIST guidelines and Executive Order 14028), security frameworks (e.g., SLSA, SSCIM), and academic proposals have emerged, all emphasizing the critical need for establishing software provenance through methods like software signing.

While these frameworks and regulations recommend signing, they do not provide concrete implementation models to guide adoption. In practice, measurement studies have shown that the software supply chain frequently suffers from missing or erroneous signatures, highlighting a gap between policy recommendations and real-world execution.

The effectiveness of software signing depends on careful adoption strategies. A deeper examination of current signing practices and the rationale behind them is essential for understanding its real-world implications. With that goal in mind, let’s get started.

Key terms and definitions

Before explaining our study, we’ll need some details about two key concepts — software supply chains and software signing.

Software Supply Chains

Software production is often visualized through a model that approximates the software engineering process, integrating both first- and third-party components, which are then packaged for downstream use. This combination of engineering processes and distribution forms the software supply chain, illustrated below.

The software supply chain factory model visualizing the software supply chain.

The security of the software supply chain is broadly defined by three key properties:

• Validity — Ensuring the integrity of components and actors.
• Transparency — Maintaining knowledge of components and actors.
• Separation — Isolating components and actions performed by different actors within the supply chain.

The combination of validity and transparency establishes provenance — a crucial aspect of software security. Security techniques aim to enhance one or more of these properties to strengthen overall software supply chain security.

Software Signing

Software signing is a formally guaranteed method of establishing the authorship of software. It employs public-key cryptography to create a hash of the software binary, which is then encrypted with a private key. This process supports two of the security properties given above:

• Validity — The signed artifact has not been altered since it was last signed.
• Transparency — The contents of the artifact are verifiable.

Together, these properties contribute to provenance, helping establish trust in the integrity and authorship of software components.

A more detailed discussion of the signing process is available in our prior work, Signing in Four Public Software Package Registries: Quantity, Quality, and Influencing Factors.

Empirical studies on software signing in open-source ecosystems have raised concerns regarding usability challenges, opportunities for exploitation, and low adoption rates. Our work takes a qualitative approach to exploring software signing practices in industry, aiming to answer key questions on effective signing strategies, adoption challenges, and the factors influencing its implementation.

Methodology

To investigate software signing adoption practices, we conducted 18 semi-structured interviews with experienced security practitioners from 13 organizations. Our participants were either responsible for initiating or implementing security controls within their organizations or worked in organizations that produced security products.

To develop our interview protocol, we drew insights from three key sources:

1. Academic literature on software security and signing.
2. The software supply chain factory model to contextualize signing within broader supply chain processes.
3. Grey literature, including industry reports on software signing usage.

By incorporating these diverse sources, we ensured that our questions were grounded in both theoretical understanding and real-world industry practices. Then, for data analysis, we employed a thematic and framework analysis approach to identify patterns and insights from participant responses. The figure below illustrates this:

A summary of our study design and analysis process. We incorporated multiple sources to inform our study instrument design. Depending on the research question, we applied thematic analysis (inductive) or a combination of thematic and framework analysis (using the previously described software supply chain factory model).

Key Results

We present some of the key findings from our research next. A more comprehensive set of results can be found in our accompanying paper.

How is Signing Applied in Practice?

We first examined where in the software engineering process software signing is implemented by development teams. To conduct this analysis, we used the software supply chain factory model (pictured above) as a reference framework. Based on participant responses, we modified the model to explicitly indicate the points in the software engineering process where provenance is — and should be! — established and verified. These points are summarized in the figure below.

Our modified software supply chain factory model highlighting different expected signing use points. These points are categorized based on whether they involve signing (S) or verification (V) of signatures. We also indicate the number of participants, out of 18, who adopt signing at these stages. (PI — Internal contributors sign commits, VI — Verify signatures from internal contributors, PE — External contributors sign commits, VE — Verify signatures from external contributors, PS — Signing after code reviews/audits, VS — Verify source code signatures before build, PB — Signing of build output, VB — Verify build signature before deployment, PA — Signing of the final software product, VA — Verification by final customers, PD — Signing after verification and certification of dependencies, VD — Verify signatures from external dependencies.)

From the figure, we observe that:

1. Most teams establish software signatures at the final product phase, the build phase, or after an internal source code review process (or even require signing from internal code contributors).
2. However, many teams omit signature verification.

What are the Challenges of Software Signing Implementation?

We asked subjects what challenges they experience as they implement signing. The following table summarizes what we learned.

A summary of the challenges articulated by our participants affecting their implementation of software signing. Using thematic analysis, we theme these into Technical, Organizational, and Human Challenges. While some of these issues have been highlighted we provide the first empirical investigations for these.

Verification problems were widely acknowledged by practitioners as a significant challenge. Our results also revealed subtle patterns indicating that participants from organizations of similar sizes reported similar types of issues. For example, only participants from large organizations reported difficulties in operationalizing the signing process, while only participants from organizations with non-security-focused product areas cited a lack of management incentives for adoption.

How do factors such as security standards, regulations, and software supply chain incidents impact the implementation/adoption of software signing?

We found that security failures primarily lead to direct fixes rather than large-scale security overhauls, with only a few instances prompting changes in software signing practices. Most incidents experienced by organizations were non-malicious vulnerabilities or operational failures rather than targeted attacks. When signing adoption was influenced, it was typically in response to specific security-critical needs, such as ensuring traceability in high-assurance environments.

Our results also show that while security regulations and frameworks shape broader security strategies — such as the adoption of SBOMs — they have minimal direct impact on software signing implementation. Organizations tend to comply with these regulations by enhancing general security processes rather than specifically integrating signing as a core security measure.

The following table gives a quantitative view of our data.

Kinds of software supply chain failures experienced, and associated security changes. Only one participant reported an influence of these failures on their software signing implementation. Software supply chain failures were more likely to prompt a direct fix rather than a change in the security process.

Conclusions and next steps

Our results show that while software signing is important, several challenges still limit its effective implementation. In its current state, software signing may not yet provide its full intended benefits. Our work addresses some of these challenges by refining the software supply chain factory model to clearly indicate where signing should be established and verified.

However, urgent issues in verification still need to be resolved, and security standards should emphasize the importance of software signing alongside SBOMs and other transparency techniques. Additionally, software signing tools should be designed to improve their usability, ensuring that both signature creation and verification processes are more accessible and efficient.

What’s Next for Us?

We are currently studying the usability of software signing tools, particularly Sigstore. Additionally, we are actively researching the state of software signature verification in open-source repositories. Breakthroughs in this area could contribute significantly to establishing trust in open-source ecosystems and improving overall security practices.

Want to learn more?

You can read the full paper here. Some of our related papers are this one and that one and also that other one. After the symposium in August 2025, our slides and recording will also be available on the USENIX website!