Create a security policy

[TravisCarden]

According to the Core dependency release cycles, security information, and evaluation criteria, dependencies are evaluated for their security policies before being added to Drupal core. To facilitate adding this library (see Add php-tuf/composer-stager to core dependencies on Drupal.org), we need to define a security policy.

• Define the policy.
• Add SECURITY.md #85
• Create an issue template for security reports #298
• Further document it as appropriate, e.g., in README.md or the Wiki.

[effulgentsia]

We'll want to reference https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/reporting-a-security-issue, but we'll need some custom language, since for example, the answer at the bottom there for "What if the vulnerability affects a project that is not hosted on Drupal.org?" would be incorrect for Composer Stager and the other PHP-TUF repos.

[effulgentsia]

Let's start with a pull request with the following SECURITY.md:

Security Policy
===============

DO NOT PUBLISH SECURITY REPORTS PUBLICLY.

Security advisories for this project are coordinated by the Drupal Security Team.

If you found any issues that might have security implications,
please send a report to security[at]drupal.org

The full [Security Policy][1] is described in Drupal's official documentation.

  [1]: https://www.drupal.org/drupal-security-team

I based the above on https://raw.githubusercontent.com/symfony/.github/main/SECURITY.md.

Let's not merge such a PR though until it's been reviewed by Drupal's security team.

[TravisCarden]

Here's the PR, @effulgentsia: #85. I requested review from the security team at https://drupal.slack.com/archives/C5B7P7294/p1677870014372739.

[TravisCarden]

I assume this should be a stable blocker, @effulgentsia.

[effulgentsia]

We need to do this to get Composer Stager into Drupal, but I don't think it needs to block a stable 2.0.0 release of Composer Stager, since adding a SECURITY.md file and other docs wouldn't disrupt Composer Stager's codebase in any way. Keeping it in the v2.0.0 milestone as something we'd like to focus on and ideally get done before 2.0.0 is fine though.