感谢你关注 NineKgTools 的安全问题。我们非常重视每一份负责任的漏洞报告。
| 版本 | 是否接收安全更新 |
|---|---|
| 1.x | ✅ 全力支持 |
| < 1.0 | ❌ 不再支持 |
请不要通过 GitHub 公开 Issue 报告安全漏洞。 这样会让漏洞在修复之前暴露给潜在攻击者。
请使用 GitHub 的私密漏洞报告通道（仅维护者可见，不会公开）：
路径：仓库主页 → Security 标签页 → Advisories → Report a vulnerability
这个通道由 GitHub 提供，比邮件更安全：
- 报告内容默认私密，仅你和维护者可见
- 修复后可以一键升级为公开 Advisory（含 CVE 申请）
- 全程在 GitHub 内闭环，无需暴露任何邮箱
报告标题建议以 [SECURITY] 开头，例如 [SECURITY] SQL 注入 in SearchService。
为了让我们尽快定位与修复，请尽量在报告里说明：
- 漏洞类型（如 XSS、SQL 注入、鉴权绕过、敏感信息泄露、SSRF 等）
- 影响范围（哪些功能 / 哪些用户角色受影响）
- 复现步骤（越详细越好，包括样例 payload）
- 受影响版本（commit hash 或 tag）
- 部署方式（Docker / dotnet run / Desktop）
- 潜在危害（数据泄露？权限提升？DoS？）
- 建议修复方案（可选）
- 你希望如何被署名致谢（可选，包括不署名）
| 阶段 | 目标时限 |
|---|---|
| 首次确认收到报告 | 3 个工作日以内 |
| 初步评估与分级 | 7 个工作日以内 |
| 修复或缓解方案 | 取决于严重程度，一般 30 天以内 |
| 公开披露 | 收到报告后 90 天，或与报告者协商后确定 |
在修复发布前，请对漏洞细节保密。
- 我们采用 协调披露（Coordinated Disclosure） 模式
- 修复发布后，我们会在
CHANGELOG.md的Security小节记录变更 - 若报告者同意，我们会在 Release Note 与致谢名单中署名
- 达到 90 天仍未修复时，我们会主动与报告者协商展期或同意其公开披露
以下情况不属于安全漏洞，请不必专门报告：
- 依赖了第三方（OpenAI、Bangumi、DLsite、Steam）的可用性或响应内容——这些由各自服务方负责
- 本地部署下
config.yaml中明文存储的 API Key —— 这是自托管工具的常规权衡；建议使用环境变量覆盖 - 默认端口 23333 无 HTTPS —— 设计预期是前置反向代理（Nginx / Caddy / Traefik）终止 TLS
- Docker 镜像不自带 Chromium —— 为镜像体积考虑的有意选择，不影响安全性
感谢所有负责任披露漏洞的安全研究人员。每一份认真的报告都在帮助这个项目变得更好。