On October 5, 2023, we held a Tech Talk on Securing the Software Supply Chain: An In-Depth Exploration of SLSA. SLSA, or Supply-chain Levels for Software Artifacts, is an OpenSSF project that provides a security framework to improve the integrity and security of packages and infrastructure.
You can watch the Tech Talk on demand on our website. The talk featured four panelists: Michael Lieberman from Kusari, Marcela Melara from Intel Corporation, Loreli Cadapan from ActiveState, and Joshua Lock from Verizon and was moderated by OpenSSF General Manager, Omkhar Arasaratnam.
SLSA Tech Talk Highlights
After a warm welcome from Omkhar Arasaratnam and introduction of panelists, we began with An Overview of SLSA by Michael Lieberman, where he presented the core concept of what SLSA is. SLSA provides software attestations to tell how secure a piece of software really is. By tying together provenance information, SLSA provides a framework and can complement existing security practices and industry standards.
Next, Marcela Melara discussed Trustworthiness and Transparency: what does it really mean to trust software? There are many moving parts to answering this question, and the software attestations provided by SLSA help address one part of this problem. Around trustworthiness and transparency, SLSA follows three guiding principles: 1) trust (a small number of) platforms, focus on artifacts; 2) trace software back to source code, not individuals; and 3) prefer attestations over inferences.
Loreli Cadapan then presented the Security Levels of SLSA. There are three security levels— L1, L2, and L3— and each security level of the SLSA Build track increases integrity guarantees. While L1 only requires a basic level of security, L2 and L3 enforce greater security and integrity requirements.
Then, Joshua Lock gave a demo while discussing Implementing SLSA and how SLSA is designed to be implemented by platforms that make up software supply chains. Software producers can opt in to which features they’d like to use, and software users, or more likely their tools,can request and verify builder attestations.
The panelists then discussed the Industry Impact and Future Trends of SLSA. As organizations have started using SLSA, the framework has helped mitigate supply chain risks and improve software security. In the future, SLSA is considering new tracks such as Source and Dependencies, and SLSA Build 4 level is currently being defined.
SLSA Questions and Answers
At the end of the Tech Talk panelists addressed live questions that participants asked about SLSA including:
Q: When the attestations are being generated, are they saved to logs? Then the logs can be verified?
- A: One output of your build is a signed json file with that information.
Q: Do you have a list of recommended build platforms and build process workflows/frameworks?
- A: This Getting Started page provides guidance on implementing SLSA as a developer, including a list of recommended build platforms.
Q: Does SLSA support both Linux and Windows builds?
- A: SLSA is just a set of security practices, so anything that supports the SLSA practices and attestation production would support it. There are various tools in the space that support it in both the Linux and Windows space.
Q: Is there an ETA for the Container builder for building docker images becoming available?
- A: Tekton and a few other tools currently support container builds with SLSA. A GitHub Action is also in development.
Even though we ran out of time to answer all the questions asked, panelists answer a few more questions asked during the talk now:
Q: To my understanding isolation is about build systems, how about air-gapped build where all sources are stored locally ?
- A: Even in an air gapped environment you want to verify that software came from within the air gap. SLSA can be used to verify that all source code and dependencies come from systems within the air gap boundary.
Q: When a process matures, do you expect the attestation signing to be done by a trusted workload versus the end user themselves?
- A: SLSA 3 does have this requirement today. Any builds must be signed with a secret not accessible to end user workloads in order to meet the SLSA 3 requirements. Any build tool that allows the secrets to be signed by a trusted component of the build tool instead of the end user’s build environment would fit this requirement.
Q: What are your thoughts on how important Hardware Security Modules are for protecting keys that perform signing operations — any signing operations that are more critical than others?
- A: This really depends on an individual project or organization’s risk appetite. HSMs as well as other hardware security components like Trusted Platform Modules (TPMs) are good at tying a particular signing secret to the physical hardware that did the signing and prevents attacks like stealing of credentials or plaintext keys. In general the most critical of signing operations will be any secret that can be used to generate other secrets like a Certificate Authority. In the context of SLSA this is useful for those who are running and using secure build systems to tie a SLSA build back to the hardware owned by the trusted party running the build.
Q: I’ve noticed on the verification side of SLSA that concepts like branches/tags are common, but not git commit SHAs, is there a reason for that?
- A: There may be more examples using tags vs commits, but both concepts (branches/tags and commit SHAs) are supported. However, commit-hash provides immutability, whereas tags don’t necessarily. Ultimately the decision is architectural and will vary by ecosystems as they adopt SLSA. Artifact verification in SLSA includes evaluating the data captured in provenance against the user’s expectations. Branches are more general and necessitate fewer updates to expectations, whereas commit digests are more precise but may require more frequent changes to a package’s expectations.
Q: Does Sigstore publish all signed information to a public log?
- A: No, it publishes records that an artifact or attestation was signed with a particular key or certificate. Signing events for publicly trusted attestations or artifacts should be logged to the public Sigstore log, while privately trusted artifacts could optionally be logged depending on your threat model. The certificate, which will include your signing identity, is recorded to the log. An attestation may be uploaded to the log in certain cases, but Sigstore clients are moving towards only including the signing event for attestations. It is possible to run the Sigstore infrastructure including Rekor, the transparency log, and Fulcio, the CA, in a private environment as well.
Watch Tech Talk on Demand
Thanks for taking the time to SLSA with us! View the Tech Talk on our website and whether you are a developer, organization, or infrastructure provider, get started using SLSA today.