|
|
@@ -0,0 +1,63 @@
|
|
|
+# Security Policy
|
|
|
+
|
|
|
+Thanks for helping keep MaxKey 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 <https://github.com/dromara/MaxKey/security/advisories/new>.
|
|
|
+ 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
|
|
|
+
|
|
|
+MaxKey is an enterprise-grade Identity and Access Management (IAM) and Single Sign-On (SSO) platform supporting SAML, OAuth2, OIDC, CAS, JWT, and more. 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
|
|
|
+- SSO redirect / open-redirect / ticket exfiltration
|
|
|
+- SAML / OAuth2 / OIDC / CAS protocol implementation flaws
|
|
|
+- JWT / token signature / claims handling flaws
|
|
|
+- Session fixation, password-reset / MFA bypass
|
|
|
+- SSRF in identity-provider metadata fetching
|
|
|
+- Cryptographic misuse in stored secrets / signing keys / passwords
|
|
|
+
|
|
|
+Out-of-scope:
|
|
|
+
|
|
|
+- Findings against intentionally trusted-admin features (e.g. admin-only configuration interfaces).
|
|
|
+- 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 MaxKey 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.
|
MaxKey