# 开发效率的安全防线：四件套逐行拆解——代码审查赛道之外，SKILL.md 里还有一层没人细讲的安全工程 ## 概述 前几轮拆解把代码审查、测试、重构、调试这几条主线都走完了：code-review/simplify/verify/run 四件套拆过，webapp-testing 拆过，二进制调试赛道也拆过。但翻开本地 `~/.claude/skills/` 目录，还有一组长期站在聚光灯外的样本：`security-best-practices`、`security-threat-model`、`security-ownership-map`，加上一个把「失败前置」写成艺术的 `security-review`。这一轮把样本范围收窄到「安全工程」这一小块，全部基于磁盘上的 SKILL.md 原文逐行阅读。核心发现有三：一是这组 Skill 覆盖了写代码时、设计时、提交门禁、仓库诊断四个互补层次，拼起来就是一条完整防线；二是其中一个样本的正文里出现了「projects being reviewed by codex」字样，留下了跨 Harness 搬运的文本痕迹；三是从中能提炼出四个可直接抄走的设计模式——预检门禁、算式开头、references 渐进加载、有界输出。 ## 评测对比表 评分基于 SKILL.md 文本质量与设计推断（未做长周期实测），「社区活跃度」一列对出厂件不适用，按分发方式标注。 | Skill | 功能完整度 (25%) | 设计质量 (25%) | 实战效果 (20%) | 上手难度 (15%) | 分发方式 (15%) | |---|---|---|---|---|---| | security-best-practices | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | 已装即用 | | security-threat-model | ★★★★ | ★★★★★ | ★★★★ | ★★★☆ | 已装即用 | | security-ownership-map | ★★★★ | ★★★★ | ★★★☆ | ★★★☆ | 需 pip 依赖 | | security-review | ★★★☆ | ★★★★☆ | ★★★★ | ★★★★★ | 已装即用 | | gh-fix-ci | ★★★☆ | ★★★★ | ★★★★ | ★★★☆ | 本地单件 | --- ## 主拆一：security-best-practices —— 「被动免疫」派，安全规范写成肌肉记忆 **定位**：不是让你跑一次安全扫描，而是在你写代码的全程当隐形安全顾问。它定义了三种工作模式，层次非常清楚：主模式是「从这里开始写 secure by default 的代码」，适合新项目起步；二模式是「被动检测」，干活路上顺手标记高危漏洞；三模式是用户点名要一份完整的安全报告，按严重程度分节、每条发现编号、关键发现配一句话影响声明。 **设计拆解**：它的第一步设计得很克制——先识别「ALL languages and ALL frameworks」，前后端都要识别，然后才去 `references/` 目录按 `---security.md` 的命名规则加载对应文档，找不到就退化到模型自身的通用知识。这是典型的渐进式披露：正文只放流程，规范细节全部外置到参考文件，按需加载。更难得的是它对「现实工程」的妥协写进了正文：Override 一节明确说「你可以向用户报告，但不要和他们对抗（do not fight with them）」，建议把绕过原因写进项目文档而不是反复阻拦。Fixes 一节甚至点破了安全债的社会学：「不安全的代码往往因为别的原因被依赖着，这正是它活了这么久的原因」——所以修复要一次一条、要考虑回归、要写清楚注释。通用建议里也有反直觉的干货：公开资源 ID 别用自增整数改用 UUID4；对 HSTS 直接建议别乱推荐，「用错会导致大面积宕机和用户被锁在门外」；非 TLS 环境设 secure cookie 会直接弄坏开发环境。 **彩蛋**：TLS 一节的原文写道「not generally recommended for the scope of projects being reviewed by **codex**」——一个 Claude 环境里的 Skill 正文里留着 codex 的名字，大概率是从别的 Harness 生态整段搬来改的。这也侧面证明安全规范类 Skill 的文本正在跨厂流通。 **短板**：三模式全靠模型自觉切换，没有像 code-review 那样的硬性输出契约；references 目录的覆盖面决定上限，冷门框架等于裸奔。 **上手**：零依赖。装好后在对话里说「给这个项目做一次安全评估报告」即可触发报告模式，平时写代码它按被动模式挂着。 ## 主拆二：security-threat-model —— 「设计时评估」派，把威胁建模做成了八步工作流 **定位**：产出一份「AppSec 级」威胁模型文档，开头第一句就把野心写在脸上——「deliver an actionable threat model that is specific to the repository, **not a generic checklist**」。它要的不是 OWASP 十条念一遍，而是锚定你这个仓库的信任边界、资产和入口点。 **设计拆解**：八步流程里藏着三个非常成熟的提示词工程手法。第一步是「证据锚定」：「Do not claim components, flows, or controls without evidence」——模型不许凭空声称系统有什么组件，必须仓库里有实证。第五步是显式的定性风险公式：可能性 × 影响，各自给低/中/高加一句理由，还要求声明「哪些假设对排序影响最大」。第六步是全文最值钱的设计：**强制暂停**。「Pause and wait for user feedback before producing the final report」——在产出终稿前，模型必须把影响排序的关键假设列出来，问用户 1~3 个针对性问题（谁负责这个服务、部署模型是什么、有没有多租户），用户不回答也要明说「哪些假设仍未解决、它们如何影响结论」。这一步把威胁模型从「模型的自嗨文档」变成了「双向确认的交付物」。第八步还有一个出厂自检清单：入口点全覆盖了吗？每条信任边界都对应到威胁了吗？运行时和 CI/开发态分开了吗？输出格式对齐模板了吗？最后强制落盘为 `<仓库名>-threat-model.md`。 **短板**：八步走完交互成本不低，小项目用它有杀鸡用牛刀之感；references 的输出契约（prompt-template.md）是硬约束，改起来要动模板。 **上手**：已装即用，触发语建议直接用「对这个仓库做一次 threat model」，中途它会停下来问你问题——这不是卡住，是设计。 ## 主拆三：security-ownership-map —— 「数据取证」派，用 git 历史算出谁在孤守密码学代码 **定位**：四件里唯一的数据科学件。从 git 历史构建「人 × 文件」二部图，计算所有权风险（bus factor），再叠加一张文件共变图（共变 Jaccard 相似度），最后导出给 Neo4j/Gephi 做可视化。它回答的问题是传统扫描器永远不问的：「这段认证代码，是不是只有一个快离职的人看懂？」 **设计拆解**：它的工程素养全在默认值里。共变图默认忽略 lockfile、`.github/*`、编辑器配置这类「胶水文件」，否则集群全被共享基建的改动污染；默认排除 Dependabot 和 merge commit；甚至从作者提交的时区偏移里推断每个贡献者的主时区——这是给「外部承包商深夜改敏感代码」这类信号留的口子。敏感路径判定用一张 CSV 规则表（`**/auth/**,auth,1.0` 这样的三列格式），默认规则盖住 auth/crypto/secret 常见路径，可用 `--sensitive-config` 覆盖。最能体现「为 LLM 消费而设计」的是 `query_ownership.py`：它把结果切成「small, JSON-bounded slices」，明确说为了「without loading the full graph into context」——查某文件的共变邻居、查 bus factor ≤ 1 的加密文件、查 `orphaned_sensitive_code`（过期且低 bus factor 的敏感代码），每条都是小 JSON。这在 SKILL.md 设计上是个范式：**脚本不只是自动化工具，更是上下文预算管理器**。 **短板**：需要 Python3 + networkx；git log 特别大的仓库要自己记得加 `--since`；输出是 CSV/JSON 原料，结论要靠上层对话自己下。 **上手**： ```bash pip install networkx python ~/.claude/skills/security-ownership-map/scripts/run_ownership_map.py \ --repo . --out ownership-map-out --since "12 months ago" --emit-commits python ~/.claude/skills/security-ownership-map/scripts/query_ownership.py \ --data-dir ownership-map-out summary --section orphaned_sensitive_code ``` ## 主拆四：security-review —— 一个因为「拒绝运行」而暴露设计的三号样本 这个 Skill 我没能看到正文：调用它时直接报错 `Shell command failed for pattern "!`git status`" — fatal: not a git repository`。但这次失败本身比多数成功样本更有教学价值——它的 SKILL.md 第一条指令是一个 `!` 前缀的 shell 预检，不在 git 仓库里就当场终止，不进入任何后续流程。对比之下，很多 Skill 的失败模式是：模型硬着头皮在没有 diff 的环境里「脑补一次代码审查」，产出看起来专业、实际是幻觉的发现清单。**预检门禁模式的本质，是把「这个 Skill 根本不该运行」的判断从模型判断降级为确定性判断**——一行 shell 搞定，零 token，零幻觉空间。同目录下 code-review 的 Phase 0 也是同思路的软版本：先跑 `git diff @{upstream}...HEAD`，拿不到就逐级降级到 `main...HEAD`、`HEAD~1`、工作区 `git diff HEAD`，并在正文里解释「the review often runs before the commit」——降级链本身就在教模型理解真实工作流。 **顺手看它的邻居**：同为出厂件的 code-review 值得引用一句话作参照——它把 token 预算直接写成开篇算式 `` `high effort → 3+4 angles × 6 candidates → 1-vote verify (recall-biased) → ≤10 findings` ``，并用「PLAUSIBLE by default / REFUTED only when constructible from the code」锁死验证倾向。安全审查和正确性审查共享同一套多 Agent 骨架，差别只在finder 的攻击视角。 ## 收尾彩排：gh-fix-ci / gh-address-comments，审查回路的两条尾巴 安全与质量发现之后，最后一步是修和回评。`gh-fix-ci` 把 GitHub CLI 的字段漂移都预案好了——自带的 `inspect_pr_checks.py` 注释里明说「handles gh field drift and job-log fallbacks」，`gh pr checks --json` 某个字段被拒就用 gh 实际支持的字段重跑；脚本「Exits non-zero when failures remain so it can be used in automation」，可以直接挂 CI。流程第六步明确要求先出修复计划、获批后再动手。`gh-address-comments` 更短：跑脚本拉取全部评论、给每条编号并给出修复成本摘要、让用户选号——又是一个「人在回路选单」设计。 --- ## 生态分类一图 ```mermaid flowchart LR subgraph WRITE["写码时（被动免疫）"] A["security-best-practices
三模式:默认安全写法/被动检测/完整报告"] end subgraph DESIGN["设计时（评估）"] B["security-threat-model
八步流程·第六步强制暂停问人"] end subgraph GATE["提交门禁（确定性）"] C["security-review
!git status 预检·非git当场终止"] end subgraph AUDIT["仓库诊断（数据取证）"] D["security-ownership-map
git历史→bus factor·共变图·时区推断"] end subgraph TAIL["修复回路（运维尾巴）"] E["gh-fix-ci
字段漂移预案·非零退出码"] F["gh-address-comments
评论编号·人选单"] end A --> C B --> C C --> D C --> E --> F ``` ## 可抄走的四个 SKILL.md 设计模式 1. **预检门禁**：把运行前置条件写成 SKILL.md 第一行的确定性命令（`!`git status``），不满足就地终止。适用一切依赖特定环境态的 Skill（git 仓库、docker、某个 MCP 在线）。 2. **算式开头**：像 code-review 那样，把「投入多少 Agent、每个产几个候选、几票验证、输出上限」写成一行公式放在正文首行。模型对显式预算的遵守率远高于散落在段落的形容词。 3. **references 渐进加载 + 命名路由**：security-best-practices 用 `<语言>-<框架>-<栈>-security.md` 的文件名约定让模型自己路由到唯一需要的那份文档；threat-model 把输出契约整个放进 `references/prompt-template.md` 并要求「use it verbatim」。正文保流程，细节外置。 4. **有界输出脚本**：ownership-map 的 `query_ownership.py` 把大图切成小 JSON 片；code-review 把发现硬性限到 10 条并规定 JSON 字段。共同点是替上下文窗口做预算，输出形状即接口。 ## 推荐排行 - **最值得整段抄写法**：security-threat-model（证据锚定 + 强制暂停 + 出厂自检三连） - **最适合新手第一只安全 Skill**：security-best-practices（零依赖、三模式清晰） - **数据深度天花板**：security-ownership-map（bus factor + 共变图是扫描器照不亮的盲区） - **失败设计教科书**：security-review（一行预检胜过千字免责声明） - **自动化友好度**：gh-fix-ci（非零退出码直通 CI） ## 参考来源与样本 本文全部结论基于本机磁盘上的 SKILL.md 原文逐行阅读（样本即来源）： 1. `~/.claude/skills/security-best-practices/SKILL.md` — 三模式工作流、Override 政策、codex 字样出处 2. `~/.claude/skills/security-threat-model/SKILL.md` — 八步流程、第六步强制暂停、输出契约 3. `~/.claude/skills/security-ownership-map/SKILL.md` — 二部图/共变图设计、query 脚本有界输出 4. `~/.claude/skills/code-review/SKILL.md` 与 `~/.claude/skills/simplify/SKILL.md` — 算式开头、验证倾向、参照组 5. `~/.claude/skills/gh-fix-ci/SKILL.md`、`~/.claude/skills/gh-address-comments/SKILL.md` — 修复回路两件 6. security-review 的预检失败记录（本会话实测输出）— `!`git status`` 门禁设计的直接证据 延伸阅读（本期未抓取，供自行验证）：anthropics/skills 官方仓库、skillsmp.com 与 skills.sh 的安全类榜单——本文为纯本地样本拆解，跨站热度数据留待后续周报核补。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。