安全与隐私白皮书（总览）第 11 章
第 11 章 漏洞披露与安全更新策略
FileBolt 鼓励负责任披露，并以可预期的修复与沟通机制建立信任。 同时，安全能力必须可演进：包括 Web 安全策略、服务端鉴权机制，以及端到端加密/协议实现（例如 cryptoVersion 的升级）。本章给出公开联络方式、处理流程、修复发布与公告原则，并说明版本化演进与弃用策略。
11.0 本章摘要
- MUST：提供公开的漏洞提交通道（例如 security.txt 与支持邮箱）。
- SHOULD：提供加密提交机制（如 PGP 公钥）以便研究者安全提交细节。
- SHOULD：明确响应与修复节奏（SLA/目标时效），并在必要时通过状态页沟通。
- MUST：对可能影响零知识承诺的漏洞（XSS、供应链注入、日志泄露 fragment 等）以最高优先级处置。
- MUST：实现版本化演进（
cryptoVersion），并定义兼容、迁移与弃用策略。
11.1 漏洞提交通道与安全联络
11.1.1 公开入口
- MUST：在
/.well-known/security.txt提供漏洞提交通道、有效期与政策入口。 - MUST：提供可达的安全联系邮箱（例如
support@filebolt.net或专用security@filebolt.net）。 - SHOULD：在站点 安全与隐私 页面提供简要说明与提交指引。
11.1.2 加密提交与敏感信息处理
- SHOULD：提供 PGP 公钥（或等效方式）以便研究者加密提交复现细节。
- MUST：内部处理时对漏洞细节实施最小可见原则，仅向需要修复的人员披露。
- MUST：禁止研究者在报告中包含用户明文内容、CEK、URL fragment 或可推导密钥材料；若不慎包含，团队 MUST 按敏感事件处理并限制扩散。
11.2 处理时效与沟通原则
处理时效取决于团队规模与漏洞复杂度，但项目 SHOULD 给出可预期的目标节奏，并在无法达成时及时沟通。 以下为推荐的目标（可按实际调整并在 /security 或 security.txt 中公开）：
- 首次响应：例如 48 小时内确认收到并分配追踪编号。
- 初步评估：例如 7 天内完成严重度分级与影响范围判断。
- 修复发布：按严重度分级推进，P0/P1 优先修复并快速发布。
SHOULD：在处理过程中保持必要沟通（例如已复现/未复现、需要补充信息、预计修复窗口），并避免公开披露可直接被滥用的细节。
11.3 漏洞披露流程（接收、确认、修复、发布、公告）
- 接收：记录报告信息、复现步骤、影响面与研究者联系方式，分配负责人并建立跟踪。
- 确认：在隔离环境复现，评估影响范围、可利用性与受影响组件（前端/后端/边缘/存储）。
- 修复：实施补丁，添加测试与回归用例，必要时增加防护规则（WAF/速率限制/策略收紧）。
- 发布：灰度发布并监控关键指标；确认无回归、无新增风险后全量发布。
- 公告：在不扩大攻击面的前提下公开说明影响、修复内容与用户需要采取的行动（如有）。
对严重漏洞或用户影响较大的事件，SHOULD 通过 /status 发布事件更新或事后报告，并与第 10 章的事件响应流程保持一致。
11.4 影响零知识边界的漏洞（优先级与处置）
零知识承诺的核心是：服务端不可获得 CEK，下载/解密环境尽可能隔离且不引入第三方脚本。 因此，以下类别的漏洞 MUST 作为最高优先级处理：
- XSS / 注入：可能在下载/解密页执行任意脚本，读取 fragment 或内存密钥材料。
- 供应链注入：依赖包被投毒、构建产物被替换、CDN/边缘注入导致脚本被篡改。
- 日志/监控泄露：URL fragment、CEK、token 或明文内容被意外记录并可被访问。
- 错误的资源加载策略：下载/解密页引入第三方脚本、CSP 放宽导致执行面扩大。
对上述漏洞，处置应包含：立即遏制（下线风险代码/收紧策略/封禁攻击向量）、快速发布修复、回溯影响范围， 并在公告中明确“是否可能导致密钥材料泄露或明文暴露”的判断依据。
11.5 安全更新与回归验证
- MUST：对安全相关变更建立回归用例（鉴权、访问控制、CSP、日志过滤、加密流程等）。
- SHOULD：对关键页面（下载/解密页）做自动化检查，确保无第三方脚本与响应头策略符合预期。
- SHOULD：修复发布后进行外部可验证项复测（例如 TLS/安全响应头扫描）。
- SHOULD：对修复引入的兼容变化（例如旧链接/旧 manifest）在文档中明确说明。
与第 12 章一致：第三方扫描可以验证部分 Web 基线，但无法直接证明零知识/E2EE 的全部实现细节； 因此回归验证应同时覆盖协议实现与可见基线。
11.6 协议与密码学版本化（cryptoVersion 演进）
FileBolt 的加密与协议实现 MUST 支持版本化，以便升级算法参数、修复实现缺陷、引入更强隔离策略。 推荐使用显式字段（例如 cryptoVersion）绑定到 manifest/元数据中。
- 显式版本：每个 transfer/manifest MUST 声明其
cryptoVersion，以确定算法、参数与编码规则。 - 版本不可隐式推断：客户端 MUST 基于 manifest 显式字段决定解析与解密逻辑，不应依赖猜测或回退试探。
- 失败关闭：遇到未知版本或参数不一致时 MUST 失败关闭，不得降级到不安全模式。
11.7 兼容、迁移与弃用策略
11.7.1 向后兼容
- SHOULD：在过渡期内，客户端支持读取旧版本 transfer，以减少对用户历史链接的影响。
- MUST：对旧版本的安全边界、限制与弃用计划进行公开说明。
11.7.2 迁移方案（保持零知识）
- SHOULD：如需从旧版本迁移到新版本，应提供“重新发布/重新加密”的用户侧路径。
- MUST：迁移过程中保持零知识：重新加密在客户端完成，服务端不可获得 CEK 或明文。
11.7.3 弃用与停用
- MUST：对被认为不再安全的版本提供明确停用时间表。
- SHOULD：在 UI/文档中提示用户重新发布，并尽量给出足够迁移窗口。
- MUST：停用后，客户端遇到被弃用版本应明确提示，不应尝试继续解密。
11.8 相关 Claim IDs（预留）
本章涉及“漏洞披露通道、处理流程、版本化演进与弃用策略”等声明。 对应 Claim IDs 将补充到 附录：Claim IDs 总表 中，并以总表为唯一权威入口。