THIS IS STILL WIP. If you would like to report a security issue please refer to current procedure .

Origin

Current version of Vulnerabilities Management Process prefers email as the only method of reporting security bugs. This has some disadvantages:

1. There is no GPG key published so all emails have to be send unencrypted

2. It's not easy to publish full history from bug report to fixing it what hurts transparency of whole process
   
   

3. It'll be hard to track multiple bug reports in the same time and not get lost
   
   

Requirements

In order to secure the communication for vulnerabilities, and having a secure email approach is challenging, the ideas was to explore a ticketing systems with the following requirements. A Jira board or other system where:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID) (maybe we need a web front end??)

2. It supports default settings where the Vulnerability management sub-committee members are the only ones that have the right to view and access all the included Jiras

3. The vulnerability management sub-committee receives a notification that there is a new jira, but without the details

4. It is possible to extend the security settings in a per JIRA basis and a per individual basis to include access for selected individuals that are required to solve the identified vulnerability.

5. Finally, it should be possible to move the access restrictions and move the JIRA (when completed) to the appropriate project jira.

Reality

In reality it turned out that Jira as every software has some limitations:

• The empty notifications. (Requirement #3) The content of the email in the notifications is not configurable and even if we manage a way to hack it it will affect all projects and not just this one. If we would have slack, we could potentially manage to send notifications there with a different format, I think. Not much we can do with the built in notifications in Jira.

• We cannot open permissions outside LF registered users for just 1 project (Requirement #1). Opening JIRA for non LF registered users cannot happen in this JIRA instance. 

Everything else could be a matter of having SECOMM under its own project workflow.

OpenStack Vulnerabilities Management Process Analysis

As we are not the only Open Source project that deals with vulnerabilities we decided to analyze OpenStack Vulnerabilities Management Process.

Full version of the process: link

Instruction how to report a bug: link

Analysis output:

1. There are 2 channels for reporting vulnerabilities:

   1. Creating a bug on launchpad

   2. Sending GPG-encrypted email to one of VMT members

2. Launchpad sends plain text notification about new bugs and updates of existing ones.

3. That's why it is recommended to use GPG-encrypted mail for critical or sensitive vulnerabilities

Recommendation

1. Align our process with OpenStack one

2. Drop requirements #1 and #3 as they are not feasible for now.

3. Create new Jira project with custom workflow

4. Choose volunteers for being a contact point for critical vulnerabilities

   1. Requirement: Ability to use GPG at work

   2. Requirement: Knowledge how to use GPG securely

5. Update our Vulnerability Management Process