cve_policy: update the policy

Update the policy with details related to Eclipse processes, the setup of the Gitlab bugtracker.

Signed-off-by: Marta Rybczynska marta.rybczynska@linaro.org

security/cve_policy.rst

@@ -4,8 +4,8 @@
 
 .. include:: ../definitions.rst
 
-Vulnerability Handling Process (draft)
-######################################
+Vulnerability Handling Process
+##############################
 
 |main_project_name| aims to build a secure system from the foundation, applying
 the best industry practices in terms of development quality. However, as in
@@ -19,6 +19,8 @@ protect deployed products, sometimes we need to delay releasing information
 related to security issues, following the industry best practices. However, all
 information about vulnerabilities is becoming publicly available at the end.
 
+This process extends `the Eclipse security process <https://www.eclipse.org/security/policy.php>`.
+
 How to Report a Vulnerability?
 ******************************
 
@@ -27,11 +29,12 @@ us immediatelly by posting a confidential issue in our bug tracker in a
 dedicated `security project <https://gitlab.eclipse.org/security/oniro-core>`_.
 
 To do so, login into our issue tracker or create a new account if you do not have one
-yet. Click on `New issue <https://gitlab.eclipse.org/security/oniro-core/-/issues/new>`_, then make sure to check the checkbox at the bottom 
+yet. Click on `New issue <https://gitlab.eclipse.org/security/oniro-core/-/issues/new>`_,
+then make sure to check the checkbox at the bottom
 'This issue is confidential and should only be visible to team members with at least 
-Reporter access'. Please use the 'Issue' type of ticket and the associated template.
-Fill in the title, answer the questions in the 'Description' field.
-Then click 'Create issue'.
+Reporter access'. Please use the 'Issue' type of ticket, on top of the 'Description'
+field choose the 'default' template. Fill in the title, answer the questions in the
+'Description' field. Then click 'Create issue'.
 
 Your report should contain a description of the issue, the steps you took to
 reproduce the issue (including the image name), affected versions, and, if
@@ -104,9 +107,13 @@ assigns it to the relevant developer. The security team also verifies which
 versions are affected.
 
 If the security team judges it could be exploited, they request a CVE number for
-the issue and set up the embargo duration. It is by default 90
-days, and may be different if necessary (for example, if the fix will be
-complicated to deploy, or the issue will be known earlier for some reasons).
+the issue and set up the embargo duration (see details in the
+`Eclipse project handbook <https://www.eclipse.org/projects/handbook/#vulnerability-cve>`__).
+It is by default 90 days, and may be different if necessary. This could be a case
+for various reasons, for example: if the fix will be complicated to deploy, the issue will
+be known earlier because of coordinated disclosure between multiple projects, or when
+security researchers who discovered it have an accepted conference paper
+with a given publication date and/or the presentation date.
 
 The CVE number is mentioned in the confidential ticket, but should not be used
 in any other communication until the end of the embargo. The commit messages
@@ -209,6 +216,12 @@ We follow the rules of the upstream projects, if applicable.
 
 This step is an equivalent of the Fix step of the Bug process.
 
+GitLab currently does not allow adding outside assignees to a confidential issue.
+It means that, when a team needs to add a domain expert, they need to create a
+new confidential issue and add ALL people who should be working on the ticket
+as assignees. This is currently the only workaround assuring no confidential data
+disclosure.
+
 Notify
 ^^^^^^