BiliMusic 是本地运行的开源客户端：程序在你的机器上直接与 B 站通信，账号凭据只保存在本地，不存在由项目方运营的服务端。因此这里关心的安全问题只有两类——你的账号会不会因此泄露，以及你的机器会不会被这个程序弄坏。

首选渠道：GitHub 私密漏洞报告（Private vulnerability reporting）

👉 提交私密安全报告

1. 受影响的版本与平台：例如 v1.11.0 / Windows 11 25H2，或 commit hash。
2. 漏洞类型：凭据泄露 / 本地文件越权 / 更新链路 / 局域网同步 / 依赖漏洞 …
3. 复现步骤：能稳定复现的最短路径。
4. 影响评估：攻击者能拿到什么、需要什么前提（例如「需要与受害者同一局域网」）。
5. 可选：PoC、相关日志（请先自行脱敏）。

• 48 小时内确认收到并给出初步判断。
• 判定成立的漏洞，修复后会在 Release Notes 中致谢（你希望匿名也可以，直接说）。
• 在修复版本发布前，不公开漏洞细节；披露时间与你协商。
• 判定为「非漏洞」的，我们会说明理由——这份文档下面的范围界定就是为了减少这类分歧。

• 本地凭据以明文形式落盘：Cookie、refresh_token 保存在 shared_preferences 中。这是当前的有意设计——桌面与移动端的应用私有目录默认不对其他应用开放，加密密钥同样得存在同一台机器上，收益有限。若你所在环境（已 root / 越狱、共享账户、或存在本地恶意软件）使该假设不成立，那属于运行环境自身的威胁模型，不是本项目的漏洞。欢迎以普通 Issue 的形式讨论改进方案（例如接入系统钥匙串），但请不要当作安全漏洞上报。
• 需要物理或管理员权限才能利用的问题、已 root / 越狱设备上的任意本地数据读取。
• B 站服务端的行为：本项目不控制也不逆向 B 站服务，其接口策略、风控、封号判定与我们无关。
• 第三方依赖自身：请向上游报告；如果本项目对其有可实际触发的调用路径，那部分仍算我们的（见上表最后一行），会尽可能修复。
• 纯理论、无复现路径、或需要「用户先自己把恶意文件放进应用目录」的报告。
• 社会工程学：伪造 Release 页面、冒充维护者索要凭据等。请开 Issue 提醒我们，但不要走漏洞通道。
• 把本地文件打包上传至阿里云OSS：我们没有云服务器，也没有存储密钥。

提交代码时请遵守以下底线：

1. 不提交任何凭据：Cookie、SESSDATA、refresh_token、账号密码、设备指纹，以及含上述内容的日志或抓包文件。
2. 出站请求只有一个装配入口：所有请求头由 NetworkConfig.headersFor(uri) 装配，不要手写 Cookie 头，也不要新增绕过它的请求路径。
3. 新增出站目标必须显式评审：把数据发往 B 站及其 CDN 之外的域名（尤其是任何遥测、统计、错误上报服务）属于需要讨论的变更，不能顺手加上。
4. 新依赖需评估：引入新的 pub / npm 依赖时，请说明来源与用途；Vela 端同样不要引入与主项目无关的依赖。
5. 更新链路不得放宽校验：assets/version.json 与 Release 解析、下载、校验、替换的链路是攻击面，改动请附带测试。

安全修复只针对最新 Release 与 dev 分支（开发主线）。较早版本请先升级再验证问题是否仍然存在。