FOR DISCUSSION Security policy: rework proposal

Rework the Policy to take define relations between the EF Security team, (as a part of EMO), Project's Security team (introduced in a related proposal). Remove the Security Team as it becomes redundant. Clarify disclosure process and timeline.

Rename the Polict to Security Policy as it covers more than vulnerability reporting.

Signed-off-by: Marta Rybczynska marta.rybczynska@eclipse-foundation.org

security-policy.adoc

@@ -9,20 +9,22 @@
 ////
 
 [[security]]
-= Eclipse Foundation Vulnerability Reporting Policy
-
-Version 1.1 February 4/2020
+= Eclipse Foundation Security Policy
+Version 1.2 August ../2024
 
 [[security-overview]]
 == Overview
 
-The purpose of the Eclipse Vulnerability Reporting 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 Vulnerability Reporting Policy applies to all software distributed by the Eclipse Foundation, including all software authored by Eclipse Committers and third-parties. This Eclipse Vulnerability Reporting 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 {bylawsUrl}[Eclipse Foundation Bylaws] and the {edpUrl}[Eclipse Foundation Development Process].
+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 {bylawsUrl}[Eclipse Foundation Bylaws] and the {edpUrl}[Eclipse Foundation Development Process].
 
 [[security-terms]]
 == Terms
 
-Security Team ::
-The Security Team, or "Eclipse Security Team" is the team tasked with security and Vulnerability management on behalf of the Eclipse community.
+Eclipse Foundation Security Team ::
+The "Eclipse Foundation Security Team" or "EF Security Team" is a part of EMO tasked with security and Vulnerability coordination and management on behalf of the Eclipse community.
+
+Project's Security Team ::
+A "Project's Security Team" is the team from a particular Project tasked with security and Vulnerability management for that Project.
 
 Vulnerability ::
 This policy uses the ISO 27005 definition of Vulnerability: "A weakness of an asset or group of assets that can be exploited by one or more threats."
@@ -30,63 +32,76 @@ This policy uses the ISO 27005 definition of Vulnerability: "A weakness of an as
 Other terms used in this document are defined in the {edpUrl}[Eclipse Foundation Development Process].
 
 [[security-team]]
-== Eclipse Security Team
+== Eclipse Foundation Security Team
+
+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 Eclipse Security Team is the first line of defense: it is effectively a triage unit with security and Vulnerability management expertise. The Security Team exists to provide assistance; Vulnerabilities are addressed and resolved by project committers with guidance and assistance from the Security Team.
+== Project's Security Team
 
-The Security Team is composed of a small number of security experts and representatives from the Project Management Committees. All members are appointed by EMO(ED) or their designate.
+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.
 
 [[security-discussion]]
 == Discussion
 
-The Eclipse Foundation is responsible for establishing communication channels for the Security Team.
+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.
 
-Every potential issue reported on established communication channels should be triaged and relevant parties notified. Initial discussion of a potential Vulnerability may occur privately amongst members of the project and Security Team. Discussion should be moved to and tracked by an Eclipse Foundation-supported issue tracker as early as possible once confirmed so the mitigation process may proceed. Appropriate effort must be undertaken to ensure the initial visibility, as well as the legitimacy, of every reported issue.
+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.
 
 [[security-resolution]]
 == Resolution
 
-A Vulnerability is considered resolved when either a patch or workaround is available, or it is determined that a fix is not possible or desirable.
+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 left to the discretion of the Security Team and Project Leadership Chain to determine what subset of the project team are best suited to resolve Vulnerabilities. The Security Team and project leaders may also--at their discretion--assemble external resources (e.g. subject matter experts) or call on the expertise of the Eclipse Architecture Council.
+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 disclosed Vulnerability, an Eclipse Foundation member may--at their discretion--engage in the Grievance Process as defined by the {edpUrl}[Eclipse Foundation Development Process].
+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 {edpUrl}[Eclipse Foundation Development Process].
 
 [[security-distribution]]
 == Distribution
 
-Once a Vulnerability has been resolved, the updated software must be made available to the community.
+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.
 
 [[security-disclosure]]
 == Disclosure
 
-Disclosure is initially limited to the reporter and all Eclipse Committers, but may be expanded to include other individuals.
+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.
 
-All Vulnerabilities must be disclosed, regardless of the resolution. Users and administrators of Eclipse software must be made aware that a Vulnerability exists so they may assess risk, and take the appropriate action to protect their users, servers and systems from potential exploit.
+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.
 
 [[security-timing]]
 === Timing
 
 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:
 
-* Vulnerabilities for which there is a patch, workaround or fix, should be disclosed to the community immediately; and
-* Vulnerabilities--regardless of state--must be disclosed to the community after a maximum three months.
+* Resolved Vulnerabilities are disclosed immediately after a release containing those fixes is available;
+* Projects are expected to resolve a Vulnerability in no more than three months; this delay might be extended by the Project Leadership Chain together with the Eclipse Foundation Security team if appropriate;
+* The Project Leadership Chain with the guidance of the Eclipse Foundation Security Team might disclose earlier if necessary;
 
-Vulnerabilities need not necessarily be resolved at the time of disclosure.
+All Vulnerabilities must be eventually disclosed.
 
 [[security-quiet-disclosure]]
 === Quiet Disclosure
 
-A Vulnerability may be _quietly_ disclosed by simply removing visibility restrictions.
+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 committer as having been erroneously marked as Vulnerabilities.
+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.
 
 [[security-progressive-disclosure]]
 === Progressive Disclosure
 
-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 committer--be disclosed to specific individuals. A committer may, for example, provide access to a subject-matter expert to solicit help or advice. A Vulnerability may also be disclosed to known adopters to allow them an opportunity to mitigate their immediate risk and prepare for a forthcoming resolution.
+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.
 
 [[security-full-disclosure]]
 === Full Disclosure
@@ -98,6 +113,6 @@ To complete the disclosure of a Vulnerability, all restrictions on visibility mu
 [[security-reporting]]
 === Reporting
 
-A project team may, at their discretion, opt to disclose a Vulnerability to a reporting authority.
+A Project's Security Team may, at their discretion, opt to disclose a Vulnerability to a reporting authority.
 
-The EMO will determine how to engage with Vulnerability reporting authorities.
+The EF Security Team will determine how to engage with Vulnerability reporting authorities.