| <?php |
| /******************************************************************************* |
| * Copyright (c) 2011, 2015 Eclipse Foundation and others. |
| * All rights reserved. This program and the accompanying materials |
| * are made available under the terms of the Eclipse Public License v1.0 |
| * which accompanies this distribution, and is available at |
| * http://www.eclipse.org/legal/epl-v10.html |
| * |
| * Contributors: |
| * Wayne Beaton (Eclipse Foundation)- initial API and implementation |
| *******************************************************************************/ |
| require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); |
| require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); |
| require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); |
| $App = new App(); |
| $Nav = new Nav(); |
| $Menu = new Menu(); |
| include($App->getProjectCommon()); |
| |
| $pageTitle = "Eclipse Security Policy"; |
| $pageAuthor = ""; |
| $pageKeywords = "Eclipse, projects, security"; |
| |
| require_once dirname(__FILE__) . '/../projects/classes/images.inc'; |
| |
| ob_start(); |
| ?> |
| <div id="maincontent"> |
| <div id="midcolumn"> |
| <h1><?php echo $pageTitle; ?></h1> |
| <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> |
| 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 planning council must be made aware of Vulnerabilities in |
| software that is part of the simultaneous release. The Planning |
| Council will determine whether or not a "respin" of the simultaneous |
| release repository and EPP packages is required. The 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 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> |
| </div> |
| </div> |
| |
| <?php |
| $html = ob_get_contents(); |
| ob_end_clean(); |
| |
| $App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html); |
| ?> |