10-26, 10:50–11:15 (Europe/Berlin), Main stage
Although a compromise of an entire open-source software package repository would be deadly serious, and we have evermore tools to try to address different parts of the story, the problem is that simply adding signatures to tamper-evident logs is not enough: given a software package, how can we tell why we are supposed to trust it in the first place? Who or what was supposed to sign the package? (This problem is reminiscent of the PGP/GPG Web of Trust.) Was the package tested for quality? Was it built on a trusted build platform? Who wrote the source code? Did anyone review the code? These questions and answers may be as varied as the hundreds of thousands of packages on such repositories. How would consumers such as package managers know which rules of the game to apply for which packages?
To solve this problem, we explain how we can use three foundational, open-source supply chain security frameworks called in-toto, The Update Framework (TUF), and Sigstore. If using in-toto is like Pfizer or Moderna vouching for exactly how a vaccine was made and what went into them, then TUF is like the FDA telling you why you should trust Pfizer and Moderna for the Comirnaty and Spikevax vaccines respectively in the first place or continue to do so, while Sigstore is like the Library of Congress permanently recording the history of every single vaccine vial. We will use PyPI as a motivating example, and explain how the same ideas and techniques can be used to secure other package repositories such as Cargo, Homebrew, NPM, and RubyGems.
If you think of supply chain attacks as the game of telephone problem, then in-toto solves this problem using two main techniques: attestations and layouts. An in-toto attestation aims to provide you with authenticated metadata about the inputs, outputs, and environment of a step within a supply chain, so that you can compare metadata between different steps in order to detect an attack. A layout specifies these steps in the first place, and what rules they must follow, such as who is allowed to sign attestations for each step, and how inputs and outputs must match between steps. Using both attestations and layouts, you could answer questions such as: did the builder use the same code that a developer committed to the source code repository, and did the package repository publish the same package that the builder produced?
You can think of The Update Framework (TUF) as being the TLS of code signing: given a version of a package, how do I know which layout (and hence attestations) to use in the first place to verify it? You can configure TUF in such a way that these delegations of trust from the repository to developers are immutable even if the repository has been compromised. TUF also prevents attackers from being able to rollback to vulnerable versions of packages (even if signatures cannot be tampered with without being detected), or mixing-and-matching incompatible versions of packages that are not meant to be installed together (e.g., due to known conflicts).
Last but not least, you can use Sigstore to permanently record all of this information on a public ledger so that independent auditors can monitor packages and keep the ecosystem honest. Developers can also depend on Sigstore for “zero-trust” keys so that they don’t have to maintain any long-term signing keys if the burden is too much.
Finally, when you put all of this together, you get a very strong security property we call transparent compromise-resilience: so strong that even if nation-state attackers have temporarily compromised an OSS package repository, packages that have opted into this level of security are not impacted.
Software supply chain security expert with 10+ years of knowledge. SLSA v1.0 and in-toto steering committee, Uptane advisor, TUF and SBOMit maintainer, Sigstore contributor.