Define a policy on how to handle security issues opened on drupal.org for security-team-supported projects

We need some clarification and standardizing around how to handle an issue logged on the public drupal.org site for a project which is covered by the security team. There currently isn't a standard process, though the following appear to be the defacto process:

• The node is unpublished.
• An sdo issue is created if needed.
• The person is added to the sdo issue.

This leaves a few open questions:

• Webmasters looking at an unpublished node may not be aware of why it's unpublished and might mistake it for e.g. spam.
• If a revision comment is left when the node is unpublished it won't be particularly obvious to webmasters.
• It isn't currently possible / easy to get a list of all public issues that were unpublished for security reasons.

Proposal:

• Unpublish the issue.
• Add the following tag to the issue: security
• Add a comment that the issue was closed for security purposes and will be followed up on separately, or some standard sentence that explains what's going on.
• Look for an existing sdo issue for the bug.
• Invite the reporter (plus anyone who worked on any patches, if applicable) to the sdo issue.
• Update public documentation to disclose this process.

Outstanding questions:

• Would it be useful to add a filter to admin/content/node on drupal.org to specifically look for the security tag? Or maybe just add a generic tag filter?
• Should all webmasters be notified of the workflow, or would a documentation change be enough?