SigstoreCon Supply Chain Day 2024

2024 has been quite the year for client libraries as well as Sigstore deployments: with betas of Homebrew's build provenance, Maven Central accepting Sigstore signatures, and PyPI's publish attestation. These deployments (and the client libraries they use) store content in Sigstore protocol buffer formats: signed material in bundles and verification material in trusted roots. There's a number of advantages to using these formats, but unfortunately cosign does not default to using them. It's important for the ecosystem to be interoperable, so we're working on updating cosign to default to these formats, including commands to help folks transition from their existing usage. In this talk we'll go over what that plan looks like, what progress we've made so far, and get your feedback on what else we need to consider to help cosign keep up with the client libraries.

Transparency logs are tamper-evident, immutable ledgers that provide a cryptographic commitment for inclusion of ledger entries in the log to allow the entries to be publicly auditable, forcing malicious behavior to be transparent. Rekor is Sigstore's signature transparency log, where each entry in the log provides auditability for a signed artifact. A public-good instance of Rekor is maintained by the Sigstore community and used by individuals, organizations and package registries. We've learned much since we deployed the 1.0 API for Rekor; the API is complex and inefficient for what clients really need to verify an artifact, and the maintenance burden and storage costs needed to support it are nontrivial and may deter operators from adopting Rekor. Moreover, privacy and redaction is not easily supportable in the current design. There has been active development in simplifying log deployments and minimizing operational costs in Certificate Transparency that we can apply to Rekor. In this talk, we'll discuss how we will leverage these innovations to improve Rekor's usability, simplifying the API and making Rekor deployments easier to maintain and scale.

In the evolving landscape of software supply chain security, Red Hat has embarked on a transformative journey, fully embracing the Sigstore ecosystem. Today, Red Hat's internal product pipelines rely on Sigstore’s Cosign to sign software releases, and Rekor provides an immutable transaction log, enabling customers to verify the integrity of downloaded software artifacts. This integration has been pivotal in ensuring the trustworthiness of the software that Red Hat distributes. As we navigated the intricacies of this integration, we gained deep insights into how Sigstore functions, encountered and overcame various challenges, and refined our approach to secure software delivery. In deploying Sigstore internally, we faced a number of obstacles that could make it challenging for large enterprises to adopt Sigstore for their own software delivery supply chains. We want to share with you how we overcame these challenges, and how we think the Sigstore ecosystem of services can be improved. Join us as we take you through Red Hat’s journey with Sigstore —sharing valuable lessons learned, highlighting the pitfalls we encountered, and showcasing how we fortified our software supply chain.

In Sigstore, the signer information is embedded from OIDC tokens into the signing certificate. Among those information, the Subject Alternative Name (SAN) is the most crucial piece representing the signer's primary identity. Picking the proper attribute as SAN is not easy; there is no one-size-fits-all answer. This is especially obvious when CI platforms are involved, with so many attributes describing the repository owner, source code, builder, etc. Which one makes the most sense as the primary identity? In this session, we will walk through a common mistake people make when using Sigstore in conjunction with GitHub Actions. We will also discuss the differences in understanding the SAN of Fulcio certificates issued to different CI platforms (e.g., GitHub Actions and GitLab pipeline) due to their behavior differences. More importantly, we will discuss what you should think about when using Sigstore on those CI platforms.

Attackers are increasingly exploiting the trust-based, interconnected nature of the open source supply chain, with malware being distributed through package ecosystems, often hidden within the complexity of upstream dependencies. In this talk, we will showcase how Sigstore provenance can serve as a powerful source of truth for verifying package proof-of-origin. The absence of clear provenance, combined with other metadata signals, can act as a strong indicator of potential malicious intent. As a case study, we will discuss a recent spike in DPRK state-sponsored attacks hosted on NPM, where APT groups aimed to harvest cryptocurrencies and establish backdoors on developer machines. Attendees will gain valuable insights into the critical role Sigstore plays in supply chain threat detection, and understand how its broader adoption can help protect the entire ecosystem. By promoting stronger provenance verification, the community can more effectively distinguish between legitimate packages and harmful imitations.

Software Bill of Materials (SBOMs) are no longer merely compliance checkboxes. They're indispensable tools for understanding and mitigating vulnerabilities in the software supply chain. High-profile attacks like Log4Shell, SolarWinds, and Apache Struts have underscored the critical importance of software supply chain security. Sigstore's signing and transparency features when paired with in-toto attestations offer approaches to tracking components within SBOMs and pedigree of SBOMs themselves. This talk will delve into how OpenSSF projects like SBOMit can enhance existing SBOM management strategies to address supply chain risks. We'll also explore how to effectively consume SBOMs using various platforms using bomctl.