Process for handling security issues

Hi everyone,

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.
Thanks.


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?

  1. 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)
  2. Add a comment to the jira issue with a link to the advisory
  3. 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
  4. Fix the issue on all supported branches and release XWiki. For low level security issues add them to the RN
  5. 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.
  6. 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.

+1

Shouldn’t we explain here the labels we use on jira.xwiki.org and the security dashboard (visible to committers)?

Why not use the labels we defined already and explain what is sever using them?

I think we should make this text a bit more generic. For me it’s not juste related to sponsoring companies but also to the reporter of the issue or anyone asking about it on the security list. We should also say why we favor sponsoring companies over others (it’s because they sponsor the dev of xwiki and we’re ok that they have a reward for doing so by having this extra lead time to prepare for their clients).

I don’t think this is right. The committers should just send the warning on the security list. It’s up to sponsoring companies to have someone on that list to relay it to them.

+1 globally, thanks

I can provide information about the labels and explain them indeed: I think we should use them when creating an issue. At least to them to quickly understand what it’s about.
I’m not entirely sure they are enough for computing the final severity (particularly when we investigated on the issue I think we should start using https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator), but we could provide an easy-to-use matrix to have an “high-level” scale of the severity.

I’m not sure to see what you have in mind there.

Sure we can be more specific here.

Right I think I forgot to edit this one.

Here’s the text you have:

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.

It mentions “sponsoring companies”. This is not broad enough IMO. There are more actors than just sponsoring companies. For me it’s not juste related to sponsoring companies but also to the reporter of the issue or anyone asking about it on the security list.