Update the security (vulnerability reporting) policy.
Change-Id: Ic7419a64a0b676688514078e40db1c072ebb9eb7
diff --git a/content/en_index.php b/content/en_index.php
index eb39527..2d3605d 100644
--- a/content/en_index.php
+++ b/content/en_index.php
@@ -48,7 +48,7 @@
</p>
<h2>The Eclipse Security Team</h2>
<p>The Eclipse Security Team provides help and advice to Eclipse
- projects on security issues and is the first point of contact for
+ projects on vulnerability issues and is the first point of contact for
handling security vulnerabilities. Members of the Security Team are
committers on Eclipse Projects and members of the Eclipse
Architecture Council.
diff --git a/content/en_policy.php b/content/en_policy.php
index ebe729d..70a51ec 100644
--- a/content/en_policy.php
+++ b/content/en_policy.php
@@ -1,6 +1,6 @@
<?php
/**
- * Copyright (c) 2011, 2015, 2018 Eclipse Foundation and others.
+ * Copyright (c) 2011 Eclipse Foundation and others.
*
* This program and the accompanying materials are made
* available under the terms of the Eclipse Public License 2.0
@@ -13,191 +13,341 @@
* SPDX-License-Identifier: EPL-2.0
*/
?>
-<a name="Overview"></a>
-<h2>Overview</h2>
-<p>The purpose of the Eclipse Security Policy is to set forth the
- general principles under which the Eclipse Foundation will manage the
- reporting, management, discussion, and disclosure of Vulnerabilities
- discovered in Eclipse software. This Security Policy applies to all
- software distributed by the Eclipse Foundation, including all
- software authored by Eclipse Committers and third-parties. This IP
- 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.
-</p>
-<p>The document 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."
-</p>
-<p>This document uses terms from the <a
- href="http://www.eclipse.org/projects/dev_process/development_process.php"
- class="external text"
- title="http://www.eclipse.org/projects/dev_process/development_process.php"
- rel="nofollow">Eclipse Development Process</a>.
-</p>
-<a name="Eclipse_Security_Team"></a>
-<h2>Eclipse Security Team</h2>
-<p>The Security Team is the first line of defense: it is effectively a
- triage unit with security expertise. Ultimately, Vulnerabilities are
- resolved by individual projects with assistance from the Security
- Team.
-</p>
-<p>The Security Team is composed of a small number of security
- experts. At any point in time, there are no more than seven (7)
- members, including a minimum of one representative each from the
- Eclipse and RT Top-Level Projects, and a representative of the
- EMO(ED). All members are appointed by EMO(ED).
-</p>
-<p>Mail sent to the security mail address is sent exclusively to all
- members of the Security Team. Anybody can send mail to this address.
-</p>
-<a name="Reporting"></a>
-<h2>Reporting</h2>
-<p>Vulnerabilities can be reported either via email or directly with a
- project via Bugzilla.
-</p>
-<p>The general security mailing list address is security@eclipse.org.
- Members of the Eclipse Security Team will receive messages sent to
- this address. This address should be used only for reporting
- undisclosed Vulnerabilities; regular issue reports and questions
- unrelated to Vulnerabilities in Eclipse software will be ignored.
- Note that this email address is not encrypted.
-</p>
-<p>The community is encouraged to report Vulnerabilities using the
- standard Eclipse Bugzilla instance. Issue reports related to
- Vulnerabilities must be marked as "committers-only", either by the
- reporter, or by a committer during the triage process.
-</p>
-<p>Note that issues marked "committers-only" are visible to all Eclipse
- committers. By default, a "committers-only" issue is also accessible to
- the reporter and individuals explicitly indicated in the "cc" list.
- These defaults can be overridden to further restrict access at the
- discretion of the committer and project leadership.
-</p>
-<dl>
- <dd>
- <i>Note that Bugzilla sends out emails as issues are modified. Email
- is inherently insecure.</i>
- </dd>
-</dl>
-<a name="Discussion"></a>
-<h2>Discussion</h2>
-<p>Initial discussion of an open Vulnerability may occur privately
- amongst members of the Security Team. Discussion should be moved to a
- Bugzilla record in a timely manner.
-</p>
-<a name="Resolution"></a>
-<h2>Resolution</h2>
-<p>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.
-</p>
-<p>The Eclipse IP Team will give priority to contribution
- questionnaires (CQs) required to resolve Vulnerabilities.
-</p>
-<p>It is left to the discretion of the Security Team and project
- leadership to determine what subset of the project committers 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 Architecture Council.
-</p>
-<a name="Distribution"></a>
-<h2>Distribution</h2>
-<p>Once a Vulnerability has been resolved, the updated software must
- be made available to the community.
-</p>
-<p>At a minimum, updated software is made available via normal project
- distribution channels (e.g. downloads and update sites).
-</p>
-<p>The Eclipse Planning Council must be made aware of Vulnerabilities in
- software that is part of the simultaneous release. The Eclipse Planning
- Council will determine whether or not a "respin" of the simultaneous
- release repository and EPP packages is required. The Eclipse Planning Council
- will coordinate the timing of the "respin" with the Project
- Leadership.
-</p>
-<a name="Disclosure"></a>
-<h2>Disclosure</h2>
-<p>Disclosure is initially limited to the reporter and all Eclipse
- Committers, but can be expanded to include other individuals.
-</p>
-<p>All Vulnerabilities must be disclosed, regardless of the
- resolution. Users and administrators of Eclipse software must made
- aware that a vulnerability exists so they can assess risk, and take
- the appropriate action to protect their users, servers and systems
- from potential exploit.
-</p>
-<a name="Timing"></a>
-<h3>Timing</h3>
-<p>The timing of disclosure is left to the discretion of the project
- leadership, including the Project Lead(s), PMC, and EMO(ED). In the
- absence of specific guidance from the project leadership, the
- following guidelines are recommended:
-</p>
-<ul>
- <li>Vulnerabilities for which there is a patch, workaround or fix,
- should be disclosed to the community immediately.
- </li>
- <li>Vulnerabilities—regardless of state—must be disclosed to the
- community after a maximum three months.
- </li>
-</ul>
-<p>Vulnerabilities need not necessarily be resolved at the time of
- disclosure.
-</p>
-<a name="Quiet_Disclosure"></a>
-<h3>Quiet Disclosure</h3>
-<p>
- A Vulnerability can be <i>quietly</i> disclosed by simply removing
- the 'committers_only' flag. The issue's history will record that the
- flag has been removed, and the issue will become visible for everyone
- in searches.
-</p>
-<p>In general, quiet disclosure is appropriate only for issues that are
- identified by a committer as having been erroneously marked as
- Vulnerabilities.
-</p>
-<a name="Progressive_Disclosure"></a>
-<h3>Progressive Disclosure</h3>
-<p>Knowledge of a Vulnerability can be easily extended to individuals
- by adding them to the "cc" list on the issue. 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. The Vulnerability
- may also be disclosed to known adopters to allow them an opportunity
- to mitigate their immediate risk and prepare for a forthcoming
- resolution.
-</p>
-<p>Contacts added to an unresolved Vulnerability must be individuals.
- Groups (e.g. mailing lists)--with the exception of
- security@eclipse.org--should never be copied on a Vulnerability issue.
-</p>
-<a name="Full_Disclosure"></a>
-<h3>Full Disclosure</h3>
-<p>All Vulnerabilities must ultimately be fully disclosed to the
- community at large.
-</p>
-<p>
- All Vulnerabilities affecting projects that participate in the
- Simultaneous Release must be reported to the Eclipse Planning Council prior
- to full disclosure to the community at large. Disclosure of a
- Vulnerability must be coordinated with the distribution of the
- updated software from the Project's own distribution channels, the
- Simultaneous Release repository, and EPP packages (please see <a
- href="#Distribution" title="">Distribution</a>).
-</p>
-<p>To complete the disclosure of a Vulnerability, the committers-only
- flag must be removed from the issue and the 'security' keyword added.
- Issues in this state are automatically reported on the security page
- and RSS feed.
-</p>
-<a name="Escalation"></a>
-<h3>Escalation</h3>
-<p>
- A security vulnerability may--at the discretion of the project
- leadership--be escalated to a outside body such as <a
- href="http://www.cert.org" class="external text"
- title="http://www.cert.org" rel="nofollow">CERT</a>. The EMO can
- provide assistance.
-</p>
\ No newline at end of file
+<div id="preamble">
+ <div class="sectionbody">
+ <div class="paragraph">
+ <p>Version 1.1 February 4/2020</p>
+ </div>
+ </div>
+</div>
+<div class="sect1">
+ <h2 id="security-overview">
+ <a class="anchor" href="#security-overview"></a><a class="link"
+ href="#security-overview">Overview</a>
+ </h2>
+ <div class="sectionbody">
+ <div class="paragraph">
+ <p>
+ 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 <a
+ href="https://www.eclipse.org/org/documents/eclipse_foundation-bylaws.pdf">Eclipse
+ Foundation Bylaws</a> and the <a
+ href="https://www.eclipse.org/projects/dev_process/">Eclipse
+ Foundation Development Process</a>.
+ </p>
+ </div>
+ </div>
+</div>
+<div class="sect1">
+ <h2 id="security-terms">
+ <a class="anchor" href="#security-terms"></a><a class="link"
+ href="#security-terms">Terms</a>
+ </h2>
+ <div class="sectionbody">
+ <div class="dlist">
+ <dl>
+ <dt class="hdlist1">Security Team</dt>
+ <dd>
+ <p>The Security Team, or "Eclipse Security Team" is the team tasked
+ with security and Vulnerability management on behalf of the
+ Eclipse community.</p>
+ </dd>
+ <dt class="hdlist1">Vulnerability</dt>
+ <dd>
+ <p>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."</p>
+ </dd>
+ </dl>
+ </div>
+ <div class="paragraph">
+ <p>
+ Other terms used in this document are defined in the <a
+ href="https://www.eclipse.org/projects/dev_process/">Eclipse
+ Foundation Development Process</a>.
+ </p>
+ </div>
+ </div>
+</div>
+<div class="sect1">
+ <h2 id="security-team">
+ <a class="anchor" href="#security-team"></a><a class="link"
+ href="#security-team">Eclipse Security Team</a>
+ </h2>
+ <div class="sectionbody">
+ <div class="paragraph">
+ <p>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.</p>
+ </div>
+ <div class="paragraph">
+ <p>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.</p>
+ </div>
+ </div>
+</div>
+<div class="sect1">
+ <h2 id="security-discussion">
+ <a class="anchor" href="#security-discussion"></a><a class="link"
+ href="#security-discussion">Discussion</a>
+ </h2>
+ <div class="sectionbody">
+ <div class="paragraph">
+ <p>The Eclipse Foundation is responsible for establishing
+ communication channels for the Security Team.</p>
+ </div>
+ <div class="paragraph">
+ <p>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.</p>
+ </div>
+ </div>
+</div>
+<div class="sect1">
+ <h2 id="security-resolution">
+ <a class="anchor" href="#security-resolution"></a><a class="link"
+ href="#security-resolution">Resolution</a>
+ </h2>
+ <div class="sectionbody">
+ <div class="paragraph">
+ <p>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.</p>
+ </div>
+ <div class="paragraph">
+ <p>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.</p>
+ </div>
+ <div class="paragraph">
+ <p>
+ 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 <a
+ href="https://www.eclipse.org/projects/dev_process/">Eclipse
+ Foundation Development Process</a>.
+ </p>
+ </div>
+ </div>
+</div>
+<div class="sect1">
+ <h2 id="security-distribution">
+ <a class="anchor" href="#security-distribution"></a><a class="link"
+ href="#security-distribution">Distribution</a>
+ </h2>
+ <div class="sectionbody">
+ <div class="paragraph">
+ <p>Once a Vulnerability has been resolved, the updated software must
+ be made available to the community.</p>
+ </div>
+ <div class="paragraph">
+ <p>At a minimum, updated software must be made available via normal
+ project distribution channels.</p>
+ </div>
+ </div>
+</div>
+<div class="sect1">
+ <h2 id="security-disclosure">
+ <a class="anchor" href="#security-disclosure"></a><a class="link"
+ href="#security-disclosure">Disclosure</a>
+ </h2>
+ <div class="sectionbody">
+ <div class="paragraph">
+ <p>Disclosure is initially limited to the reporter and all Eclipse
+ Committers, but may be expanded to include other individuals.</p>
+ </div>
+ <div class="paragraph">
+ <p>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.</p>
+ </div>
+ <div class="sect2">
+ <h3 id="security-timing">
+ <a class="anchor" href="#security-timing"></a><a class="link"
+ href="#security-timing">Timing</a>
+ </h3>
+ <div class="paragraph">
+ <p>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:</p>
+ </div>
+ <div class="ulist">
+ <ul>
+ <li>
+ <p>Vulnerabilities for which there is a patch, workaround or fix,
+ should be disclosed to the community immediately; and</p>
+ </li>
+ <li>
+ <p>Vulnerabilities—​regardless of
+ state—​must be disclosed to the community after a
+ maximum three months.</p>
+ </li>
+ </ul>
+ </div>
+ <div class="paragraph">
+ <p>Vulnerabilities need not necessarily be resolved at the time of
+ disclosure.</p>
+ </div>
+ </div>
+ <div class="sect2">
+ <h3 id="security-quiet-disclosure">
+ <a class="anchor" href="#security-quiet-disclosure"></a><a
+ class="link" href="#security-quiet-disclosure">Quiet Disclosure</a>
+ </h3>
+ <div class="paragraph">
+ <p>
+ A Vulnerability may be <em>quietly</em> disclosed by simply
+ removing visibility restrictions.
+ </p>
+ </div>
+ <div class="paragraph">
+ <p>In general, quiet disclosure is appropriate only for issues that
+ are identified by a committer as having been erroneously marked as
+ Vulnerabilities.</p>
+ </div>
+ </div>
+ <div class="sect2">
+ <h3 id="security-progressive-disclosure">
+ <a class="anchor" href="#security-progressive-disclosure"></a><a
+ class="link" href="#security-progressive-disclosure">Progressive
+ Disclosure</a>
+ </h3>
+ <div class="paragraph">
+ <p>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.</p>
+ </div>
+ </div>
+ <div class="sect2">
+ <h3 id="security-full-disclosure">
+ <a class="anchor" href="#security-full-disclosure"></a><a
+ class="link" href="#security-full-disclosure">Full Disclosure</a>
+ </h3>
+ <div class="paragraph">
+ <p>All Vulnerabilities must eventually be fully disclosed to the
+ community at large.</p>
+ </div>
+ <div class="paragraph">
+ <p>To complete the disclosure of a Vulnerability, all restrictions
+ on visibility must be removed and the Vulnerability reported via
+ channels provided by the Eclipse Foundation.</p>
+ </div>
+ </div>
+ <div class="sect2">
+ <h3 id="security-reporting">
+ <a class="anchor" href="#security-reporting"></a><a class="link"
+ href="#security-reporting">Reporting</a>
+ </h3>
+ <div class="paragraph">
+ <p>A project team may, at their discretion, opt to disclose a
+ Vulnerability to a reporting authority.</p>
+ </div>
+ <div class="paragraph">
+ <p>The EMO will determine how to engage with Vulnerability reporting
+ authorities.</p>
+ </div>
+ </div>
+ </div>
+</div>
+<div class="sect1">
+ <h2 id="history">
+ <a class="anchor" href="#history"></a><a class="link" href="#history">History</a>
+ </h2>
+ <div class="sectionbody">
+ <div class="paragraph">
+ <p>Changes made in this document:</p>
+ </div>
+ <div class="sect2">
+ <h3 id="changelog">
+ <a class="anchor" href="#changelog"></a><a class="link"
+ href="#changelog">ChangeLog</a>
+ </h3>
+ <div class="sect3">
+ <h4 id="2019-2019-03-06-version-1-1">
+ <a class="anchor" href="#2019-2019-03-06-version-1-1"></a><a
+ class="link" href="#2019-2019-03-06-version-1-1">[2019] -
+ 2019-03-06 (version 1.1)</a>
+ </h4>
+ <div class="sect4">
+ <h5 id="changes">
+ <a class="anchor" href="#changes"></a><a class="link"
+ href="#changes">Changes</a>
+ </h5>
+ <div class="ulist">
+ <ul>
+ <li>
+ <p>Changed the name from "Security Policy" to "Vulnerability
+ Reporting Policy"</p>
+ </li>
+ <li>
+ <p>Formalized terms into their own section.</p>
+ </li>
+ <li>
+ <p>Changed several occurances of the word "can" to "may" to
+ improve clarity.</p>
+ </li>
+ </ul>
+ </div>
+ </div>
+ <div class="sect4">
+ <h5 id="added">
+ <a class="anchor" href="#added"></a><a class="link" href="#added">Added</a>
+ </h5>
+ <div class="ulist">
+ <ul>
+ <li>
+ <p>Added a pointer to the Grievance Handling section of the
+ Eclipse Foundation Development Process.</p>
+ </li>
+ </ul>
+ </div>
+ </div>
+ <div class="sect4">
+ <h5 id="removed">
+ <a class="anchor" href="#removed"></a><a class="link"
+ href="#removed">Removed</a>
+ </h5>
+ <div class="ulist">
+ <ul>
+ <li>
+ <p>Removed references to specific technology (e.g., Bugzilla or
+ specific mailing lists). These are implementation details.</p>
+ </li>
+ <li>
+ <p>Removed references to the Eclipse Planning Council and
+ Simultaneous Release.</p>
+ </li>
+ </ul>
+ </div>
+ </div>
+ </div>
+ </div>
+ </div>
+</div>
\ No newline at end of file
diff --git a/index.php b/index.php
index 70a02d9..7d0f964 100755
--- a/index.php
+++ b/index.php
@@ -20,7 +20,7 @@
include ($App->getProjectCommon());
-$pageTitle = "Eclipse Security";
+$pageTitle = "Eclipse Vulnerability Reporting";
$Theme->setPageTitle($pageTitle);
$Theme->setPageKeywords("Eclipse, projects, security");
diff --git a/policy.php b/policy.php
index 40000e9..3cd5c5e 100755
--- a/policy.php
+++ b/policy.php
@@ -20,7 +20,7 @@
include ($App->getProjectCommon());
-$pageTitle = "Eclipse Security Policy";
+$pageTitle = "Eclipse Vulnerability Reporting Policy";
$Theme->setPageTitle($pageTitle);
$Theme->setPageKeywords("Eclipse, projects, security");
