[eclipse.org-committers] Vulnerabilities and responsible disclosure

[Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>]

Greetings Eclipse Committers,

The Eclipse Foundation has a policy regarding the resolution and responsible disclosure of identified vulnerabilities. The short version is that this is one of the rare areas where open source transparency and openness ideals may be curtailed for a period of time while a vulnerability is addressed privately; but that all identified vulnerabilities, regardless of whether or not they are fixed, must be disclosed after no more than three months.

Common Vulnerabilities and Exposures (CVE) is a means of reporting publicly known cybersecurity vulnerabilities. The Eclipse Foundation is a CVE Numbering Authority (CNA), which means that we have the means to report vulnerabilities for dissemination by a central authority. 

It is left to individual project teams to determine whether or not an identified vulnerability should be reported as a CVE. My advice is that if there is potential that anybody currently using your project's software is potentially impacted by the vulnerability, it should be reported. If you can categorize and describe the vulnerability, it should be reported. This is true whether or not the vulnerability has been fixed. This is true whether or not the vulnerability is exposed by the project code itself or by configuration. If you'd like some help, send a note to security@xxxxxxxxxxx and the Security Team will try to help.

We need the project team's engagement because reporting vulnerabilities is a big deal. We depend on project teams to draft a description of the issue, categorize it, and identify versions that are impacted. But more fundamentally, we depend on the project team to determine that a report of a vulnerability identified in their code is accurate. Frankly, we need to have confidence that the description of a vulnerability is not misleading.

The tools that a project team opts to leverage while addressing a vulnerability is left to their discretion. The Eclipse Foundation's Bugzilla instance has a means of marking individual records as "committers-only" to limit visibility; you can use this feature to capture discussions regarding mitigation if you'd like. Both GitHub and GitLab have features that make it possible to work in semi-privacy as well. Per the policy, regardless of what channels your team chooses to use to mitigate the issue, they must eventually be opened for public scrutiny. 

Regardless of the channel you choose to discuss mitigation of a vulnerability, you need to use the Eclipse Foundation's Bugzilla to request that we assign a CVE (if you're using a Bugzilla record as the discussion channel, you can add emo@xxxxxxxxxxx in copy and request a CVE on the existing record). The handbook describes the information that we need to create the CVE. You don't have to get the request exactly right the first time; the EMO will work with you to get the information that we need to make a good report.

Note that, in the past, due to the way in which CVEs were assigned to CNAs in blocks, we were unable to assign actual CVE numbers until the time to disclose was imminent. The manner in which CVEs are reserved as changed, so we now have greater flexibility in timing. That said, it is still our strong preference to wait to assign a CVE until you are almost completely ready for disclosure.

You can use this list or contact me directly if you have any questions. By way of expectation management, since this list has a rather large distribution, I may direct certain conversations to other channels.

Wayne

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation