ZeroWeb 还在快速迭代，但安全问题还是要按安全问题来处理。我们欢迎负责任的漏洞报告。

现在只会优先处理这两个范围里的安全问题：

• main 分支最新提交
• 最新发布或最新可识别的稳定快照

更旧的分支或历史提交通常不会单独回补。

请不要在公开 issue、PR 或讨论区直接披露漏洞细节。

优先走这两个渠道：

1. 仓库托管平台提供的 private vulnerability reporting / security advisory
2. 维护者在仓库主页或个人资料中提供的私密联系方式

如果现在没有私密渠道，就开一个不带 exploit 细节的最小公开 issue，只说你需要一个安全沟通渠道。

未披露漏洞、利用样例、临时修复分支、私密 advisory 编号、密钥和凭据都属于 C3 受限信息：

• 只能在 private vulnerability reporting / security advisory 或维护者指定的私密通道中讨论
• 由私密通道内指定的人类责任维护者接管，AI 和 bot 不能成为批准主体
• 公开 issue、proposal、PR、commit message 和 CODEOWNERS 不得包含相关细节或私密编号
• 对外披露完成后，公开修复仍需按 贡献责任边界 执行 review、验证和 adoption

如果公开 PR 意外泄漏未修复漏洞，请停止普通 review，并立即转入上述私密流程。

请尽量提供：

• 受影响的提交、分支或版本
• 漏洞类型和影响范围
• 复现步骤或最小 PoC
• 触发条件、平台信息和依赖环境
• 你对严重性的初步判断
• 是否已知有公开利用

维护者会尽量按这个节奏来：

• 5 个工作日内确认收到
• 10 个工作日内完成初步分级
• 在修复期间持续同步关键进展

这是期望节奏，不是强 SLA。毕竟项目现在还是实验阶段。

这几类问题最值得直接报给我们：

• 同源策略、CORS、CSP、Cookie、导航隔离相关缺陷
• 渲染进程、脚本沙箱、WASM 沙箱的逃逸或越权
• 资源加载、URL 处理、缓存和存储隔离错误
• 可能导致崩溃、拒绝服务或资源耗尽的解析器输入
• 第三方依赖中的已知高危漏洞

下面这些情况通常不按安全漏洞处理：

• 纯样式错误或视觉回归
• 没有安全影响的性能下降
• 尚未实现功能导致的预期失败
• 许可证策略讨论或普通依赖升级建议

一般会等修复可用之后再公开细节。公开说明通常会带上：

• 问题摘要
• 影响范围
• 修复提交或版本
• 临时缓解措施