analyzing-security

安全校验关卡

自动化扫描捕捉模式，但严重度判定与处置取决于上下文——sink、信任边界、补偿控制。

何时使用

场景	必跑	理由
新模块落地	✅	引入新攻击面
安全相关变更	✅	直接触及威胁面
重构完成	✅	防止重构引入退化
提交前（含敏感数据/外部输入处理）	✅	最后一道闸
攻防任务交付	✅	验收前自检
仅文档/样式改动	❌	无攻击面变化

何时不使用

• 依赖更新（用 SCA 工具如 npm audit、pip-audit，不是模式扫描）
• 运行时漏洞（用 DAST，不是静态扫描）
• 配置审计（用 CIS Benchmark 或专用工具）

解读输出

严重度（critical / high / medium / low）+ 类别（注入 / 敏感信息 / XSS / 反序列化 / 路径遍历 / SSRF / 弱加密 / 不安全随机 / 调试残留）。

必修

• Critical（SQL 注入、命令注入、硬编码密钥、AWS Key、私钥）→ 阻断交付，无例外。
• High（XSS、反序列化、路径遍历、SSRF）→ 修复或显式接受风险（需 DESIGN.md 留痕 + 补偿控制）。

上下文降级条件

• Medium/Low 可在 DESIGN.md 标注「已知/已评估」后保留。判据：
  • 弱加密 MD5/SHA1 用于非安全场景（如 hash bucket）→ 可接受
  • random 用于非安全场景（如 jitter）→ 可接受
  • 调试残留在 dev-only 构建 → 可接受，prod 构建必须剔除

假阳处理

每条规则均有 excludePattern，若仍误报：

1. 检查命中文本是否真为 sink（看上下文，不只是模式）
2. 若确认假阳，在 DESIGN.md 记录 + 行内注释（// nosec: <规则 ID> <理由>）

与其他 skill 联动

• 命中 critical/high → 同步触发 securing-systems 路由的对应秘典（如 SQL 注入查 pentest.md）
• 新模块场景 → 与 verifying-modules 串行，先扫安全再校验文档
• 变更场景 → 与 analyzing-changes 串行，先看变更范围再决定扫描深度

使用

node scripts/security_scanner.js <路径>            # 默认全扫
node scripts/security_scanner.js <路径> -v         # 详细，含命中代码片段
node scripts/security_scanner.js <路径> --json     # 机读格式，供 CI
node scripts/security_scanner.js <路径> --exclude vendor,dist

完整规则矩阵、危险模式速查、误报豁免清单详见 references/rules.md。

收口

Critical/High 必修后方可交付。安全决策须于 DESIGN.md 记录：威胁模型、信任边界、已知风险、补偿控制。