Panel Discussion: Ketchup, Mustard, and Relish of Software Supply...
Analyzes panel Discussion: Ketchup, Mustard, and Relish of Software Supply and evaluates key implications for security practitioners.
Summary
### Overview This panel discussion, hosted by the Open Source Security Foundation (OpenSSF) under the Linux Foundation, explores key frameworks and tools designed to protect the software supply chain. Moderated by Arnaud (IBM), panelists Laura (Red Hat), Jay White (Microsoft), and Mike Lieberman (Kusari) demystify the open-source supply chain security landscape by breaking down three primary pillars developed within OpenSSF's Supply Chain Integrity Working Group: SLSA (Supply Chain Levels for Software Artifacts), Fresca, and S2C2F (Secure Supply Chain Consumption Framework).
### Key Topics - **OpenSSF Structure**: Formed to secure open-source software collectively, transitioning in 2022 to a fully funded model with a Governing Board, Technical Advisory Council (TAC), and multiple working groups, including the Supply Chain Integrity Working Group. - **SLSA (Supply Chain Levels for Software Artifacts)**: A framework establishing progressive levels of assurance to prevent tampering, improve build integrity, and generate verifiable provenance metadata throughout the build pipeline. - **Fresca (Secure Software Factory)**: A cloud-native reference implementation originating from CNCF TAG Security, implementing SLSA level 3 requirements using tools such as Tekton, Tekton Chains, and SPIFFE/SPIRE. - **S2C2F (Secure Supply Chain Consumption Framework)**: Originating within Microsoft, this consumer-side framework organizes dependency management and open-source ingestion into eight practices across four maturity levels based on threat modeling. - **Evolution of SLSA 1.0**: The reduction from early draft requirements (~20 requirements down to 5 core requirements across 3 levels) to establish a sharply focused, actionable foundation centered on build provenance generation and isolation strength.
### Technical Details - **SLSA Specifications & Tracks**: While early drafts outlined four levels across varied scopes, SLSA 1.0 concentrates strictly on the Build Track across levels 1 to 3. Level 1 requires recording build execution and provenance; Level 2 requires cryptographic signing of provenance; Level 3 mandates isolated build environments to prevent tampering with signing keys and credentials. Future iterations plan to introduce dedicated tracks for Source and Build Platforms, as well as re-evaluating an actionable Level 4. - **Fresca Infrastructure**: Fresca provides a concrete build system capable of hitting SLSA Build Level 3 in a secure Kubernetes cluster. Pull requests involving SPIFFE/SPIRE with Tekton and Tekton Chains allow the system to detect and prevent unauthorized in-flight build modifications even against actors with cluster administrative access. - **S2C2F Governance and Threat Mitigation**: S2C2F structures dependency consumption against risk matrices (e.g., mitigating typo-squatting, malicious injections, zero-days, or known vulnerabilities). Level 1 establishes basic open-source scanning and governance; Level 3 introduces defenses such as zero-day detection, malicious defense, and scanning of mirrored/cloned repositories; Level 4 introduces advanced validation of SBOM quality and completeness. - **Attack Surface Realities**: The panel addressed real-world attacks such as SolarWinds and Codecov, noting that build provenance alone cannot prevent compromised production credentials or attacks targeting the build system itself. Future source tracking aims to verify that committed code accurately reflects developer intent, with community discussions evaluating evidence mechanisms such as multi-party signing for pair programming.
### Takeaways - SLSA, Fresca, and S2C2F are complementary: S2C2F governs how open-source dependencies are ingested and managed before the build, SLSA provides standards for pipeline hardening and provenance verification during the build, and Fresca provides an open-source reference implementation of these build standards. - OpenSSF frameworks map to industry compliance requirements, including NIST SSDF, NIST SP 800-161, NIST SP 800-53, and executive orders. - Participation across all OpenSSF working groups and specification tracks is open to the public without paid membership requirements.
Related talks
The Linux Foundation·40 min
Laura Seay · Arnaud Hors · Jay White · Michael Lieberman · Joshua Lock
Evaluates ketchup, Mustard, and Relish and evaluates key implications for security practitioners.
The Linux Foundation·26 min
Anand Kashyap · Marvin Tong · Erica Brescia
Discusses wrap-Up Session Panel Discussion: Quick Takes and evaluates key implications for security practitioners.
The Linux Foundation·29 min
Details regulatory Panel Discussion: Brittany Kaiser, Mark Bower, & Moderated by Aaron Fulkerson and evaluates key implications for security practitioners.


