cc-safety-net 只为最新发布版本提供安全修正。如果你使用旧版本，请在报告问题前升级，除非最新版本也受到该漏洞影响。
本页说明如何报告问题。信任边界、fail-closed 执行和攻击面见安全模型。策略的权威版本是源代码仓库中的 SECURITY.md。
破坏性命令未被阻止，属于公开 bug。CC Safety Net 自身造成有害行为，属于需要私密报告的漏洞。不确定时，请阅读选择公开或私密报告。如需先诊断问题，请从故障排除开始。
私密报告漏洞
**不要在公开 GitHub issue 中报告安全漏洞。**如果仓库提供了 GitHub 私密漏洞报告功能，请使用该功能。如果无法使用，请发送邮件至维护者邮箱 jliew@420024lab.com。 在可以安全分享时，请提供以下信息：- 受影响的
cc-safety-net版本 - 操作系统和运行时版本
- 受影响的集成，例如 Claude Code、OpenCode、Gemini CLI、GitHub Copilot CLI、Grok Build 或 Codex
- 复现步骤，以及绕过、削弱或滥用 CC Safety Net 的命令或输入
cc-safety-net explain或cc-safety-net doctor的相关输出- 问题是否会造成数据丢失、命令执行、机密暴露或其他具体安全影响
选择公开或私密报告
CC Safety Net 应在所选安全级别的保证范围内，阻止智能体运行破坏性命令。未能阻止就是 bug，应提交到公开 GitHub issue。strict 和 paranoid 的威胁模型假定攻击者，包括提示注入或对抗性上下文，可以发出任何破坏性命令。因此，公开某种未被捕获的命令形式，不会给攻击者增加能力。公开报告也方便修正缺口，用户可以先用自定义规则处理。 如果工具自身执行了有害操作，例如泄漏机密、在自身目录外写入文件或发布被篡改的软件包，则属于漏洞。这类不明显的构造方式也属于机密，应私密披露。 判断标准是：工具只是没有阻止破坏性命令，还是工具自身造成了危害？哪些问题属于安全问题
请私密报告以下问题：- 通过阻止消息、审计日志、诊断、调试输出或误报报告预填内容泄漏机密，包括针对特定令牌格式的脱敏绕过，或报告预览声称已替换但实际未替换的路径
- 审计日志或配置处理中的路径遍历或文件系统问题，即构造的输入会写入预期目录之外
- 影响已发布 npm 软件包或插件分发的供应链或打包问题，包括 rulebook 完整性
哪些问题应提交公开 issue
以下问题请使用普通 GitHub issues：- 任何让破坏性命令执行的绕过或 fail open，包括覆盖缺口（规则尚未阻止的命令）、解析器、分词器或包装器分析边缘情况，或者导致命令通过而非被阻止的分析错误。请报告命令形式，不要提供可直接粘贴使用的武器化提示注入载荷。
- 安全命令被阻止的误报
- 缺少便利规则或新功能请求
- 文档错误
- 没有安全影响的安装问题
- 关于自定义规则或配置的问题
failClosed 开关。只有 stdout 上明确的 deny 才能阻止工具调用；hook 崩溃、超时或输出格式错误时，调用照常执行。适配器仍会为自身的 fail-closed 情况输出明确的 deny，例如工具输入被截断或工作目录不可用。在这个宿主上，如果失败导致适配器完全没有输出，这次调用就不会被阻止。这是宿主行为，不是覆盖缺口。
即使破坏性命令覆盖缺口看起来很严重，它仍应公开报告。它不会被重新分类为漏洞，私密渠道仅用于上述类别。在 standard 模式的文档放宽范围内允许的命令不属于缺口。standard 只提供尽力保护；strict 或 paranoid 才会对这些形式 fail closed。