Through the Looking Glass: How Open Source Projects See Vulnerability Disclosure
summary
Open source projects typically reply in five concrete ways: fixed in release, not a security issue, needs testing, submit a patch, or we do not issue CVEs. Causes are poor repro steps and noisy false positives (maintainers report getting ~15 useless reports at once), lack of security training, and maintenance overload across 400 projects. Practical fixes that show measurable improvement: migrate reporting to GitHub/GitLab, add SECURITY.md files, run developer security workshops, build tooling to enforce branch protection and translate reports; these changes reduce confusion and increase confirmed fixes.
AI-written summary · about
chapters (8)
- 0:00Introduction to disclosure
- 1:25Audience and speaker background
- 2:44Project context
- 3:41Analyzing response scenarios
- 14:38Challenges in open source
- 17:25Improving project security
- 21:07Advice for researchers
- 23:57Conclusion and Q&A
related talks
44mPreparing for Zero-Day: Vulnerability Disclosure in Open Source Software
49mImproving FOSS Security
39mOpen source security: who’s responsible?
45mSimplifying Coordinating Vulnerabilities & Disclosures in Open Source...
48mHow to report a vulnerability: Responsible Disclosure for Developers
01h 08mPreparing for Zero-Day: Vulnerability Disclosure in Open Source Software
31mA Glimpse Into OSS Vulnerability Disclosure Practices
48mImproving the Security of a Large Open Source Project One Step...