Securing InnerSource
summary
OpenSSF tools can be repurposed for inner source by threat modeling concrete risks: no external scrutiny, insider malicious actors, transitive trust through internal dependencies (example: a single npm add can pull ~500 packages), overly broad write/read access, departed maintainers, and tooling gaps. Practical adaptations include using Security Scorecards (CLI run, manual triage into a roadmap across five client engagements), SLSA attestations for signed build artifacts, and enterprise-fed vulnerability feeds instead of public OpenCVE. The low-tech manual process proves effective.
AI-written summary · about
chapters (7)
- 0:00Introduction to InnerSource security
- 1:52Threats to InnerSource projects
- 6:53Open source security tools
- 10:25Scorecard for security metrics
- 13:57Adapting tools to InnerSource
- 15:45Implementing security practices
- 18:13Q&A and closing remarks
related talks
41mBack to Security Basics: Evaluating, Consuming, and Contributing Open Source...
57mFrontiers in Securing the Open Source Ecosystem
42mDeveloping a Secure, Open Future
42mAssessing the Risk of Open-source Components Using OpenSSF's Scorecard
20mBuilding Secure Software OpenSSF Best Practices for Everyone!
44mSecuring Open Source Software - End-to-End, at Massive Scale, Together
37mSecuring Open Source Through Threat Modeling
37mOpenSSF Best Practices for Everyone!