Skip to content

Commit 53ebeb4

Browse files
DeusDataDeusData
committed
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 <martin.vogel@datadice.io>
1 parent 1519f86 commit 53ebeb4

2 files changed

Lines changed: 134 additions & 9 deletions

File tree

‎SECURITY.md‎

Lines changed: 47 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -26,13 +26,47 @@ Please report **privately** rather than as a public issue so we can fix before p
2626

2727
## Reporting a Vulnerability
2828

29-
If you discover a security vulnerability, please report it responsibly:
30-
31-
1. **Do NOT open a public issue** for security vulnerabilities
32-
2. Email: martin.vogel.tech@gmail.com
33-
3. Include: description, reproduction steps, affected version, potential impact
34-
35-
We will acknowledge your report within 48 hours and provide a fix timeline within 7 days.
29+
If you discover a security vulnerability, please report it **privately** so we
30+
can fix it before public disclosure:
31+
32+
1. **Do NOT open a public issue, PR, or social-media post** for security
33+
vulnerabilities.
34+
2. **Preferred:** use GitHub's [private vulnerability reporting](https://github.com/DeusData/codebase-memory-mcp/security/advisories/new)
35+
(the repository's **Security → Report a vulnerability** button). This keeps
36+
everything in one place and starts a private advisory automatically.
37+
3. **Alternative:** email martin.vogel.tech@gmail.com.
38+
4. Include: description, reproduction steps, affected version, and potential
39+
impact.
40+
5. Include your **GitHub handle and a contact email**. We use these to credit
41+
you and to invite you (read-only) to privately verify the fix before its
42+
release — see step 4 of the
43+
[handling process](docs/SECURITY-DISCLOSURE.md#what-happens-after-you-report).
44+
Let us know if you would prefer to remain anonymous.
45+
46+
> **This is a solo, volunteer-maintained project, so security handling is
47+
> best-effort.** As good-faith targets — not guarantees — we aim to:
48+
>
49+
> - **acknowledge** your report within **7 days** (usually much sooner);
50+
> - give an **initial assessment and severity** within **14 days**;
51+
> - **develop, validate, and release a fix** as quickly as the severity
52+
> warrants — typically within **90 days**, and expedited for high-severity
53+
> issues.
54+
>
55+
> If something will take longer, we will tell you and keep you updated.
56+
57+
We follow **coordinated disclosure**: fixes are developed privately, validated
58+
across all supported platforms, released, and only then disclosed publicly via a
59+
[GitHub Security Advisory](https://github.com/DeusData/codebase-memory-mcp/security/advisories)
60+
with a **CVE** and credit to you. The full handling process — including how you
61+
can verify the fix before release — is documented in
62+
[`docs/SECURITY-DISCLOSURE.md`](docs/SECURITY-DISCLOSURE.md).
63+
64+
### Safe harbor
65+
66+
We will not pursue or support legal action against researchers who act in good
67+
faith — accessing only their own test data, avoiding privacy violations and
68+
service disruption, and giving us reasonable time to fix before public
69+
disclosure. Research conducted under this policy is considered authorised.
3670

3771
## Security Measures
3872

@@ -103,5 +137,9 @@ sha256sum -c checksums.txt
103137

104138
| Version | Supported |
105139
|---------|-----------|
106-
| 0.5.x | Yes |
107-
| < 0.5 | No (Go codebase, superseded by C rewrite) |
140+
| Latest `0.8.x` | Yes — security fixes land in the newest release |
141+
| < 0.8 | No — please upgrade to the latest release |
142+
143+
Only the latest release is supported. Security fixes are shipped in a new
144+
patched release rather than backported to older versions; upgrading to the
145+
newest version is the supported path to receive them.

‎docs/SECURITY-DISCLOSURE.md‎

Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
# Security Disclosure & Handling Process
2+
3+
This document explains **how security reports are handled** for
4+
codebase-memory-mcp — what happens after you report a vulnerability, what you
5+
can expect from us, and how disclosure and credit work.
6+
7+
For **how to report** a vulnerability and **what is in scope**, see
8+
[`SECURITY.md`](../SECURITY.md). This document covers the process *after* a
9+
report arrives.
10+
11+
> **This is a solo, volunteer-maintained project.** Everything below is handled
12+
> on a good-faith, best-effort basis. The timeframes are honest targets we aim
13+
> to beat — not contractual guarantees. If something will take longer, we will
14+
> tell you and keep you updated rather than go silent.
15+
16+
## Principles
17+
18+
We follow **coordinated disclosure**:
19+
20+
1. **Fix privately, disclose publicly.** Details of an unfixed vulnerability are
21+
never discussed in the open. We develop and validate the fix in private, ship
22+
a release, and only then disclose.
23+
2. **Patch before publicity.** A fixed release is always available *before* the
24+
vulnerability is described publicly, so users can update immediately.
25+
3. **Credit the researcher.** Public credit by default; anonymity on request.
26+
4. **A bug fixed once should stay fixed.** Every fix ships with a regression
27+
test or guard so the same class of issue cannot silently return.
28+
29+
## What happens after you report
30+
31+
| Step | What we do | Target (best-effort) |
32+
|------|------------|----------------------|
33+
| 1. **Acknowledge** | Confirm we received your report and are looking at it. | within **7 days** (usually much sooner) |
34+
| 2. **Triage & severity** | Reproduce the issue and assign a severity (CVSS). | within **14 days** |
35+
| 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 |
36+
| 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. | — |
37+
| 5. **Release** | Merge the fix and cut a patched release promptly. | as fast as severity warrants |
38+
| 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 |
39+
40+
**Overall fix timeline:** we aim to resolve and release a fix within **90 days**
41+
of triage, and much faster for high-severity issues. Critical, actively
42+
exploitable issues are handled with the highest priority.
43+
44+
## Severity
45+
46+
We assess severity using **CVSS** and prioritise accordingly. Roughly:
47+
48+
- **Critical / High** — remote code execution, sandbox/scope escape, supply-chain
49+
compromise. Prioritised; expedited release.
50+
- **Medium** — issues requiring local access, non-default configuration, or
51+
significant user interaction.
52+
- **Low** — defense-in-depth gaps, hardening, information exposure with limited
53+
impact.
54+
55+
## Credit & CVE
56+
57+
- You are **credited by name/handle** in the published advisory unless you ask to
58+
remain anonymous.
59+
- A **CVE identifier** is requested for each distinct vulnerability via the
60+
GitHub Security Advisory (one CVE per vulnerability, not per report — a single
61+
report may yield several).
62+
- The advisory lists the **affected and patched version ranges** so downstream
63+
tooling (e.g. Dependabot) can alert users automatically.
64+
65+
## Safe harbor
66+
67+
We will not pursue or support legal action against researchers who act in
68+
**good faith**, meaning you:
69+
70+
- only access, modify, or store data in **your own test environment**;
71+
- avoid privacy violations, data destruction, and degradation of service for
72+
others;
73+
- give us a **reasonable opportunity to fix** the issue before disclosing it
74+
publicly;
75+
- do not exploit the issue beyond the minimum necessary to demonstrate it.
76+
77+
Good-faith research conducted under this policy is considered authorised, and we
78+
will work with you, not against you.
79+
80+
## What we ask of you
81+
82+
- Report **privately** (see [`SECURITY.md`](../SECURITY.md)) — not as a public
83+
issue, PR, or social-media post.
84+
- Give us **reasonable time** to fix before any public write-up.
85+
- Provide enough detail to **reproduce** (affected version, steps, impact).
86+
87+
Thank you for helping keep a tool used by developers worldwide safe. 🙏

0 commit comments

Comments
 (0)