meta: refine the security vuln posture for experimental flagged features

Currently, any runtime gated experimental feature security vulnerability
is considered a "valid" vulnerability, even if the work is still very
much work in progress. This adds friction because it ends up requiring
that things be compile time gated which makes it more difficult if there
is not a corresponding CI job to run tests.

This relaxes the policy a bit. For anything that is 1.0 and 1.1, a vuln
report is only valid if it directly compromises a stable feature, allows
a workaround that compromises a stable feature, etc. An example would be
an obvious DOS vector that can be exploited even if the feature is not
enabled, for instance.

This gives us leeway to reject vuln reports on things that are enabled
only by `--experimental-*` runtime flag that are still works in progress.

Signed-off-by: James M Snell <jasnell@gmail.com>

Author: jasnell

SECURITY.md

@@ -124,19 +124,45 @@ This policy recognizes that experimental platforms may not compile, may not
 pass the test suite, and do not have the same level of testing and support
 infrastructure as Tier 1 and Tier 2 platforms.
 
-### Experimental features behind compile-time flags and V8 flags
+### Experimental features behind compile-time flags, experimental runtime flags, and V8 flags
 
 Node.js includes certain experimental features that are only available when
-Node.js is compiled with specific flags. These features are intended for
-development, debugging, or testing purposes and are not enabled in official
-releases.
+Node.js is compiled with specific flags or that are only enabled with experimental
+runtime flags. These features are intended for development, debugging, or testing
+purposes and are not enabled or supported in official releases.
 
 Node.js may also expose V8 features that are controlled by V8 command-line flags
 (e.g., `--js-staging`, `--max_old_space_size`). These flags
 enable or modify V8-level JavaScript engine behavior that is not part of the
 ECMAScript specification that Node.js implements and is not part of the
 Node.js documented API surface.
 
+#### Runtime gated experimental features
+
+Experimental features behind runtime flags can fall into one of three categories:
+
+- 1.0 - Early development. Experimental features at this stage are unfinished
+  and subject to substantial change.
+- 1.1 - Active development. Experimental features at this stage are nearing
+  minimum viability.
+- 1.2 - Release candidate. Experimental features at this stage are hopefully
+  ready to become stable. No further breaking changes are anticipated but may
+  still occur in response to user feedback or the features' underlying
+  specification development. We encourage user testing and feedback so that
+  we can know that this feature is ready to be marked as stable.
+
+Security vulnerabilities that only affect experimental features in either the
+1.0 or 1.1 stages will **not** be accepted as valid security issues unless the
+vulnerability can be exploited in a way that impacts the security of a stable
+feature. For instance, if the experimental feature exposes a vulnerability in
+a stable feature or allows a workaround that can be exploited to compromise a
+stable feature, then it may be considered a valid security issue.
+
+Security vulnerabilities that affect experimental features in the 1.2 stage are
+acceptable as valid security issues.
+
+#### Compile-time gated experimental features and V8 flags
+
 * Security vulnerabilities that only affect features behind compile-time flags
   or V8 flags will **not** be accepted as valid security issues.
 * Any issues with these features will be treated as normal bugs.