From 89f71f2126b02007f0ad1cf81907ae74ab64316e Mon Sep 17 00:00:00 2001 From: Martin Vogel Date: 2026年6月21日 21:43:21 +0200 Subject: [PATCH] docs(security): coordinated-disclosure process + realistic reporting policy Add docs/SECURITY-DISCLOSURE.md describing how vulnerability reports are handled end to end (private fix, cross-platform validation, reporter verification, patched release, then a GitHub Security Advisory with a CVE and credit). Update SECURITY.md: add GitHub private vulnerability reporting as the preferred channel, replace the over-tight 48h/7-day commitment with honest best-effort targets for a solo-maintained project, add a safe-harbor statement, and refresh the stale supported-versions table (0.5.x -> 0.8.x). Signed-off-by: Martin Vogel --- SECURITY.md | 56 ++++++++++++++++++++---- docs/SECURITY-DISCLOSURE.md | 87 +++++++++++++++++++++++++++++++++++++ 2 files changed, 134 insertions(+), 9 deletions(-) create mode 100644 docs/SECURITY-DISCLOSURE.md diff --git a/SECURITY.md b/SECURITY.md index 8ce0d025b..22e1c668a 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -26,13 +26,47 @@ Please report **privately** rather than as a public issue so we can fix before p ## Reporting a Vulnerability -If you discover a security vulnerability, please report it responsibly: - -1. **Do NOT open a public issue** for security vulnerabilities -2. Email: martin.vogel.tech@gmail.com -3. Include: description, reproduction steps, affected version, potential impact - -We will acknowledge your report within 48 hours and provide a fix timeline within 7 days. +If you discover a security vulnerability, please report it **privately** so we +can fix it before public disclosure: + +1. **Do NOT open a public issue, PR, or social-media post** for security + vulnerabilities. +2. **Preferred:** use GitHub's [private vulnerability reporting](https://github.com/DeusData/codebase-memory-mcp/security/advisories/new) + (the repository's **Security → Report a vulnerability** button). This keeps + everything in one place and starts a private advisory automatically. +3. **Alternative:** email martin.vogel.tech@gmail.com. +4. Include: description, reproduction steps, affected version, and potential + impact. +5. Include your **GitHub handle and a contact email**. We use these to credit + you and to invite you (read-only) to privately verify the fix before its + release — see step 4 of the + [handling process](docs/SECURITY-DISCLOSURE.md#what-happens-after-you-report). + Let us know if you would prefer to remain anonymous. + +> **This is a solo, volunteer-maintained project, so security handling is +> best-effort.** As good-faith targets — not guarantees — we aim to: +> +> - **acknowledge** your report within **7 days** (usually much sooner); +> - give an **initial assessment and severity** within **14 days**; +> - **develop, validate, and release a fix** as quickly as the severity +> warrants — typically within **90 days**, and expedited for high-severity +> issues. +> +> If something will take longer, we will tell you and keep you updated. + +We follow **coordinated disclosure**: fixes are developed privately, validated +across all supported platforms, released, and only then disclosed publicly via a +[GitHub Security Advisory](https://github.com/DeusData/codebase-memory-mcp/security/advisories) +with a **CVE** and credit to you. The full handling process — including how you +can verify the fix before release — is documented in +[`docs/SECURITY-DISCLOSURE.md`](docs/SECURITY-DISCLOSURE.md). + +### Safe harbor + +We will not pursue or support legal action against researchers who act in good +faith — accessing only their own test data, avoiding privacy violations and +service disruption, and giving us reasonable time to fix before public +disclosure. Research conducted under this policy is considered authorised. ## Security Measures @@ -103,5 +137,9 @@ sha256sum -c checksums.txt | Version | Supported | |---------|-----------| -| 0.5.x | Yes | -| < 0.5 | No (Go codebase, superseded by C rewrite) | +| Latest `0.8.x` | Yes — security fixes land in the newest release | +| < 0.8 | No — please upgrade to the latest release | + +Only the latest release is supported. Security fixes are shipped in a new +patched release rather than backported to older versions; upgrading to the +newest version is the supported path to receive them. diff --git a/docs/SECURITY-DISCLOSURE.md b/docs/SECURITY-DISCLOSURE.md new file mode 100644 index 000000000..044737007 --- /dev/null +++ b/docs/SECURITY-DISCLOSURE.md @@ -0,0 +1,87 @@ +# Security Disclosure & Handling Process + +This document explains **how security reports are handled** for +codebase-memory-mcp — what happens after you report a vulnerability, what you +can expect from us, and how disclosure and credit work. + +For **how to report** a vulnerability and **what is in scope**, see +[`SECURITY.md`](../SECURITY.md). This document covers the process *after* a +report arrives. + +> **This is a solo, volunteer-maintained project.** Everything below is handled +> on a good-faith, best-effort basis. The timeframes are honest targets we aim +> to beat — not contractual guarantees. If something will take longer, we will +> tell you and keep you updated rather than go silent. + +## Principles + +We follow **coordinated disclosure**: + +1. **Fix privately, disclose publicly.** Details of an unfixed vulnerability are + never discussed in the open. We develop and validate the fix in private, ship + a release, and only then disclose. +2. **Patch before publicity.** A fixed release is always available *before* the + vulnerability is described publicly, so users can update immediately. +3. **Credit the researcher.** Public credit by default; anonymity on request. +4. **A bug fixed once should stay fixed.** Every fix ships with a regression + test or guard so the same class of issue cannot silently return. + +## What happens after you report + +| Step | What we do | Target (best-effort) | +|------|------------|----------------------| +| 1. **Acknowledge** | Confirm we received your report and are looking at it. | within **7 days** (usually much sooner) | +| 2. **Triage & severity** | Reproduce the issue and assign a severity (CVSS). | within **14 days** | +| 3. **Fix privately** | Develop the fix in a private environment, with a regression guard, and validate it across all supported platforms (Linux, macOS, Windows) under full CI. | severity-dependent | +| 4. **You verify** | We invite you (read-only) to confirm the fix resolves the issue and that the guard prevents regression. Your sign-off is welcomed; an unresponsive reporter will not indefinitely block a release. | — | +| 5. **Release** | Merge the fix and cut a patched release promptly. | as fast as severity warrants | +| 6. **Disclose** | Publish a [GitHub Security Advisory](https://github.com/DeusData/codebase-memory-mcp/security/advisories), request a **CVE** (GitHub is a CNA), and credit you. | after a short upgrade window | + +**Overall fix timeline:** we aim to resolve and release a fix within **90 days** +of triage, and much faster for high-severity issues. Critical, actively +exploitable issues are handled with the highest priority. + +## Severity + +We assess severity using **CVSS** and prioritise accordingly. Roughly: + +- **Critical / High** — remote code execution, sandbox/scope escape, supply-chain + compromise. Prioritised; expedited release. +- **Medium** — issues requiring local access, non-default configuration, or + significant user interaction. +- **Low** — defense-in-depth gaps, hardening, information exposure with limited + impact. + +## Credit & CVE + +- You are **credited by name/handle** in the published advisory unless you ask to + remain anonymous. +- A **CVE identifier** is requested for each distinct vulnerability via the + GitHub Security Advisory (one CVE per vulnerability, not per report — a single + report may yield several). +- The advisory lists the **affected and patched version ranges** so downstream + tooling (e.g. Dependabot) can alert users automatically. + +## Safe harbor + +We will not pursue or support legal action against researchers who act in +**good faith**, meaning you: + +- only access, modify, or store data in **your own test environment**; +- avoid privacy violations, data destruction, and degradation of service for + others; +- give us a **reasonable opportunity to fix** the issue before disclosing it + publicly; +- do not exploit the issue beyond the minimum necessary to demonstrate it. + +Good-faith research conducted under this policy is considered authorised, and we +will work with you, not against you. + +## What we ask of you + +- Report **privately** (see [`SECURITY.md`](../SECURITY.md)) — not as a public + issue, PR, or social-media post. +- Give us **reasonable time** to fix before any public write-up. +- Provide enough detail to **reproduce** (affected version, steps, impact). + +Thank you for helping keep a tool used by developers worldwide safe. 🙏

AltStyle によって変換されたページ (->オリジナル) /