Software Supply Chain Security: Provenance, Transparency, and Context Slides

Transcript

1. Secure Software Supply Chain Challenges
2. Source Build Package Run Deploy Software supply chain Dependency
3. Source Build Package Run Inject bad code Compromise source control Build from modified source Compromise build system Compromised/ vulnerable dependency (includes build toolchains) Bypass CI/CD, inject bad artifact Compromise package repo/signing Use compromised package Deploy Compromise Deploy Process Deploy compromised image Vulnerability discovered post-deployment Software supply chain attack vectors Dependency
4. Source Build Package Run Inject bad code Compromise source control Build from modified source Compromise build system Compromised/ vulnerable dependency (includes build toolchains) Bypass CI/CD, inject bad artifact Compromise package repo/signing Use compromised package Deploy Compromise Deploy Process Deploy compromised image Vulnerability discovered post-deployment Software supply chain attack vectors Dependency
5. % Surge in OSS supply chain attacks 1 % Commercial code bases have OSS vulnerabilities 2 % of organizations worldwide will have experienced attacks on their software supply chains by 2025 3 81 45 742 Increasingly, the software development lifecycle (SDLC) itself has become a vector for attacks. The recent Log4J, SolarWinds, Kaseya, and Codecov hacks highlight vulnerable surface areas exposed in the SDLC. 1. Sonatype, 2023 - State of the Software Supply Chain 2. Synopsys, 2022 - Open Source Security and Risk Analysis Report 3. Gartner, 2021 - How Software Engineering Leaders Can Mitigate Software Supply Chain Security Risks 4. IDC, 2022 - IDC FutureScape: Worldwide Developer and DevOps 2022 Predictions % in response to the above, by 2024, 55% of organizations will demand DevOps pipeline security to secure the software supply chain to lower the risk of compromise 4 55 Supply chain attacks are increasingly successful
6. Supply chain security challenges OSS Proliferation CI/CD Automation Many attack vectors Standards / Tools Nearly all commercial code relies on OSS Unknown contributors expand supply chain Increased number of attack vectors Exposure level evolve, difficult to understand Growing number and of emerging standards Lack of end-to-end solutions Modern dev increase deployment frequency Lack of security automation Base image proliferation
7. Secure Software Supply Chain Concepts
8. S3C concepts What’s the content of the artifact? packages, libraries, their versions and provider, and the relationships between them How and where was the artifact created? source code, tools, build system, and individuals involved in its development Is my software artifacts impacted? what is the potential impact of each one of the vulnerabilities in my software transparency provenance context
9. Secure Software Supply Chain Transparency
10. Transparency: Software Bill of Materials (SBOM) Ingredients: Organic Tomato Purée, Filtered Water, Organic Cream, Organic Cane Sugar, Organic Anions, Sea Salt, Black Cracked Pepper Some Soup Company Somewhere, USA
11. Transparency: SBOM cisa.gov/sbom SPDX v2.3 document shall contain SPDX v2.3 document may contain SPDX document creation information Package information File information Snippet information Other licensing information detected Relationship between SPDX elements information Annotation information Review information Software Bill of Materials SBOM Drivers: When producing software: • License compliance • Vulnerability monitoring When selecting software: • Targeted security analysis • Policy compliance When operating software • Risk management • Independent mitigations
12. Transparency: SBOM Software Bill of Materials Cyber Resilience Act - CRA Supply Chain Security and actors’ responsibilities (detection, reporting, mitigation) U.S. Executive Order on Improving the Nation’s Cybersecurity EO 14028 (Project plan with timeline) Supply Chain Security including SBOM Guidance on Supply Chain Security, under EO 14028 Section 4c/4d Network and Information Security Directive - NIS2 (Supply Chain Security, Incident Management including reporting (CVD)) May 12, 2021 May 5, 2022 Jan 16, 2023 Jan 23, 2023 Oct 18, 2024 NIS2 national laws Dec 15, 2020 NIS2 prop. EO 14028 NIS2 CRA RFC closed EO 14028 guidance Supply chain security guidance Supply chain mapping guidance
13. Transparency: SBOM Software Bill of Materials “ By 2026, >60% of organizations procuring mission-critical software solutions will mandate SBOM disclosures — Gartner Strategic Planning Assumptions
14. SBOM: Solutions Software Bill of Materials From Artifact OSS generation tools (e.g. syft, snyk) can generate either SPDX or CycloneDX formatted SBOM from artifact (container image) From Source On-demand generated from the lockfile (e.g. go.mod, pom.xml, or package-lock.json in GitHub) During Build Generated during build process by the tool creating the actual artifact (e.g. ko for Go and jib for Java)
15. Transparency: SBOM Ingredients: Organic Tomato Purée, Filtered Water, Organic Cream, Organic Cane Sugar, Organic Anions, Sea Salt, Black Cracked Pepper Some Soup Company Somewhere, USA
16. Transparency: SBOM Ingredients: Tomato Paste, Water, High Fructose Corn Syrup, Salt, Partially Hydrogenated Soybean Oil, Artificial Flavoring, Red Dye 40 Some Soup Company Somewhere, USA
17. Secure Software Supply Chain Provenance
18. Provenance Verifiable attestation to the: Source of the ingredients Growing location Delivery mechanism Length of storage Preparation process … Ingredients: Organic Tomato Purée, Filtered Water, Organic Cream, Organic Cane Sugar, Organic Anions, Sea Salt, Black Cracked Pepper Some Soup Company Somewhere, USA
19. Provenance: SLSA framework Supply Chain Levels for Software Artifacts slsa.dev Open Source Security Framework Standardized check-list of controls to improve integrity, prevent tampering, and secure software artifacts and infrastructure Externalization of internal framework Based on Google’s long-standing internal framework Open Governance 7 person steering committee, 4 working groups, 30+ company contributor community, under OpenSSF (Linux Foundation)
20. Builders produce, conformant and signed, provenance document (aka build attestation) Provenance document includes Build Definition (e.g. parameters, dependencies), and Run Details (e.g. builder, metadata). To make it easier to reason about it, key characteristics of the build provenance are grouped into SLSA Levels Downstream consumers can inspect the provenance, and implement policy decisions based on the inferred level Provenance: SLSA in Practice slsa.dev
21. Protection against How SLSA L0 None SLSA L1 None, but getting started Scripted build, with provenance SLSA L2 Tampering after the build Build service and signed provenance SLSA L3 Tampering during or after the build Hardened build service, isolation SLSA L4 Tampering before, during, or after the build Require two-person code review and hermetic builds Supply Chain Levels for Software Artifacts Provenance: SLSA Build Levels slsa.dev Note: Level 4 has been removed from SLSA v1.0 spec
22. Cloud Build Level 3 assurance automatically generated in Artifact Analysis for all images pushed to Artifact Registry GitHub Actions Reusable workflow generates build provenance, meets Level 3 requirements. Works in conjunction with Sigstore cosign to create a verifiable In-totto attestation in image registry. GitLab CI/CD GitLab Runner generates artifact metadata meeting SLSA Level 2, support external code signer to potentially deliver Level 3. Provenance: Solutions slsa.dev
23. Secure Software Supply Chain Context
24. Context: VEX cisa.gov Vulnerability Exploitability eXchange • Software can contain components with a vulnerability and yet not be vulnerable itself • VEX provides context for the vulnerabilities found in software using its impact statements VULNERABILITY X [AFFECTS | DOES NOT AFFECT] SOFTWARE Y [BECAUSE OF …]
25. Impact: Solutions Software Bill of Materials Open Source Standards & Tooling Evolving formats with various levels of maturity (e.g. Common Security Advisory Framework, CycloneDX, OpenVEX).
26. Generate SBOM, understand its content Gain knowledge and control over your software inventory Understand primary and transitive dependencies Discover CVEs, manage their risks Understand reachability and exploitability Protect against pipeline and distribution risks with provable integrity Enforce least privilege access Ensure everything has Identity Use binary authorization policy Create tamper evident provenance Ensure access transparency Limit exposure, blast radius Manage upstream dependencies, and automate remediation of new issues Control admission to runtime Create org-level policies to gate admission to production Generate attested evidence of compliance S3C: Practical Steps