Add more rejected examples in SECURITY.md

SECURITY.md

@@ -36,6 +36,31 @@ are not limited to):
 
 - Malicious `unserialize()` inputs.
 
+- Memory exhaustion from a size the input declares, where `memory_limit`
+  refuses the allocation and only the current request dies. Reaching a limit
+  that works as designed is a robustness issue at best.
+
+# Writing a Report We Can Act On
+
+We spend most of a triage rebuilding what a report left out, so cover these
+points:
+
+- Reproduce it on a supported branch, through a normal PHP entry point. A crash
+  is enough, you do not need to write a working exploit. A crash reached only
+  from a custom fuzzing harness, or by calling an internal C function, leaves
+  reachability open.
+
+- Tell us if you ran under a sanitizer, a debug build or `USE_ZEND_ALLOC=0`.
+  The last one turns every `emalloc()` into a bare `malloc()` and drops the
+  `memory_limit` check, so we read the trace differently.
+
+- Skip the theatrics. Drop the impact essay, send a short reproducer with the
+  few lines that matter, and make each point once.
+
+- Separate what you observed from what you inferred. A rough CVSS is fine, we
+  re-derive severity anyway, but a heap corruption that turns out to be a crash
+  costs us a full analysis.
+
 # Vulnerability Policy
 
 Our full policy is described at