Skip to main content
aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--pom.xml14
-rw-r--r--source/chapters/security-policy.adoc49
2 files changed, 43 insertions, 20 deletions
diff --git a/pom.xml b/pom.xml
index 4b1b0df..8f2a2ee 100644
--- a/pom.xml
+++ b/pom.xml
@@ -102,6 +102,20 @@
</attributes>
</configuration>
</execution>
+ <execution>
+ <id>asciidoc-to-html-security-policy</id>
+ <phase>generate-resources</phase>
+ <goals>
+ <goal>process-asciidoc</goal>
+ </goals>
+ <configuration>
+ <sourceDocumentName>chapters/security-policy.adoc</sourceDocumentName>
+ <headerFooter>false</headerFooter>
+ <attributes>
+ <edpUrl>http://www.eclipse.org/projects/dev_process/development_process.php</edpUrl>
+ </attributes>
+ </configuration>
+ </execution>
<!-- <execution> -->
<!-- <id>asciidoc-to-html-polarsys</id> -->
<!-- <phase>generate-resources</phase> -->
diff --git a/source/chapters/security-policy.adoc b/source/chapters/security-policy.adoc
index 56fc8dd..8cc20da 100644
--- a/source/chapters/security-policy.adoc
+++ b/source/chapters/security-policy.adoc
@@ -1,5 +1,5 @@
////
- * Copyright (C) 2018 Eclipse Foundation, Inc. and others.
+ * Copyright (C) Eclipse Foundation, Inc. and others.
*
* This program and the accompanying materials are made available under the
* terms of the Eclipse Public License v. 2.0 which is available at
@@ -14,44 +14,53 @@
[[security-overview]]
== Overview
-The purpose of the Eclipse Vulnerability Reporting 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 Vulnerability Reporting 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 {bylawsUrl}[Eclipse Foundation Bylaws].
+The purpose of the Eclipse Vulnerability Reporting 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 Vulnerability Reporting 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 {bylawsUrl}[Eclipse Foundation Bylaws].
-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."
+[[security-terms]]
+== Terms
+
+Security Team ::
+The Security Team, or "Eclipse Security Team" is the team tasked with security and Vulnerability management an behalf of the Eclipse community.
+
+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."
+
+Other terms used in this document are defined in the {edpUrl}[Eclipse Development Process].
[[security-team]]
== Eclipse Security Team
-The Security Team is the first line of defense: it is effectively a triage unit with security and vulnerability management expertise. Ultimately, vulnerabilities are resolved by individual projects with assistance from the Security Team.
+The Eclipse Security Team is the first line of defense: it is effectively a triage unit with security and Vulnerability management expertise. Ultimately, Vulnerabilities are resolved by individual projects with assistance from the Security Team.
The Security Team is composed of a small number of security experts and representatives from the Project Management Committees.
[NOTE]
====
-Mail sent to the mailto:{securityTeamEmail}[security team email address] is sent exclusively to all members of the Security Team. Anybody can send mail to this address. This list is not archived, and is not open for public subscription.
+Mail sent to the mailto:{securityTeamEmail}[Security Team email address] is sent exclusively to all members of the Security Team. Anybody can send mail to this address. This list is not archived, and is not open for public subscription.
====
[[security-discussion]]
== Discussion
-Initial discussion of an open 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 in the mitigation process. Appropriate effort must be be undertaken to ensure that the visibility of a reported issue is managed.
+Initial discussion of an open 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 in the mitigation process. Appropriate effort must be be undertaken to ensure that the visibility of a reported issue is managed.
[[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 either a patch or workaround is available, or it is determined that a fix is not possible or desirable.
-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 Eclipse Architecture Council.
+It is left to the discretion of the Security Team and Project Leadership Chain 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 Eclipse Architecture Council.
[[security-distribution]]
== Distribution
-Once a vulnerability has been resolved, the updated software must be made available to the community.
+Once a Vulnerability has been resolved, the updated software must be made available to the community.
At a minimum, updated software must be made available via normal project distribution channels.
[WARNING]
====
-The Eclipse Planning Council must be made aware of vulnerabilities in software that is part of a simultaneous release. The Eclipse Planning Council will determine whether or not a _respin_ of the simultaneous release content is required. The Eclipse Planning Council will coordinate the timing of the respin with the project leadership.
+The Eclipse Planning Council must be made aware of Vulnerabilities in software that is part of a simultaneous release. The Eclipse Planning Council will determine whether or not a _respin_ of the simultaneous release content is required. The Eclipse Planning Council will coordinate the timing of the respin with the Project Leads.
====
[[security-disclosure]]
@@ -59,38 +68,38 @@ The Eclipse Planning Council must be made aware of vulnerabilities in software t
Disclosure is initially limited to the reporter and all Eclipse Committers, but can be expanded to include other individuals.
-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.
+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.
[[security-timing]]
=== Timing
-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:
+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.
-* Vulnerabilities—regardless of state—must be disclosed to the community after a maximum three months.
+* 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.
Vulnerabilities need not necessarily be resolved at the time of disclosure.
[[security-quiet-disclosure]]
=== Quiet Disclosure
-A Vulnerability can be _quietly_ disclosed by simply removing visibility restrictions.
+A Vulnerability may be _quietly_ disclosed by simply removing visibility restrictions.
-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 committer as having been erroneously marked as Vulnerabilities.
[[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 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.
[[security-full-disclosure]]
=== Full Disclosure
-All vulnerabilities must eventually be fully disclosed to the community at large.
+All Vulnerabilities must eventually be fully disclosed to the community at large.
[WARNING]
====
-All vulnerabilities affecting projects that participate in a 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 known downstream consumer where possible.
+All Vulnerabilities affecting projects that participate in a 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 known downstream consumer where possible.
====
-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. \ No newline at end of file
+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. \ No newline at end of file

Back to the top