we just published our first security advisory on Github, so I’d like to submit to vote a general process for handling security issue. If everyone agrees on it, then it will become the rules for handling them for committers and I’ll publish it on xwiki.org. Note that this is pretty important since it might also impact the sponsored companies of XWiki. Also consider that we comply to those rules for the security advisory we just published in order to prove it’s working (at least for one occurence).
The vote is open for two weeks until May 26th.
Here’s my +1.
Below the document to vote to.
XWiki Security Policy
The goal of this document is to provide some information about the policy of XWiki.org in case a vulnerability is found in XWiki Standard.
It aims at being published on https://github.com/xwiki/xwiki-platform/security/policy and to be referenced wherever it’s needed (in particular on https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Security and https://dev.xwiki.org/xwiki/bin/view/Community/Security)
Where to submit security issues?
All security issues should be submitted on https://jira.xwiki.org with the visibility set to Confidential.
Those issues are only visible to people who submitted them and to the committers of XWiki.
How long does it take to fix a security issue?
Not all security issues have the same severity and they cannot all be tackled immediately. Contributors are fixing the security issues depending on this severity and on the other priorities for the project. All this can be (and should be) part of discussion on the issues themselves.
What are the criteria for computing severity?
The severity is defined by the contributors depending on two criteria:
- the impact of the security issue (e.g. an issue that might impact all pages of a wiki is more severe than an issue which might impact only pages with specific rights)
- and the difficulty to reproduce it (e.g. an issue which needs script rights to be reproduced is less severe than an issue which only needs view access on the wiki)
Note: on the future we’ll need to formalize the usage of https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator to compute the severity of our security.
When is a security issue considered as fixed?
Security issues are considered as fixed only once the fix is part of releases for all supported branches impacted by the issue. So for example, if XWiki.org is currently in the 12.x cycle and a security issue impacts both 11.10.1 (LTS) and 12.3 (stable), the issue is fixed when 11.10.2 and 12.3.1 (or 12.4) are released with the fix.
Are security issues ever publicly disclosed?
Once the issue has been properly fixed, a CVE might be published to publicly disclose about this issue and to incitate for an upgrade. The CVE is not mandatory and should happen only in case of severe issues: if it doesn’t require special permissions (e.g. anybody with view rights can reproduce the issue) and if it might impact all pages or the server itself.
This criteria of severity might be adapted on a case-by-case basis depending on the context of the issue.
If no CVE is published, the issue and its details are never publicly disclosed, but the release notes will mention that some security issues have been fixed.
How long does it take to publish a CVE?
Once an issue has been fixed and released, an embargo of 3 months is starting to allow the sponsoring companies to perform actions before the publication of the CVE. The sponsoring companies are automatically informed as soon as a security issues has been discovered.
For example, if a security issue has been fixed and released in 11.10.2 and in 12.0, respectively released the 5th of February and the 29th of January, the CVE could be published 3 months after latest release: i.e. the 5th of May.
What’s the process to handle security issues for committers?
- Once the issue has been validated by a developer taking the ownersnip of fixing the issue, create a draft advisory on Github (see: https://help.github.com/en/github/managing-security-vulnerabilities/creating-a-security-advisory). As part of this, compute the security score (severity)
- Add a comment to the jira issue with a link to the advisory
- If the severity of the issue is high, announce the problem to all supporting companies by sending them a link to the security issue and some information about the severity
- Fix the issue on all supported branches and release XWiki. For low level security issues add them to the RN
- Annnounce the fix on the security list with the start of the 3 months timer clock. Make it part of the Release Plan for the RM to do.
- After 3 months, request a CVE (for high criticity issues only FTM) through GitHub Advisory page. Remove the confidential label on the Jira issue. Publish the advisory once the CVE ID has been received.