Open Source Summit North America 2022

SLSA (Supply-chain Levels for Software Artifacts) is a framework led by Google, that defines four levels of protection for a software supply chain, and provides guidelines on how to reach these levels. Since companies operate dynamic pipelines, there is a need to continuously measure the pipeline's security. This can be met by implementing automated SLSA-compliance evaluation. In this talk , we shall share lessons learned from our journey in implementing automation in real-world scenarios using open-source tools such as Sigstore and OPA. The lessons, conceptual and technical, shed light on the real-world details and challenges we encountered when evaluating, and automating the evaluation of SLSA compliance. Some of these lessons challenge part of SLSA requirements.

Tekton, a cloud native solution for building CI/CD systems, has made great strides in achieving SLSA Level 1 (​​unsigned provenance) and 2 (hosted source/build, signed provenance) with the inclusion of Tekton Chains. Part of attaining higher SLSA levels include protecting and holding the build systems we use accountable. A requirement of SLSA level 3 is non-falsifiable provenance, which states that build system provenance should not be falsifiable by build service’s users - i.e. protecting against cluster administrators. With the integration SPIFFE/SPIRE, Tekton can achieve this capability. SPIFFE/SPIRE provides Tekton with short-lived certificates (backed by workload attestation), that are used to sign build results and status updates (through the TaskRun object). This results in the ability to provide and verify provenance of the build steps, ensuring that they are cryptographically protected against edits not performed by the Tekton Trusted Computing Base (TCB). In this presentation we will show this in action and sabotage our own pipelines to visualize non-falsifiable provenance.

Github Actions, the recent (from 2018) CI/CD addition to the popular source control system, is becoming an increasingly popular DevOps tool mainly due to its rich marketplace and simple integration. As part of our research of the Github actions security landscape, we discovered that in writing a perfectly secure Github actions workflow, several pitfalls could cause severe security consequences. Unless the developers are proficient in the depths of Github best-practices documents, these workflows would have mistakes. Such mistakes are costly - and could cause a potential supply-chain risk to the product. During the talk, we’ll walk you through our journey on how we found and disclosed vulnerable workflows in several popular open-source tools, delved into Github actions architecture to understand the possible consequences of these vulnerabilities, and present what could be the mitigations for such issues.