mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-07-27 02:23:23 +00:00
Chris LuandGitHub
b58e9ac3c4
* 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
79 lines
3.4 KiB
Markdown
79 lines
3.4 KiB
Markdown
# Security Policy
|
|
|
|
## Supported versions
|
|
|
|
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.
|
|
|
|
## Reporting a vulnerability
|
|
|
|
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.
|
|
|
|
### What a report must include
|
|
|
|
We can only act on reports that show real impact. Please include:
|
|
|
|
- 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
|
|
|
|
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.
|