SECURITY.md: require working repro and trust-boundary impact (#9990)

* SECURITY.md: require working repro and trust-boundary impact

Funnel reports through GitHub private vulnerability reporting, require a
reproduction against a supported version, and spell out the trust model so
internal-cluster exposure and example-config issues are out of scope.
Unvalidated scanner/AI output is handled as hardening, not as an advisory.
CVEs minted by third parties outside this process may be disputed.

* SECURITY.md: drop email channel, GitHub private reporting only

SECURITY.md

@@ -1,24 +1,78 @@
 # Security Policy
 
-## Reporting a Vulnerability
+## Supported versions
 
-If you find a security issue in SeaweedFS, please report it privately:
+Security fixes land in the latest release. Please reproduce against a recent
+release or `master` before reporting; issues that only reproduce on old,
+unsupported versions are not eligible for a fix or an advisory.
 
-- Email: support@seaweedfs.com  
-- Do not open a public GitHub issue
+## Reporting a vulnerability
 
-Please include:
-- A clear description of the issue
-- Steps to reproduce (if possible)
-- Affected versions
+Report privately through GitHub private vulnerability reporting (the "Report a
+vulnerability" button under the repository's Security tab). This keeps the
+report, the fix, and any CVE in one place. Do not open a public issue.
 
-## Response
+### What a report must include
 
-- We will respond as soon as possible (usually within 1 business day)  
-- We will investigate and work on a fix  
-- We may coordinate disclosure with you
+We can only act on reports that show real impact. Please include:
 
-## Notes
+- Affected version (a release tag or `master` commit you reproduced on)
+- The exact deployment and configuration: which components are running
+  (master, volume, filer, S3, admin), which ports are reachable by the
+  attacker, and what authentication is enabled
+- The attacker's starting position: unauthenticated, a valid S3 user, an admin,
+  or someone with access to the internal cluster network
+- The trust boundary that is crossed (e.g. an unauthenticated client reading
+  another tenant's data, an S3 user escalating to admin)
+- A minimal, working reproduction or proof of concept
+- Expected vs. actual behavior
 
-- Please allow time for a fix before public disclosure  
-- If you’re unsure whether something is a security issue, feel free to reach out
+A report without a working reproduction and a clear trust boundary is a
+hardening suggestion, not a vulnerability. We are glad to receive those, but
+they are handled on the normal issue tracker, not as security advisories.
+
+### Automated and AI-assisted reports
+
+Output from static analysis, dependency scanners, fuzzers, or LLMs is welcome
+only when you have manually validated it and can supply a working reproduction
+against a supported version, per the requirements above. Raw tool output,
+speculative findings, or generated reports without a demonstrated exploit will
+be closed as hardening suggestions.
+
+## Trust model
+
+SeaweedFS is built to run with its cluster components (master, volume servers,
+and the raw filer API) on a trusted network. Those internal APIs are not an
+authentication boundary unless you explicitly enable a control (for example
+volume JWT or filer authentication) and that control is bypassed. Exposing an
+internal port directly to untrusted clients is a deployment mistake, not a
+vulnerability in SeaweedFS.
+
+Reports are in scope when they cross a boundary SeaweedFS is meant to enforce,
+for example:
+
+- Unauthenticated access to data or operations that require authentication
+- One S3 identity reading, writing, or deleting another identity's data
+- Privilege escalation from a normal S3 user to administrative capability
+- Bypass of Object Lock / retention where it is configured
+- Remotely triggered data corruption or loss
+
+Reports are generally out of scope when they require:
+
+- Direct access to an internal cluster port that is meant to be private
+- Full master, filer, or volume server access (already a full compromise)
+- An insecure example configuration rather than a documented secure setup
+- Local-only impact on a host the attacker already controls
+
+## CVE assignment
+
+When a report is confirmed, we publish an advisory and request the CVE through
+GitHub. CVEs assigned by third parties without coordinating with us, or for
+issues that do not cross a boundary described above, may be disputed.
+
+## Response and disclosure
+
+- We aim to acknowledge a valid report within a few business days.
+- We will investigate, work on a fix, and coordinate a disclosure timeline
+  with you.
+- Please allow time for a fix before any public disclosure.