From a7b83b1cfe6b9e32714b5057e9838201af3fc67e Mon Sep 17 00:00:00 2001 From: eddieran Date: Wed, 6 May 2026 18:12:43 +0800 Subject: [PATCH] chore: add SECURITY.md with private vulnerability reporting guidance MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit mayfly-go currently has no security policy on file. GitHub's "Suggest a security policy" workflow flags this and offers researchers a friction-free way to send a draft PR. This is that draft. It documents: - The preferred private channel: GitHub Private Vulnerability Reporting (https://github.com/dromara/mayfly-go/security/advisories/new) once enabled in *Settings → Code security → Private vulnerability reporting*. - A fallback email channel — placeholder for the maintainer to fill in. - What a good report should include. - Scope and supported versions. - Triage / coordinated-disclosure expectations. Maintainers should feel free to edit any section. The important thing is that a private reporting channel exists so researchers can submit findings responsibly without having to choose between "stay silent" and "post to a public issue." Refs #128. --- SECURITY.md | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000..603f722c --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,61 @@ +# Security Policy + +Thanks for helping keep mayfly-go and the wider [dromara](https://github.com/dromara) ecosystem secure. + +## Reporting a vulnerability + +**Please do not open a public issue, discussion, or pull request that describes a suspected vulnerability** — that gives attackers a head-start before a fix lands. + +Use one of these private channels instead: + +1. **GitHub's Private Vulnerability Reporting (preferred).** + Open a private security advisory at . + GitHub automatically routes it to the maintainers, keeps the discussion private until you and the maintainers agree to publish, and (optionally) assigns a CVE on publish. + +2. **Email.** + If GitHub PVR is unavailable to you for any reason, email the project lead directly. Maintainers should add the preferred email here when they configure the policy. + +## What to include + +A good report contains: + +- A clear description of the vulnerability and its impact. +- Steps to reproduce against a specific commit SHA or release tag. +- Affected code locations (`file:line`) where useful. +- A suggested fix or mitigation if you have one. +- Whether you'd like credit in the published advisory and, if so, under what name. + +## Scope and supported versions + +mayfly-go is a self-hosted DevOps platform. The maintainers support security fixes on the latest minor release. Older releases will not generally receive backports. + +In-scope vulnerability classes include: + +- Authentication / authorization bypass +- Server-side request forgery (SSRF), command injection, path traversal +- Insecure deserialization +- Broken access controls in the machine, db, redis, mongo, or auth modules +- Cryptographic misuse in stored secrets / credentials + +Out-of-scope: + +- Findings against intentionally trusted-admin features (e.g. the SSH/RDP terminal — admin-controlled by design). +- Issues that require an attacker to already have full database / server access. +- Best-practice complaints without a concrete impact (e.g. "this header should be set", "TLS version should be raised"). + +## Process + +After you submit: + +1. A maintainer will acknowledge receipt within roughly 1 week. +2. We'll triage the report: confirm severity, scope, and reproducibility. +3. We'll work with you on a fix and a coordinated disclosure timeline (typically up to 90 days, longer if the fix is structural). +4. On publication, we credit you in the advisory unless you ask not to be credited. + +## Hall of fame + +Reporters who have helped harden mayfly-go via responsible disclosure will be listed here once the corresponding advisory is published. + +--- + +This policy is suggested via [GitHub's "Suggest a security policy" workflow](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository). Maintainers can edit any section freely; the most important thing is that **a private reporting channel exists** so researchers can submit findings responsibly.