Building SLSA 3 Conforment Attestors for Artifacts Generated on GitHub

The importance of attestation data in securing the software delivery pipeline and the need for a verification process to establish trust in the attestation data.

• Attestation data provides proof of an event and allows tracing of outputs from inputs in the software delivery pipeline.
• Verification process is necessary to ensure integrity and authenticity of the attestation data.
• Integrity ensures that the attestation data cannot be tampered with, while authenticity ensures identification of the attestation creator.
• Non-forigibility and non-perishability ensure that the attestation content cannot be influenced by users operating the pipeline.
• Complete zero trust in the system is necessary to establish trust in the attestation data.

In the software delivery pipeline, attestation data such as build provenance and software component analysis can help determine what dependencies went into the production and whether any of them were vulnerable to potential CVEs. However, without a verification process, malicious actors could inject malicious artifacts or tamper with the build process and provide a malicious attestation alongside them. Thus, it is important to establish trust in the attestation data through a verification process that ensures integrity and authenticity.

Supply chain Levels for Software Artifacts, or SLSA (salsa) is a security framework to reason about and improve the integrity of released artifacts. SLSA (slsa.dev) is seeing increased adoption, both from industry and open source projects. Besides released artifacts, SLSA provenance attestation may also be generated for other types of "artifacts", such as vulnerability scanner results, SBOMs, etc. This allows the generation of trustworthy supply-chain metadata about arbitrary artifacts. Implementing a SLSA compliant attestor is, however, hard work, and requires expertise in both SLSA and the underlying platform used to build it. Come to this talk to learn about a recent extension of the SLSA framework that allows you to wrap existing tools (in the form of a binary, a GitHub Action or a container) into a SLSA compliant attestor, with minimal effort. We will show how SLSA builders for several package managers, such as npm and maven, are implemented with this framework. We will also report the lessons learned and the challenges we faced, in the hope it will help others in the field. At the end of this talk, attendees will have enough background to make their tool attest to their output using SLSA provenance.