Vulnerability Reporting Policy | Eclipse Foundation | The Eclipse Foundation

Version 1.2 November 20/2024
The purpose of the Eclipse Foundation Security Policy is to set forth the general principles under which the Eclipse Foundation manages the reporting, management, discussion, and disclosure of Vulnerabilities discovered in Eclipse software. This Security Policy applies to all software developed and distributed by the Eclipse Foundation, including all software authored by Eclipse Committers and third-parties. This Eclipse Security Policy should at all times be interpreted in a manner that is consistent with the Purposes of the Eclipse Foundation as set forth in the Eclipse Foundation Bylaws and the Eclipse Foundation Development Process.
Other terms used in this document are defined in the Eclipse Foundation Development Process.
The Eclipse Foundation Security Team is the first line of defense: they triage reports, redirect them to the appropriate Project’s Security team or the EMO team, provide assistance and guidance in the resolution.
The EF Security Team is composed of a small number of security experts and is a part of EMO. The EF Security Team does not resolve Vulnerabilities; Vulnerabilities are addressed and resolved by Project’s Security Team and Committers with guidance and assistance from the EF Security Team.
The Project’s Security Team is responsible for coordinating the resolution of Vulnerabilities within the Project. By default, the Project’s Security Team includes all Committers. However, the Project may choose a different arrangement and establish specific criteria for team nominations
The Project’s Security Team might require guidance and help from the EF Security Team, notably in cases when a synchronization between multiple Projects’ Security Teams is necessary.
The EMO will, upon request from a Project Security Team’s, allocate a confidential channel for discussing undisclosed Vulnerabilities. Confidential channels must only be used for communication on details of a resolution of an undisclosed Vulnerability. Discussions about disclosed Vulnerabilities should take place on public channels.
The Project’s Security Team is closely collaborating with the Eclipse Foundation Security Team. Therefore, the Project’s Security Team shall immediately communicate their preferred method of communication to the Eclipse Foundation Security Team upon creation and keep them updated on any changes.
The Eclipse Foundation is responsible for establishing communication channels for the Eclipse Foundation Security Team and for Projects’ Security Teams, as appropriate.
Every potential issue reported through established communication channels should be triaged, and relevant parties notified. Initial discussions of a potential Vulnerability may occur privately between the Project’s Security Team and the EF Security Team. Once confirmed, the discussion should be moved to and tracked by an Eclipse Foundation-supported issue tracker as early as possible to allow the mitigation process to proceed. Appropriate effort must be made to ensure the visibility and legitimacy of every reported issue from the outset.
If there is a difference of opinion between the individual reporting the potential issue, the Project’s Security Team, and the EF Security Team regarding the classification of the issue as a Vulnerability, the Eclipse Foundation Security Team will provide the final classification.
A Vulnerability is considered resolved when a fix or workaround is available, or when it is determined that a fix is not possible or desirable. If no fix or workaround is available, a risk analysis must be provided. All Vulnerabilities must be resolved.
It is at the discretion of the Project’s Security Team and Project Leadership Chain to determine what subset of the committers are best suited to resolve Vulnerabilities. The Project’s Security Team may also–at their discretion–assemble external resources (e.g. subject matter experts) or seek the expertise of the EF Security Team.
In the unlikely event that a project team does not engage in good faith to resolve a Vulnerability, an member of EMO may–at their discretion–initiate the Grievance Process as defined by the Eclipse Foundation Development Process.
Once a Vulnerability is resolved, the updated software must be made available to the community. This updated software should be either a regular or a service release.
At a minimum, updated software must be made available via normal project distribution channels.
The information on the Vulnerability is initially limited to the reporter, Project’s Security Team, and EF Security Team, but may be expanded to include other individuals.
It is strongly recommended that public disclosure occurs immediately after a bugfix release is available. In all cases, users and administrators of Eclipse Projects software must be informed of any Vulnerability so they can assess the risk and take appropriate action to protect their users, servers, and systems from potential exploits.
The timing of disclosure is left to the discretion of the Project Leadership Chain. In the absence of specific guidance from the Project Leadership Chain, the following guidelines are recommended:
All Vulnerabilities must be eventually disclosed.
A Vulnerability may be quietly disclosed by simply removing visibility restrictions and documenting a risk analysis or providing the reasoning for not considering it a Vulnerability.
In general, quiet disclosure is appropriate only for issues that are identified by a Project’s Security Team as having been erroneously marked as Vulnerabilities or Vulnerabilities with low severity and when exploitation is highly unlikely.
Knowledge of a Vulnerability can be extended to specific individuals before it is reported to the community. A Vulnerability may–at the discretion of the Project’s Security Team–be disclosed to specific individuals. Project’s Security Team may, for example, provide access to a subject-matter expert to solicit help or advice.
All Vulnerabilities must eventually be fully