Do not create security forks with module name included.

Problem/Motivation

Currently forks for security issues are created using the template /security/123456-machine_name-security.

We know that GitLab generates links programmatically based on the namespace of the project. This means that links to work items include the name of the module https://git.drupalcode.org/security/123456-drupal-security/-/work_items/1 would be the path for work item for issue 123456 in the Drupal module.

There is already at least one case of a link being posted (attached screenshot) revealing the maintainer is working on a module with a vulnerability. This occurred after there was discussion that warnings may be needed to advise maintainers not to post links.

Warnings do not resolve the fundamental flaws that the links can leak not just from accidental posts in Slack.

Browser referrer headers, browser plugins and proxy severs would be three other very common leak points.

If the data is considered sensitive enough to post a warning it is sensitive enough to not include in the URL. MITRE CWE-200: Exposure of Sensitive Information to an Unauthorized Actor and children become relevant here.

Created as a security team issue as they own the security queue process and are responsible for choosing Infrastructure to keep their needs. Major since there are known leaks that have occurred due to this though there is some potential to avoid them.

Steps to reproduce

Create a security issue for any module on D.O. and observe the created report ends up assigned to a project with the module name inluded in URL’s.

Proposed resolution

Do not creates repositories with module name included.

Remaining tasks

Decide if the Security team wishes to change the naming of repos
Create followup issues to change security repository naming.

User interface changes

Security forks will no longer include the project name in the their name.

API changes

None

Data model changes