tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-10-22 12:05:37 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #8826 from open-sausages/pulls/4/docs-cve-security-process

Browse Source 
DOCS Clarify security process, introduce CVE and CVSS
This commit is contained in:
Ingo Schommer 2019-03-11 21:28:18 +13:00 committed by GitHub
commit b388114dd3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 62 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

68
docs/en/05_Contributing/04_Release_Process.md
View File

@ -119,7 +119,7 @@ SS_DEPRECATION_ENABLED="0"
### Reporting an issue ### Reporting an issue
Report security issues in our [commercially supported modules](https://www.silverstripe.org/software/addons/silverstripe-commercially-supported-module-list/) Report security issues in our [commercially supported modules](https://www.silverstripe.org/software/addons/silverstripe-commercially-supported-module-list/)
to [security@silverstripe.com](mailto:security@silverstripe.com). to [security@silverstripe.com](mailto:security@silverstripe.org).
Please don't file security issues in our [bugtracker](issues_and_bugs). Please don't file security issues in our [bugtracker](issues_and_bugs).
### Acknowledgment and disclosure ### Acknowledgment and disclosure
@ -128,16 +128,11 @@ In the event of a confirmed vulnerability in our
[supported modules](https://www.silverstripe.org/software/addons/silverstripe-commercially-supported-module-list/), [supported modules](https://www.silverstripe.org/software/addons/silverstripe-commercially-supported-module-list/),
we will take the following actions: we will take the following actions:
* Acknowledge to the reporter that we’ve received the report and that a fix is forthcoming. We’ll give a rough * Acknowledge to the reporter that we’ve received the report and that a fix is forthcoming.
timeline and ask the reporter to keep the issue confidential until we announce it. We’ll give a rough timeline and ask the reporter to keep the issue confidential until we announce it.
* Assign a unique identifier to the issue in the format `SS-<year>-<count>`, * Assign a [CVE identifier](https://cve.mitre.org) to the issue.
where `<count>` is a padded three digit number counting issues for the year. * For "high" and "critical" issues (CVSS of >=7.0): Pre-announce the upcoming security release to aprivate pre-announcement mailing list of important stakeholders (see below).
Example: `SS-2013-001` would be the first of the year `2013`. * We will inform you about resolution and [announce](https://forum.silverstripe.org/c/releases) a
Additionally, [CVE](http://cve.mitre.org) numbers are accepted.
* Halt all other development as long as is needed to develop a fix, including patches against the current and one
previous major release (if applicable).
* Pre-announce the upcoming security release to aprivate pre-announcement mailing list of important stakeholders (see below).
* We will inform you about resolution and [announce](https://forum.silverstripe.org/c/releases) a
[new release](http://silverstripe.org/security-releases/) publically. [new release](http://silverstripe.org/security-releases/) publically.
You can help us determine the problem and speed up responses by providing us with more information on how to reproduce You can help us determine the problem and speed up responses by providing us with more information on how to reproduce
@ -147,52 +142,25 @@ webserver access logs (if a hack is suspected), any other services and web packa
### Severity rating ### Severity rating
Each [security release](http://www.silverstripe.org/security-releases/) includes an overall severity rating and one for Each [security release](http://www.silverstripe.org/security-releases/) includes an overall severity rating and one for
each vulnerability. The rating indicates how important an update is: each vulnerability. The rating indicates how important an update is.
It follows the [Common Vulnerability Scoring System (CVSS)](https://www.first.org/cvss).
| Severity | Description | | Severity | CVSS | Description |
|---------------|-------------| |---------------|------|-------------|
| **Critical** | Critical releases require immediate action. Such vulnerabilities allow attackers to take control of your site and you should upgrade on the day of release. *Example: Directory traversal, privilege escalation* | | **Critical** | 9.0 to 10.0 | Critical releases require immediate action. Such vulnerabilities allow attackers to take control of your site and you should upgrade on the day of release. *Example: Directory traversal, privilege escalation* |
| **Important** | Important releases should be evaluated immediately. These issues allow an attacker to compromise a site's data and should be fixed within days. *Example: SQL injection.* | | **High** | 7.0 to 8.9 | Important releases should be evaluated immediately. These issues allow an attacker to compromise a site's data and should be fixed within days. *Example: SQL injection.* |
| **Moderate** | Releases of moderate severity should be applied as soon as possible. They allow the unauthorized editing or creation of content. *Examples: Cross Site Scripting (XSS) in template helpers.* | | **Medium** | 4.0 to 6.9 | Releases of moderate severity should be applied as soon as possible. They allow the unauthorized editing or creation of content. *Examples: Cross Site Scripting (XSS) in template helpers.* |
| **Low** | Low risk releases fix information disclosure and read-only privilege escalation vulnerabilities. These updates should also be applied as soon as possible, but with an impact-dependent priority. *Example: Exposure of the core version number, Cross Site Scripting (XSS) limited to the admin interface.* | | **Low** | 0.1 to 3.9 | Low risk releases fix information disclosure and read-only privilege escalation vulnerabilities. These updates should also be applied as soon as possible, but with an impact-dependent priority. *Example: Exposure of the core version number, Cross Site Scripting (XSS) limited to the admin interface.* |
### Internal Security Process ### Internal Security Process
Follow these instructions in sequence as much as possible: See [SilverStripe Core Release Process](making-a-silverstripe-core-release).
* When receiving a report:
* Perform initial criticality assessment, and ensure that the reporter is given a justification for all issues we classify or demote as non-security vulnerabilities.
* Assign a unique identifier (see "Acknowledgement and disclosure").
Identifiers are based on reported year and order reported in JIRA (Example: `SS-2017-001`)
* Respond to issue reporter with this identifier on the same discussion thread (cc security@silverstripe.org). Clarify issue if required.
* If encrypted information is provided, add pass phrases into the SilverStripe Ltd. LastPass account. Keep encrypted documents in Google Drive and only share directly with relevant participants
* Add a new issue in the "Backlog" on the [project board](https://github.com/silverstripe-security/security-issues/projects/1).
Add a link to the [Google Groups](https://groups.google.com/a/silverstripe.com/forum/#!forum/security) discussion thread so it's easy to review follow up messages.
* Create a draft page under [Open Source > Download > Security Releases](https://www.silverstripe.org/admin/pages/edit/show/794) on silverstripe.org. Describe the issue in a readable way, make the impact clear. Credit the author if applicable.
* Clarify who picks up owns the issue resolution
* When developing a fix:
* Ensure you're working on the oldest supported minor release branch of every supported major release (see [Supported Versions](#supported-versions))
* Move the issue into "In Progress" on the [project board](https://github.com/silverstripe-security/security-issues/projects/1)
* Add fixes on the [http://github.com/silverstripe-security](http://github.com/silverstripe-security) repo
* Ensure that all security commit messages are prefixed with the CVE. E.g. "[ss-2015-001] Fixed invalid XSS"
* Get them peer reviewed by posting on security@silverstripe.org with a link to the Github issue
* Before release (or release candidate)
* Merge back from [http://github.com/silverstripe-security](http://github.com/silverstripe-security) repos shortly at the release (minimise early disclosure through source code)
* Merge up to newer minor release branches (see [Supported Versions](#supported-versions))
* Send out a note on the pre-announcement mailing list with a highlevel description of the issue and impact (usually a copy of the yet unpublished security release page on silverstripe.org)
* Link to silverstripe.org security release page in the changelog.
* Move the issue to "Awaiting Release" in the [project board](https://github.com/silverstripe-security/security-issues/projects/1)
* Perform release
* Follow the steps for [making a core release](making-a-silverstripe-core-release)
* After release
* Publish silverstripe.org security release page
* Respond to issue reporter with reference to the release on the same discussion thread (cc security@silverstripe.org)
* Move the issue to "Done" in the [project board](https://github.com/silverstripe-security/security-issues/projects/1)
### Pre-announcement mailing list ### Pre-announcement mailing list
In addition to our public disclosure process, we maintain a private mailing list where upcoming security releases In addition to our public disclosure process, we maintain a private mailing list where upcoming
are pre-announced. Members of this list will receive a security pre-announcement, as soon as it has been "high" or "critical" security releases are pre-announced.
Members of this list will receive a security pre-announcement, as soon as it has been
sufficiently researched, with a timeline for the upcoming release. sufficiently researched, with a timeline for the upcoming release.
This will happen a few days before the announcement goes public alongside a new release, This will happen a few days before the announcement goes public alongside a new release,
and most likely before a patch has been developed. and most likely before a patch has been developed.

75
docs/en/05_Contributing/05_Making_A_SilverStripe_Core_Release.md
View File

@ -90,6 +90,8 @@ For doing security releases the following additional setup tasks are necessary:
## Security release process ## Security release process
### Overview
When doing a security release, typically one or more (or sometimes all) of the below When doing a security release, typically one or more (or sometimes all) of the below
steps will need to be performed manually. As such, this guide should not be followed steps will need to be performed manually. As such, this guide should not be followed
exactly the same for these. exactly the same for these.
@ -102,41 +104,52 @@ Security issues are never disclosed until a public stable release containing thi
is available, or within a reasonable period of time of such a release. is available, or within a reasonable period of time of such a release.
</div> </div>
Producing a security fix follows this general process: ### When receiving a report
* When a security issue is disclosed on security@silverstripe.com it should be given * Perform initial criticality assessment, and ensure that the reporter is given a justification for all issues we classify or demote as non-security vulnerabilities.
a CVE (common vulnerability exposure) code. E.g. ss-2015-020. Make sure you thank * If encrypted information is provided, add pass phrases into the SilverStripe Ltd. LastPass account. Keep encrypted documents in Google Drive and only share directly with relevant participants
anyone who disclosed this issue, and confirm with them as soon as possible whether * Add a new issue in the "Backlog" on the [project board](https://github.com/silverstripe-security/security-issues/projects/1).
this issue is a verified security issue. Add a link to the [Google Groups](https://groups.google.com/a/silverstripe.com/forum/#!forum/security) discussion thread so it's easy to review follow up messages.
* Log this CVE, along with description, release version, and name of reporter in * Use the [CVSS Calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) to determine the issue severity
the [security issues GitHub repository](https://github.com/silverstripe-security/security-issues/issues). * Once the issue is confirmed, [request a CVE identifier](https://cveform.mitre.org/) under the security@silverstripe.org contact email (see "Acknowledgement and disclosure").
* Create a similar record of this issue on the [security releases page](http://www.silverstripe.org/download/security-releases) * Once a CVE has been assigned, respond to issue reporter and add it to the Github issue
in draft mode. * Clarify who picks up owns the issue resolution (assign in Github)
* Post a pre-announcement to the [security pre-announcement list](https://groups.google.com/a/silverstripe.com/forum/#!forum/security-preannounce).
It's normally ideal to include a [CVSS](https://nvd.nist.gov/CVSS-v2-Calculator) ### When developing a fix
(common vulnerability scoring system) along with this pre-announcement. If the
release date of the final stable is not known, then it's ok to give an estimated * Ensure you're working on the oldest supported minor release branch of every supported major release (see [Supported Versions](#supported-versions))
release schedule. * Move the issue into "In Progress" on the [project board](https://github.com/silverstripe-security/security-issues/projects/1)
* Push the current upstream target branches (e.g. 3.2) to the corresponding security fork * Add fixes on the [http://github.com/silverstripe-security](http://github.com/silverstripe-security) repo. Don't forget to update branches from the upstream repo.
to the equivalent branch on [silverstripe-security](https://github.com/silverstripe-security). * Ensure that all security commit messages are prefixed with the CVE. E.g. "[CVE-2019-001] Fixed invalid XSS"
Security fixes should be applied to the branch on this private repository only. * Get them peer reviewed by posting on security@silverstripe.org with a link to the Github issue
Once a fix (or fixes) have been applied to this branch, then a tag can be applied,
and a private release can then be developed in order to test this release. ### Before release (or release candidate)
* Once upstream branches are all pushed to the security forks, make sure to merge all
security fixes into those branches prior to running cow. * For issues rated "high" or "critical" (CVSS of >=7.0), post a pre-announcement to the [security pre-announcement list](https://groups.google.com/a/silverstripe.com/forum/#!forum/security-preannounce).
* Setup a temporary [satis](https://github.com/composer/satis) repository which points to all relevant repositories It should include a basic "preannouncement description" which doesn't give away too much,
the CVSS score as well as the CVE identifier.
* Create a draft page under [Open Source > Download > Security Releases](https://www.silverstripe.org/admin/pages/edit/show/794).
Populate it with the information from the [Github project board](https://github.com/silverstripe-security/security-issues/projects/1).
* Link to silverstripe.org security release page in the changelog.
* Move the issue to "Awaiting Release" in the [project board](https://github.com/silverstripe-security/security-issues/projects/1)
### Perform release
* Public disclosure of security vulnerabilities need to happen in stable releases (not pre-releases)
* Merge back from [http://github.com/silverstripe-security](http://github.com/silverstripe-security) repos shortly at the release (minimise early disclosure through source code)
* Merge up to newer minor release branches (see [Supported Versions](#supported-versions))
* Setup a temporary [satis](https://github.com/composer/satis) repository which points to all relevant repositories
containing security fixes. See below for setting up a temporary satis repository. containing security fixes. See below for setting up a temporary satis repository.
* Once release testing is completed and the release is ready for stabilisation, then these fixes * Once release testing is completed and the release is ready for stabilisation, then these fixes
can then be pushed to the upstream module fork, and the release completed as per normal. can then be pushed to the upstream module fork, and the release completed as per normal.
Make sure to publish any draft security pages at the same time as the release is published (same day). * Follow the steps for [making a core release](making-a-silverstripe-core-release)
* After the final release has been published, close related GitHub issues
in the [security-issues repository](https://github.com/silverstripe-security/security-issues/issues). ### After release
* Publish silverstripe.org security release page
* Respond to issue reporter with reference to the release on the same discussion thread (cc security@silverstripe.org)
* Move the issue to "Done" in the [project board](https://github.com/silverstripe-security/security-issues/projects/1)
<div class="warning" markdown="1">
Note: It's not considered acceptable to disclose any security vulnerability until a fix exists in
a public stable, not an RC or dev-branch. Security warnings that do not require a stable release
can be published as soon as a workaround or usable resolution exists.
</div>
### Setting up satis for hosting private security releases ### Setting up satis for hosting private security releases