telagod 安全校验关卡
判断先于执行：决定「是否做 / 选什么 / 如何取舍」（栈、方案、架构、权衡）前，先读领域判断内核
skills/_kernel/security/SKILL.md——它管 judgment，本秘典管 execution；冲突时以内核判断为准。
自动化扫描捕捉模式，但严重度判定与处置取决于上下文——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，若仍误报：
- 检查命中文本是否真为 sink（看上下文，不只是模式）
- 若确认假阳，在 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 记录：威胁模型、信任边界、已知风险、补偿控制。