Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Establishing Provenance Before Coding: Traditional and Next-Gen Software Signing

Taylor R. Schorlemmer, Ethan H. Burmane, Kelechi G. Kalu, Santiago Torres-Arias, James C. Davis

TL;DR

The paper addresses the vulnerability of software supply chains arising from reliance on third-party components and argues that provenance—provenance being a blend of validity and transparency—can be established primarily through software signing. It contrasts traditional signing, with its key-management and transparency challenges, against next-generation signing platforms like Sigstore that use ephemeral keys, identity-provider binding, and public transparency logs. It outlines the architecture, components, and workflows of next-gen signing, and surveys current adoption trends and platform examples, while cautioning that provenance does not guarantee correctness. The work emphasizes integrating provenance into component selection and highlights regulatory and industry momentum toward widespread signing adoption, alongside the need for formal methods to certify software correctness.

Abstract

Software engineers integrate third-party components into their applications. The resulting software supply chain is vulnerable. To reduce the attack surface, we can verify the origin of components (provenance) before adding them. Cryptographic signatures enable this. This article describes traditional signing, its challenges, and the changes introduced by next-generation signing platforms.

Establishing Provenance Before Coding: Traditional and Next-Gen Software Signing

TL;DR

The paper addresses the vulnerability of software supply chains arising from reliance on third-party components and argues that provenance—provenance being a blend of validity and transparency—can be established primarily through software signing. It contrasts traditional signing, with its key-management and transparency challenges, against next-generation signing platforms like Sigstore that use ephemeral keys, identity-provider binding, and public transparency logs. It outlines the architecture, components, and workflows of next-gen signing, and surveys current adoption trends and platform examples, while cautioning that provenance does not guarantee correctness. The work emphasizes integrating provenance into component selection and highlights regulatory and industry momentum toward widespread signing adoption, alongside the need for formal methods to certify software correctness.

Abstract

Software engineers integrate third-party components into their applications. The resulting software supply chain is vulnerable. To reduce the attack surface, we can verify the origin of components (provenance) before adding them. Cryptographic signatures enable this. This article describes traditional signing, its challenges, and the changes introduced by next-generation signing platforms.
Paper Structure (35 sections, 4 figures, 1 table)

This paper contains 35 sections, 4 figures, 1 table.

Table of Contents

  1. TRUST BEFORE CODING
  2. Components Influence Product Code
  3. Provenance in Software Supply Chains
  4. Software Signing
  5. Software Bills of Materials (SBOMs)
  6. Attestations
  7. PRIMER ON PUBLIC-KEY CRYPTOGRAPHY
  8. Key Terms and Concepts
  9. Applications in Computing
  10. TRADITIONAL SOFTWARE SIGNING
  11. How Traditional Signing Works
  12. An Example: Pretty Good Privacy (PGP)
  13. Challenges
  14. Key Management
  15. Identity Verification
  16. ...and 20 more sections

Figures (4)

  • Figure 1: Depiction of the software factory model to highlight the external dependencies. Each chain symbol represents part of the software supply chain involved in producing software. Each component comes from some individual or organization. Provenance techniques enable downstream users to verify the origins of the components on which they depend.
  • Figure 2: Traditional workflow for software signing (left) and next-gerneration workflow for software signing (right). Figure reproduced and adapted from Kalu et al.KaluSigningARXIV.
  • Figure 3: Software signing trends in four public software package registries. Figure is from Schorlemmer et al.schorlemmer_signing.
  • Figure 4: The Sigstore project has tooling available in several programming languages. This chart shows the downloads over time of the associated package for the Python-PyPI package (blue, in thousands) and the JavaScript-NPM package (orange, in millions).