Panel Discussion: Handling vulnerability reports in Apache Solr
summary
Solr PMC handles a handful of vulnerability reports a year, routes initial reports to security@apache.org or security@solr.apache.org, assesses CVE-worthiness, tracks work in a private JIRA, and only announces a fix together with the CVE and a release. Recent practice includes backports (examples: 8.8.2 and even 7.7.x maintenance releases), triage of noisy scanner output (Black Duck/OSS scanners) via a dependency wiki, and hard lessons from the XML config/API incident that forced process and “secure by default” discussions.
AI-written summary · about
chapters (17)
- 0:00Introduction to panel
- 2:18Scale and criticality of Solr
- 5:34Frequency of vulnerability reports
- 7:59Reporting process for vulnerabilities
- 11:07CVE-worthiness assessment
- 14:58Handling grey-area reports
- 20:14Public exposure of non-CVE issues
- 21:59Handling improper reports
- 25:57Backporting security fixes
- 28:02Communicating fixes to users
- 31:14Dependency vulnerabilities
- 32:57Internal handling of vulnerabilities
- 38:54Handling reports from users
- 41:42Timing of vulnerability announcements
- 43:09Policies for dependency CVEs
- 46:57Challenges with vulnerability scanners
- 48:41Final thoughts on security posture
related talks
37mOSS Security: Lessons from 10+ Years at Apache Solr
48mHow to report a vulnerability: Responsible Disclosure for Developers
27mThrough the Looking Glass: How Open Source Projects See Vulnerability Disclosure
29mThe maintainability of open source code 20 years from today
27mSecurity: The Thing That Everyone...
30mEffective Vulnerability Management for Over 400 Projects at the Eclipse Foundation
05mKeynote: OpenSearch, Open Security: Bringing Transparency to Our Security Processes
59mWho’s Vulnerability Is It Anyway? Harmonizing Stakeholder Roles in Vulnerability Management