Improving FOSS Security
summary
Open source projects must write a security policy and publish a private contact route, reserve CVE IDs early, and use GitHub’s private vulnerability reporting so embargoed work doesn’t leak. Use fuzzers and static analyzers, run npm audit, and prefer patches that are small, test-covered and backportable with the CVE in the commit. Real results: Vim’s bounty surfaces ~130 bugs in a year (roughly half get CVEs); failing to assign CVEs (Kitty) breaks distro patching.
AI-written summary · about
chapters (12)
- 0:00FOSS security fundamentals
- 7:23CVE assignments and metadata
- 10:13Effective security policy
- 12:47Vulnerability reports handling
- 16:18Coordinated vulnerability disclosure
- 20:32Security policies for downstream
- 27:08Reserving CVEs and cooperation
- 31:05Researcher reporting and tracking
- 35:01Bug bounties expectations
- 37:15OpenSSF vulnerability resources
- 41:13Trust in supply chains
- 47:15Building trust in security networks
related talks
48mImproving the Security of a Large Open Source Project One Step...
52mCollaborating to Improve Open Source Security: How the Ecosystem Is Stepping Up
27mThrough the Looking Glass: How Open Source Projects See Vulnerability Disclosure
35mOpen source security: Opportunity or oxymoron?
39mOpen source security: who’s responsible?
37mBringing Security to Your Open Source Project
16mPerformance improvements: exposing hidden security fixes in Open Source
47mImproving the Security of a Large Open Source Project One Step at a Time