SigstoreCon Supply Chain Day 2024

Over the last 5 years, PyPI has adopted a large number of technologies and standards aimed at improving the integrity of the Python packaging ecosystem: scoped API tokens, security events, strong MFA, Trusted Publishing, and (most recently) PEP 740 for cryptographic package attestations. This talk hypothesizes and breaks down the next 5 years of changes, ranging from immediately practical efforts to "big picture" ideas. Some ideas considered include (but are not limited to): * Index-wide binary transparency in the style of Go's sumdb, along with considerations for identity (i.e. package identity) monitoring by upstreams; * "Counter" attestations in the vein of PEP 740, enabling auditors and interested community members to cryptographically register their trust in a PyPI package; * Scalable witnessing and monitoring for PEP 740 attestations, including rollup techniques for reducing the burden of integration for pure-Python package installers like `pip`; * TOFU-style identity locking via lockfiles, including (potentially) Python's PEP 751; * Using TUF to distribute complex identity policies.

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.

Sigstore Ruby now exists. So exciting! But bringing it to life was a challenge, particularly due to the goal of being able to ship it as a part of Ruby itself. Building a sigstore implementation atop only the standard library required writing a TUF client, implementing custom x509 handling, and abstracting over all the supported key types, among other challenges. This talk will explore those challenges, and dive into _why_ a sigstore implementation proves to be such an undertaking, hopefully inspiring some simplification for the next poor soul who attempts to build one from scratch.

The Sigstore trust root is delivered to Sigstore clients via root-signing, a less known but security-critical part of Sigstore. In this talk the audience will learn how the project operates and also why it went through a significant rewrite during the past year when it switched to using tuf-on-ci as tooling. The talk will outline the best practices of trust root management and how they are now applied in the project. Topics include: * Current state of the Sigstore root-signing project * Why on earth would you rewrite working critical infrastructure? There are multiple incompatibility incidents in the history of root-signing: the talk will show how a rewrite can be a sensible choice in this situation * Design discussion – why is root-signing such a strange little project? Turns out the combination of user collaboration in a community project with hardware backed signing requires a unique solution * What is next for root-signing?

When an AI model misbehaves (e.g., it tells you to put glue on pizza), you must investigate how this happened. Sometimes these are accidents caused by the training data, but these incidents can also be due to nefarious activities – we’ve seen ML malware deployed in 2024. At the end of the day AI is still software, so security needs to be established around its creation. The same transparency and accountability must be enforced as with other parts of the software supply chain. Utilizing SLSA (Supply Chain Levels for Software Artifacts) and GUAC (Graph for Understanding Artifact Composition), we can determine the provenance of each dataset and the composition of each model. In this talk, we dive into the anatomy of AI model attacks: identifying bad models, determining the root cause of badness, and finding the blast radius of models affected. Once the data is collected, we can create an SBOM and distribute with the AI model provenance to meet compliance and transparency requirements.

The Sigstore and TUF communities both maintain conformance test suites that have been helpful in identifying inconsistencies and security vulnerabilities in clients. This talk offers a deep dive into these two conformance test suites. We first talk about the issues that lead to their development: Interoperability issues and vulnerabilities are painful everywhere but especially so in the field of supply chain security. We then describe the architecture of the test suites and take a look at the engineering and the unique technical problems in conformance testing systems like this: When all test data is by definition cryptographically signed, creating test cases can be very tricky. Next, we cover with practical examples how clients can adopt the test suites and share the experiences client developers have had when adopting the test suites.. Finally, we will examine the impact of these efforts on the Sigstore and TUF ecosystems and how compatibility is improving and clients are becoming more secure. We finish the talk by discussing future ideas for the conformance test suites and how the community can contribute.

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.