OpenVigil 当前是生产候选实现。Demo、单元测试、本地开发栈或历史审计的通过结果，不能证明某个部署已满足生产安全要求。本政策说明安全问题的报告方式、处理范围及部署时应保留的安全边界。
安全修复优先面向 main 的最新代码。项目尚未建立多个发行分支的长期安全维护周期。
| 代码范围 | 处理方式 |
|---|---|
main 最新代码 |
接收报告，优先复现、评估并修复。 |
| 历史 commit、旧 tag 和自行修改的版本 | 可报告问题；通常需在最新代码上确认，不保证向历史版本回补。 |
| 第三方依赖与外部服务 | 评估其对 OpenVigil 的实际影响；上游问题也应通过对应项目的安全渠道报告。 |
请报告身份验证、权限提升、跨租户或跨资产访问、密钥泄漏、注入、SSRF、文件/制品访问、审计绕过、依赖利用，以及模型提示注入导致越权、证据伪造或未经授权业务动作等问题。
具体部署的账号、密钥和数据由部署方管理。部署事故应同时联系该环境的负责人员；仓库维护者无法替部署方撤销凭据或隔离现场系统。
不要在公开 Issue、PR、评论或附件中发布利用步骤、有效凭据、客户数据或完整漏洞证明。
首选 仓库 Security 页面 中的 Report a vulnerability，通过 GitHub 私密漏洞报告与维护者沟通。该入口需要仓库单独启用；添加本文件不会自动启用此功能。
截至 2026-09-29，仓库的私密漏洞报告功能未启用，也未公布专用安全联系邮箱。如果入口不可用，请先在 GitHub Issues 提交一个仅请求私密联系方式的问题，例如：
我希望私下报告一项潜在安全问题，请提供合适的私密报告渠道。
这一步不提供受影响接口、影响描述、复现方法、日志或截图。维护者提供私密渠道后，再发送详细报告。GitHub 的私密报告说明介绍了入口和未启用时的联系方式申请流程。
一般功能缺陷和不含敏感信息的开发问题可以使用普通 Issue，见 贡献指南。
请通过私密渠道提供尽可能小且可重复验证的报告：
- 受影响 commit、版本或镜像 digest，运行模式（Demo / Production）及组件。
- 环境与配置前提，包括所需身份、角色、数据范围和访问条件；不包含实际密码或 token。
- 漏洞类型、预期安全边界、实际行为和可能影响。
- 使用隔离环境与脱敏/合成数据的复现步骤或最小 PoC。
- 必要的错误信息、请求 ID、经过脱敏的日志，以及可选的修复建议。
- 模型相关问题说明输入来源、提示注入位置、输出或业务动作如何越过权限/证据边界；勿发送完整私有知识库或真实现场资料。
不能安全提供某项信息时，请说明限制，无需获取更多真实用户数据来证明影响。
维护者会尽力确认报告、评估影响、在隔离环境复现，并协调修复与验证。调查可能需要进一步的环境或复现信息。
请与维护者协调公开时间、修复版本、缓解措施和署名意愿；安全修复讨论及完整 PoC 在协调披露前应保持私密。需要公开通知时，可使用 GitHub Security Advisories。
项目未承诺固定响应时限、修复 SLA 或漏洞奖励；不要将提交报告理解为已确认漏洞或已安排奖励。
- 仅测试自己拥有或获得明确授权的实例、账号和数据。
- 优先在隔离环境验证，使用最小请求量和合成数据，记录必要证据后停止。
- 不对第三方部署进行未授权扫描、拒绝服务、批量数据获取、凭据猜测或破坏性操作。
- 不为了复现问题操纵真实风机、SCADA、CMS、EAM 或其他现场系统；这类验证需要部署方的专门授权与安全安排。
- 不修改生产数据、关闭鉴权或削弱审计来让测试通过；普通单元测试的替身不能作为真实安全验收证据。
- 普通本地运行使用被 Git 忽略的根
.env；生产凭据由批准的 secret manager 提供。不要将密钥写入源码、前端 bundle、测试、PR、日志或截图。 - 隔离开发栈的配置、临时凭据及日志保存在
.artifacts/local-stack/；业务 E2E 的配置、trace 和私有日志也可能包含临时凭据。不要直接公开或提交这些目录，分享报告前进行脱敏。 - 为模型、embedding、对象存储、遥测来源、身份委托和监控使用各自适当范围的凭据。示例
dev-*值与测试鉴权开关不能用于生产。 - 生产保持 TLS、服务端身份验证、RBAC、数据范围、请求校验、速率限制和审计；浏览器显示或前端状态不能代替后端授权。
- 上传地址和外部调用目标需保持来源及目标约束；不要为了排障放开通配符来源、任意 URL 或对象存储访问权限。
- 将模型、知识库和外部数据内容视为不可信输入。模型输出必须经过结构、证据和业务规则校验，高风险审批仍由有权限的人完成；供应商失败不能静默退回演示推理。
- 现场数据进入外部模型、存储或报告前，应确认部署方允许的数据范围；诊断成功不代表数据发送或业务动作已获得授权。
发现凭据泄漏时，先联系凭据所有者撤销或轮换，再检查访问记录、影响范围和传播位置，并通过私密渠道报告。只删除文件或修改 Git 历史不能使已泄漏的凭据失效。保留调查所需证据，公开材料须脱敏。
部署方应使用经审阅的锁文件与固定构建输入，执行依赖审计、镜像扫描、SBOM 和签名验证，并保留与同一 commit、release ID、镜像 digest 绑定的验收证据。实际发布门禁见 发布工作流 与 中文 README 的生产验收边界。
不要因配置、依赖或安全检查失败而关闭门禁。healthz 成功只说明进程存活；依赖 readiness、身份/权限、数据隔离、恢复及外部安全验证应分别完成。Sites 的 Web 发布成功也不能替代 Python 后端、依赖与现场系统的安全验收。
开发中的安全检查和 PR 要求见 CONTRIBUTING.md；它们是工程验证的一部分，不构成“没有漏洞”的保证。