Security: clarify use of confidential issues

Add warnings on the use of confidential issues. Only assignees see the issue, not people in CC (outside of the project).

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

source/chapters/security.adoc

@@ -68,7 +68,7 @@ Project can request CVE numbers in different ways depending on the project setup
 
 For most projects the process looks as follows:
 
-* *Request the number*: When you know that there is a security issue (the fix is not yet needed at this point), go to {cveRequestUrl}[the CVE Request form] and fill it. Make sure to keep the issue confidential for now. If you want to make the issue visible to multiple project members, add them as assignees or CC them when creating the ticket (it will be hard later on).
+* *Request the number*: When you know that there is a security issue (the fix is not yet needed at this point), go to {cveRequestUrl}[the CVE Request form] and fill it. Make sure to keep the issue confidential for now. If you want to make the issue visible to multiple project members, add them as assignees when creating the ticket (it will be hard later on).
 
 * *Receive the number*: The Eclipse Foundation Security Team will come back to you with the assigned number. You can start using it internally when preparing documentation of the release containing the fix.
 
@@ -85,6 +85,13 @@ For most projects the process looks as follows:
 Project commiters should make it clear if their request is a reservation of a CVE number, or a publication.
 ====
 
+[TIP]
+====
+When working with GitLab confidential issues, be careful. Only the author of the ticket, all commiters in the project containing the issue tracker, and assigned people will see the issue and receive notifications.
+
+Adding new assignees who are not members of the project has no effect when the issue is already confidential. When in doubt, verify with the concerned person if they receive notifications by other communication means.
+====
+
 The _Tracking_ section of the request issue includes some checkboxes for the project team and for the Security Team. The Security Team will assign the CVE upon receipt of the request, but will not escalate (that is, they will not report the assignment of the CVE to the central authority) until after a project committer clearly indicates that they are ready to disclose the vulnerability.
 
 ****
@@ -206,3 +213,7 @@ Do we need a <<vulnerability-cve,CVE>> for versions of software that we released
 The answer to this is not obvious, but as a general rule... no. The answer is not obvious because the continuity of the source of affected products may not be obvious (or relevant) to consumers, and it is not strictly wrong for a CVE Numbering Authority to create a CVE for a version of a product not immediately in their purview. 
 +
 Ultimately, whether or not we should create a CVE is the project team's call.
+
+I think that my project hasn't received all notifications about security issues? ::
+
+In this case, please contact the <<vulnerability-team, Security Team>>. Please note that the Eclipse Foundation Security Team notifies project leads by default.