本仓库欢迎公开使用、二次开发、商业使用，以及人类或 AI 参与的协作式开发。

与此同时，任何使用方式都不应以牺牲安全性为代价。若你发现安全问题，请遵循本文件中的披露方式，不要直接公开漏洞细节。

当前默认支持以下范围内的安全问题处理：

• 默认分支上的最新代码
• 最近一次公开发布或可识别的稳定快照

通常不承诺为以下内容单独提供安全修复：

• 长期未同步的历史分支
• 第三方 Fork 中自行引入的问题
• 明显脱离本仓库主干的定制化改造

如果你认为发现了安全漏洞，请不要直接公开：

• 完整利用方式
• 可直接复现的攻击脚本
• 密钥、令牌、凭据、内部地址或敏感配置
• 可能导致真实系统被直接利用的细节

请优先通过私下方式联系维护者。

如果当前仓库尚未公开专用安全邮箱或私密报告入口，请采用以下方式：

1. 先通过仓库所有者或维护者在平台资料页中提供的私下联系方式联系。
2. 如果找不到私下联系方式，可提交一个不含漏洞细节的 Issue，只说明“发现潜在安全问题，需要私下沟通”。
3. 在建立私下沟通渠道后，再提供完整细节。

为了让问题更快被确认，建议在报告中包含：

• 漏洞类型与影响范围
• 受影响的文件、模块、接口或页面
• 复现步骤
• 触发条件
• 影响评估
• 可选的修复建议或临时缓解方案

如果问题与依赖、部署配置、供应链或 AI 自动化流程有关，也请一并说明。

在没有不可抗力或维护中断的情况下，维护者通常会尽量按以下节奏处理：

• 7 个自然日内确认是否收到报告
• 14 个自然日内给出初步判断或补充信息请求
• 在确认问题成立后，根据严重程度安排修复、缓解或公开说明

这些时间是目标值，不构成法律承诺或服务等级协议。

维护者在处理安全问题时会尽量遵循以下原则：

• 先修复或缓解，再公开细节
• 仅披露对用户判断风险和升级必要的信息
• 尽量避免把敏感利用路径留在公开讨论区
• 对合理、善意、负责任的披露保持欢迎态度

如果问题来自第三方依赖、平台服务或外部组件，维护者可能需要等待上游修复或同步披露窗口。

以下情况通常不视为本仓库需要单独处理的安全漏洞：

• 仅存在于你自己的私有部署、私有配置或私有数据中的问题
• 缺少现实攻击路径、仅为理论风险且无明确影响说明的问题
• 已由上游依赖公开披露、且本仓库无法独立修复的问题
• 与社会工程学、物理接触、账号自行泄露等外部因素直接相关的问题

开源不等于免运维。无论你是人类开发者还是 AI/Agent 使用者，都应自行负责：

• 审核引入的依赖、脚本、模型、数据和凭据管理方式
• 在生产环境中进行最小权限配置
• 对 AI 生成或修改的代码进行安全审查
• 在发布前进行必要的测试、扫描和人工复核

我们欢迎负责任的安全报告，也感谢帮助项目降低风险的研究者和贡献者。