Google SLSA & NIST SSDF: Emerging Software Supply Chain Security Best Practices

### Overview In this talk, Tony Lure, a developer advocate and evangelist at Cycode, explores two prominent software supply chain security frameworks: NIST's Secure Software Development Framework (SSDF v1.1) and OpenSSF's SLSA (Supply-chain Levels for Software Artifacts, historically associated with Google). The presentation outlines how attackers are increasingly shifting their focus away from attacking production applications directly toward targeting software delivery pipelines and developer credentials. Using statistics such as Gartner's prediction that 45% of organizations worldwide will experience software supply chain attacks, Lure examines the structure, requirements, and philosophies of both NIST SSDF and OpenSSF SLSA, highlighting how organizations can combine them to build a comprehensive security roadmap while addressing remaining industry gaps.

### Key Topics - **Shifting Threat Landscape**: Attacks targeting developer credentials, pipelines, and dependencies (referencing incidents like SolarWinds, Codecov, XcodeSpy, and Log4j). - **NIST SSDF (SP 800-218)**: Created in response to a presidential executive order following incidents like the Colonial Pipeline attack, the SSDF establishes a common security language across federal agencies and industry. It outlines five core principles (Protect, Confidentiality, Identity, Rapid Response, Training) and four primary practice groups: Prepare the Organization, Protect Software, Produce Well-Secured Software, and Respond to Vulnerabilities. - **OpenSSF SLSA**: Originating from Google's internal practices (such as Binary Authorization for Borg), SLSA provides an incremental, prescriptive rubric focused on build integrity and provenance fidelity across four progressive levels (SLSA 0 through SLSA 4). - **SSDF vs. SLSA Comparison**: The SSDF addresses "what" needs to be achieved at a high level across risk management tiers, whereas SLSA provides a detailed, actionable rubric detailing "how" to secure source, build, and provenance generation. - **Identified Industry Gaps**: Critical areas not explicitly covered in either framework, including behavioral anomaly detection, code leak prevention, least privilege enforcement to stop lateral movement, and unpatched dependency management.

### Technical Details - **NIST Guidelines and Principles**: NIST SSDF version 1.1 focuses on defining critical software, conducting static and dynamic analysis (including fuzzing and structural testing), threat modeling, and consuming Software Bills of Materials (SBOMs). Related publications include NIST SP 800-161 and SP 800-53 (security and privacy controls for information systems). - **SLSA Level Breakdown**: - *Level 0*: No security guarantees. - *Level 1*: Fully scripted build processes that generate provenance. - *Level 2*: Version control usage and a hosted build service generating authenticated provenance. - *Level 3*: Auditable source control and build platform integrity with retention of build logs and source (minimum 18 months, ideally indefinite). - *Level 4*: Highest rigor, requiring two-person code reviews for all changes and hermetic, reproducible build processes. - **SLSA Requirement Categories**: Source requirements (MFA authentication, verified history), build requirements (isolation, hermeticity), provenance generation, provenance content (builders, artifacts, source, transitive dependencies), and common requirements (access controls, super user governance). - **Shared Best Practices and Gaps**: Both frameworks emphasize hard-coded secret scanning across source, builds, and registries, along with configuration inventory and drift prevention. However, both lack explicit mandates for anomaly detection (such as abnormal geographical logins or mismatched public Kubernetes deployments originating from private repositories) and proactive containment of lateral movement.

### Takeaways - **Tiers vs. Levels**: While organizations must weigh business friction and overhead when determining their target tier in the NIST SSDF (as tier 4 is not necessary for every non-critical organization), all software teams should aspire to advance through the progressive milestones toward SLSA Level 4. - **Addressing Common Root Causes**: Approximately 60% of recent breaches exploited an unpatched dependency that already had a known fix, underscoring that updating dependencies remains one of the most effective security mitigations. - **Compliance and Open Source**: Adopting these frameworks enables teams to generate attestations and provenance as policy-as-code to prove due diligence to downstream customers. For open-source maintainers, SLSA offers an accessible, step-by-step technical rubric, while NIST SSDF provides high-level organizational and risk-management context.