Supply-Chain Security, Outside in: What Helping ~200 Projects Improve Their Security Looks Like
summary
Google’s open source security team targets ~200 critical projects using OSS-F criticality and Scorecard to prioritize work, makes 455 contributions focused on code-based quick wins (minimizing GitHub workflow permissions, adding security policies, hash-pinning, suggesting provenance and safer publish flows), and lands 90% accepted PRs. Projects move from the 40th percentile to the top ~11th percentile by Scorecard ranking, showing measurable improvement; work relies on human-led outreach, so it improves security effectively but does not scale without broader ecosystem support.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 1:50Physical supply chains origins
- 3:58Software supply chain failures
- 6:48Key differences from physical chains
- 9:15Security by default limitations
- 11:22Contributing to open source security
- 13:27Guiding principles for contributions
- 17:01Results of the year-long effort
- 20:57Impact measured by scorecard
- 22:22Limitations of the approach
- 23:24Call to action for viewers
- 25:29Handling unresponsive projects
- 27:16Iterating on the approach
- 29:48Prioritizing maintainer-friendly changes
- 31:23Why this work started
- 33:27Bridging tooling adoption gaps
- 34:31Timeline of contributions
- 35:13Conclusion and Q&A
related talks
11mSupply Chain Cybersecurity
44mOpen Source Security: The World Needs Our Help
41mBack to Security Basics: Evaluating, Consuming, and Contributing Open Source...
44mSecuring Open Source Software - End-to-End, at Massive Scale, Together
07mHow to Secure Your End-to-end Supply Chain
52mCollaborating to Improve Open Source Security: How the Ecosystem Is Stepping Up
43mThe Importance of Developer Tooling to Make Open Source More Secure by Default- 41mBack to Security Basics: Evaluating, Consuming, and Contributing Open Source...