Add a SECURITY.md community health file to the repo

Following GitHub's best practices,[^1] this adds our previously voted on
and approved[^2] security classification document[^3] to the repository.

[^1]: https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
[^2]: https://wiki.php.net/rfc/security-classification
[^3]: https://wiki.php.net/security

SECURITY.md

@@ -0,0 +1,165 @@
+# Security Classification Document
+
+*The canonical version of this document is located at <https://wiki.php.net/security>.
+Where there are discrepancies, the canonical version takes precedence.*
+
+## Meta
+
+- Authors: Release Managers
+- Date: November 2016
+- Version: 1.0.1
+- RFC: [Security Issue Classification](https://wiki.php.net/rfc/security-classification)
+
+## Introduction
+
+For the sake of our users, we classify some of the issues found in PHP
+as "security issues". This document is intended to explain which issues
+are thus classified, how we handle those issues and how to report them.
+
+## Classification
+
+We classify as security issues bugs that:
+
+- allow users to execute unauthorized actions
+- cross security boundaries
+- access data that is not intended to be accessible
+- severely impact accessibility or performance of the system
+
+The purpose of this classification is to alert the users and the
+developers about the bugs that need to be prioritized in their handling.
+
+We define three categories of security issues, by their severity,
+described below. Please note that this categorization is in many aspects
+subjective, so it ultimately relies on the judgement of the PHP
+developers.
+
+### High severity
+
+These issues may allow:
+
+- third party to compromise any, or most installations of PHP
+- the execution of arbitrary code
+- disabling the system completely
+- access to any file a local PHP user can access.
+
+The issue can be triggered on any, or on most typical installations, and
+does not require exotic and non-recommended settings to be triggered.
+
+This category also includes issues that can be triggered in code or
+functions known to be frequently used (session, json, mysql, openssl,
+etc.) during typical usage, and that require settings or configurations
+that may not be strictly the best practice, but are commonly used.
+
+This category also may include issues that require special code or code
+pattern if such code or pattern is present in many popular libraries.
+
+This kind of issues usually requires a CVE report.
+
+### Medium severity
+
+These issues may have the same potential to compromise an installation
+as a high severity issue, but may also require:
+
+- an extension that is not commonly used
+- a particular type of configuration that is used only in narrow
+  specific circumstances
+- relies on old version of a third-party library being used
+- code, or patterns of code, that are known to be used infrequently
+- code that is very old, or extremely uncommon (and so is used
+  infrequently)
+
+This kind of issues usually will have a CVE number, unless the required
+configuration is particularly exotic to the point it's not practically
+usable.
+
+### Low severity
+
+This issue allows theoretical compromise of security, but practical
+attack is usually impossible or extremely hard due to common practices
+or limitations that are virtually always present or imposed.
+
+This also includes problems with configuration, documentation, and other
+non-code parts of the PHP project that may mislead users, or cause them
+to make their system, or their code less secure.
+
+Issues that can trigger unauthorized actions that do not seem to be
+useful for any practical attack can also be categorized as low severity.
+
+Security issues, that are present only in unstable branches, belong to
+this category, too. Any branch that has no stable release, is per se not
+intended for the production use.
+
+Low severity issues usually do not need to have CVE and may, at the
+discretion of the PHP developers, be disclosed publicly before the fix
+is released or available.
+
+### Not a security issue
+
+We do not classify as a security issue any issue that:
+
+- requires invocation of specific code, which may be valid but is
+  obviously malicious
+- requires invocation of functions with specific arguments, which may
+  be valid but are obviously malicious
+- requires specific actions to be performed on the server, which are
+  not commonly performed, or are not commonly permissible for the user
+  (uid) executing PHP
+- requires privileges superior to that of the user (uid) executing PHP
+- requires the use of debugging facilities - ex. xdebug, var_dump
+- requires the use of settings not recommended for production - ex.
+  error reporting to output
+- requires the use of non-standard environment variables - ex.
+  USE_ZEND_ALLOC
+- requires the use of non-standard builds - ex. obscure embedded
+  platform, not commonly used compiler
+- requires the use of code or settings known to be insecure
+- requires the use of FFI
+- requires an open_basedir bypass
+
+## Handling issues
+
+High and medium severity fixes are merged into a security repository and
+merged before the release is tagged.
+
+Low severity fixes are merged immediately after the fix is available and
+handled like all regular bugs are handled consequently. However, release
+managers may choose to pull those fixes into the RC branch after the
+branch is created, and also backport them into security-only release
+branch.
+
+## FAQ
+
+Q. How do I report a security issue?\
+A. Please report it on <http://bugs.php.net>, choosing type "Security".
+This will automatically make it private. If for some reason you can not
+do that, or need to talk to somebody about a PHP security issue that is
+not exactly a bug report, please write to security@php.net.
+
+Q. What do you consider a responsible disclosure?\
+A. Please report the issue as described above. Please communicate with
+the developers about when the fix will be released - usually it's the
+next monthly release after the bug was reported. Some issues can take
+longer. After the fix is released (releases usually happen on Thursday)
+please feel free to disclose the issue as you see fit.
+
+Q. What if I think it's a security issue but developers disagree?\
+A. Please read the above and try to explain to us why it fits the
+description.
+
+Q. What if developers still don't think it's a security issue?\
+A. We'll have to agree to disagree.
+
+Q. The bug I submitted was classified as "not a security issue", you
+don't believe it's real?\
+A. It has nothing to do with the bug being real or its importance to
+you. It just means it does not fit our specific definitions for issues
+that we will handle in a special way. We fix a lot of non-security bugs
+and pull requests are always welcome.
+
+Q. But you classified bug #424242 as security issue, but not this
+one?!\
+A. Each bug usually has its aspects, if a short discussion does not
+yield agreement we'd rather do more fixing and less arguing.
+
+Q. Do you pay bounties for security issues?\
+A. PHP is a volunteer project. We have no money, thus we can't pay them.