[Security] Secret 防泄漏：依赖漏洞、敏感内容和输出脱敏拦截

[v833]

标签建议：area/security, area/reliability, priority/P0, type/feature, depends-on/security

背景

当前能力：

• q-code 项目明确要求不暴露 .env、API key、token 等敏感配置。
• 已有审计日志、shell 输出 spill、工具调用记录、session 持久化和 TUI 输出等多个可能承载敏感内容的路径。
• 依赖漏洞、敏感文件读取、模型输出复述和 Git 提交都是潜在泄漏点。

痛点：

• 敏感信息可能来自工具输入、工具输出、shell 日志、模型回复、审计事件或 PR/commit 内容。
• 仅靠人工提醒不足以防止 token 被打印、记录或提交。
• 企业环境需要更强的 secret scanning、依赖漏洞提示和输出脱敏策略。

需要补齐：

• 统一 secret detector 和 redaction 管线。
• 对文件、工具、shell、审计、session、Git 工作流的多点拦截。
• 依赖漏洞扫描和安全报告。

目标

实现安全扫描与 Secret 防泄漏能力：在读取、输出、审计、持久化和提交前检测敏感内容并脱敏或阻断，同时提供依赖漏洞检查和可审计的安全报告。

用户故事

• 作为用户，我希望 q-code 不会在回复里复述我的 API key，以便敏感配置不被意外泄露。
• 作为维护者，我希望提交前能检查 staged diff 中是否含 secret，以便避免把凭据推到 GitHub。
• 作为企业安全负责人，我希望工具输出和审计日志默认脱敏，以便满足最小暴露原则。
• 作为开发者，我希望依赖漏洞能被提示并关联修复建议，以便及时处理供应链风险。

详细需求

1. Secret detector

• 支持常见 token/key 模式、.env 键名、GitHub/OpenAI/Cloudflare/SSH/WebDAV 等敏感模式。
• 支持路径敏感：.env、private key、credentials 文件默认高风险。
• detector 输出类型、位置、置信度和 redacted 版本。

2. Redaction 管线

• 工具输出、shell 输出、审计日志、session 持久化、错误提示和最终回复都应有脱敏边界。
• 对用户明确要求展示敏感信息的场景，仍需二次确认或遵循安全策略。
• Redaction 不应破坏 JSON 结构或测试日志基本可读性。

3. 提交前扫描

• 与 Git 工作流助手集成，扫描 staged diff、commit message 和 PR body。
• 检测到高置信 secret 时默认阻断提交/推送，除非用户明确覆盖且被审计。
• .env、.q-code/、sessions、crashes、shell-spills 等本地目录默认提示不可提交。

4. 依赖漏洞扫描

• 支持运行 pnpm audit 或等价本地依赖扫描，并解析结果摘要。
• 外部网络不可用时给出降级说明，不让普通启动失败。
• 与 [Verification] 自动验证策略：测试选择、失败归因、flaky 检测和风险评分 #26 验证报告结合展示风险等级。

5. 配置与例外

• 支持配置允许列表，例如测试 fixture 中的假 token。
• 允许列表必须尽量按路径/模式收窄，并在审计中记录。
• 默认策略安全优先，但避免对明显假值过度报警。

输出样例

安全扫描: failed

高风险:
- .env: GITHUB_PERSONAL_ACCESS_TOKEN 看起来像真实 token，已脱敏

建议:
- 不要提交 .env
- 改用用户级配置或 secret manager

验收标准

• 常见 API key/token/private key 能被 detector 识别并脱敏。
• 工具输出、shell 输出、审计日志和最终回复经过 redaction 边界。
• Staged diff 中发现高置信 secret 时阻断提交或要求明确覆盖。
• Redaction 后 JSON/日志仍尽量保持可读结构。
• 支持测试 fixture 假 token 的路径级 allowlist。
• 依赖漏洞扫描可运行并生成摘要，网络失败可降级。
• README/AGENTS 增加安全扫描、脱敏和 allowlist 说明。
• 单元测试覆盖 detector、redaction、allowlist 和提交前扫描。

测试方案

• tests/unit/secret-scanner.test.ts：覆盖常见 token、private key、假 token、allowlist。
• tests/unit/redaction.test.ts：覆盖文本、JSON、shell 输出和审计事件脱敏。
• tests/integration/security-flow.test.ts：在临时 git repo 中覆盖 staged diff 阻断。
• 手动验证：.env、shell 输出 token、pnpm audit、PR body secret。

不在本期范围

• 替代专业 SAST/DAST 平台。
• 云端 secret manager 集成。
• 自动轮换已泄露密钥。
• 对所有语言的深度依赖漏洞修复。

依赖 / 风险

• 安全能力应与 [Security] Approval Policy：工具、文件、网络和工作区边界审批系统 #22 approval policy、[Git] 工作流助手：分支、提交、PR、review comment 和冲突辅助 #27 Git 工作流和审计日志协同。
• false positive 过多会影响体验，需要 allowlist 和置信度设计。
• false negative 风险不可完全消除，文档不能承诺绝对防泄漏。
• 处理敏感内容时测试和日志必须使用假数据。

工作量评估

• Secret detector 与 redaction core：2 人日
• 输出/审计/session/Git 集成：3 人日
• 依赖漏洞扫描与报告：1 人日
• 测试与文档：2 人日
• 合计：~8 人日