<div dir="ltr">An idea that occurred to me last year, after <a href="https://geoserver.org/behind%20the%20scenes/2022/01/20/log4j-upgrade.html">successful running a fundraising effort</a> in response to log4j security issues, was that ... 2022 was terrible.<div><br></div><div>The second idea was that we could help OSGeo projects respond more quickly and professionally in the future.</div><div><br></div><div>With this in mind I would like to propose an "osgeo security initiative" with very limited emergency scope.</div><div><br></div><div>1. Projects apply when faced with an emergency in a fashion similar to the code-sprint initiative</div><div>2. Projects would require registration of a formal CVE number for the vulnerability (in practice security researchers register these numbers on a project's behalf.)</div><div>3. Projects would require a clear budget for the request (standard practice just like a code sprint or event)</div><div>4. Challenge: Some secure channel is required for this communication because mean people exist </div><div>5. Challenge: Funding for preventative measures is not supported to limit scope of this initiative</div><div><br></div><div>If done correctly the initiative can raise funds as more organizations are sensitive to the security of the open-source components they have come to depend on. Ideally it can also be an outreach opportunity to engage with security professionals. </div><div><br></div><div>I have added this topic to both the <a href="https://wiki.osgeo.org/wiki/Board_Meeting_2023-01-30">upcoming meeting</a> and <a href="https://wiki.osgeo.org/wiki/OSGeo_Budget_2023#OSGeo_Initiatives">2023 budget</a>.</div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--</div><div>Jody Garnett</div></div></div></div></div></div></div></div>