安全与治理类 Skills 榜单

先给清单：十二条，按「能不能阻断」排

怎么装（命令抄自各自官方页面 / 仓库 README）

# ①② 不用装，改配置就有。沙箱先看面板缺什么
/sandbox
# 要把沙箱当安全门禁而不是省事工具，这两个键必须显式写
{ "sandbox": { "enabled": true, "failIfUnavailable": true,
                "allowUnsandboxedCommands": false,
                "network": { "strictAllowlist": true, "allowedDomains": ["*.github.com"] } } }

# ③④⑤⑪ 确定性扫描器，装法都是一行
brew install gitleaks trufflehog zizmor
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest
gitleaks git --report-path gitleaks-report.json   # 有发现 → 退出码 1
trufflehog git file://. --results=verified --fail # 有发现 → 退出码 183
osv-scanner scan source -r .
zizmor .github/workflows/                          # 支持 SARIF 输出接 CI

# ⑥⑦ 官方插件；⑧ 内置命令，什么都不用装
/plugin marketplace add anthropics/claude-plugins-official
/plugin install security-guidance@claude-plugins-official
/plugin install claude-security@claude-plugins-official   # 需要 python3 ≥ 3.9
/claude-security         # 菜单三件事：扫全库 / 扫改动 / 出补丁
/security-review         # 当前分支跑一遍，不用装任何东西

# ⑩ semgrep 的 MCP 现在是主仓的子命令（旧仓 semgrep/mcp 已归档）
claude mcp add semgrep -- semgrep mcp

# ⑫ 扫你自己装的那些 MCP server 与 skill；默认逐个问你才连
uvx snyk-agent-scan@latest scan

逐条说人话

• ① Bash 沙箱（官方机制）：本榜唯一由操作系统兜底的一条——macOS 走 Seatbelt，Linux/WSL2 靠两个包，原生 Windows 不支持。两层独立：filesystem 管路径、network 管域名。最值得抄的设计：denyRead 在更宽的 allowRead 里依然成立（官方原话是「一条宽的 allow 不能悄悄把一个 secret 重新暴露出来」）。什么时候别用：你其实想要的是每条命令都问你——那用 permission 模式，别用沙箱。
• ② permissions.deny（官方机制）：能收紧、不能放宽——deny 规则在 auto 模式下依然生效。但它有一条必须知道的天花板：Bash 的 deny 是按命令原文匹配的，官方自己写明「要不依赖命令文本的网络管控，请用沙箱的网络隔离」。什么时候别用：你想要的是「问我一下」而不是「禁掉」——那写成 ask。
• ③ gitleaks（MIT，据其 GitHub 页 2026-09 约 29.6k star）：正则规则库扫 git 历史与文件。本榜最省事的 fail-closed 样本：有发现就退出码 1（--exit-code 可改），pre-commit 一行 - id: gitleaks 就拦在提交前。老仓库满屏告警的解法是 baseline：先出报告，再 --baseline-path 只看新增，个别误报进 .gitleaksignore。别装：托管方的推送保护已经够用。
• ④ trufflehog（AGPL-3.0，据其 GitHub 页 2026-09 约 28.2k star、800+ 检测器）：和 ③ 的关键差别是验证——拿捡到的凭据真去调一次服务方 API（AWS 走 GetCallerIdentity）确认还活着。--results=verified 把噪音砍到「真能用的那些」，--fail 让有发现时退出码变 183。代价：验证要往外发请求，且 AGPL-3.0 不是所有公司能接。
• ⑤ osv-scanner（Apache-2.0，据其 GitHub 页 2026-09 约 11.1k star）：读 package.json / go.mod / pom.xml 这些清单跟 OSV.dev 的漏洞库对账，scan source -r . 递归扫。实验性的 osv-scanner fix 能按漏洞深度与严重度自动提升级方案，但官方标了红线：它在不可信项目上有风险，可能执行包管理器脚本。
• ⑥ security-guidance（官方插件）：纯 hooks 写的三层自动复审，管「模型刚写出来的那段代码」。关键设计是不让写代码的实例自己打分，另起一个只被告知「找问题」的 Claude。本榜最重要的一句诚实交代：它三层都不阻断写入或提交，只把发现塞回去让模型改。装了它不等于装了门禁。
• ⑦ claude-security（官方插件，需 python3 ≥ 3.9）：一队 agent 先摸架构、建威胁模型、分头找漏洞，每条发现都由独立 verifier agent 复核过才进报告。产出三份同源文件：CLAUDE-SECURITY-RESULTS.md / .jsonl / .sarif（SARIF 2.1.0，按 CWE 归类，能直接喂 GitHub code scanning），外加一份版本戳记下扫的是哪个 commit。三条必须知道的限制：扫描结果不确定（同一份代码两次扫可能给出不同发现）、补丁永不自动应用（写到 patches/F1.patch 等你 git apply）、一次扫描消耗的 token 可能很多且要开着会话跑完。
• ⑧ /security-review（官方内置命令）：本榜成本最低——什么都不用装，在项目目录里敲一下，对当前分支跑一遍安全 pass。官方把分工写得很清楚：⑥ 在模型写代码时管，⑧ 是单次过一遍分支，⑦ 是按需深扫。不够用时：你要每次提交都自动跑——那是 ⑥ 或 CI 的活。
• ⑨ claude-code-security-review（MIT，据其 GitHub 页 2026-09 约 6.3k star / 700 fork）：一个 GitHub Action，在 PR 上自动跑并评论，覆盖注入 / 越权与 IDOR / 密钥泄漏 / 弱加密 / 反序列化 RCE 等，内置一层误报过滤（主动排除 DoS、限流、开放重定向这些高误报项）。它自己的警告必须读：没有针对 prompt injection 做加固，只应审可信的 PR，并建议对外部贡献者开启「需要审批」。最小工作流只要 contents: read ＋ pull-requests: write。
• ⑩ semgrep mcp（LGPL-2.1，据其 GitHub 页 2026-09 约 16.8k star）：把 5,000+ 条规则的 SAST 做成 MCP 工具（security_check / semgrep_scan / semgrep_scan_with_custom_rule 等），让 agent 自己去扫。名字上有坑：独立仓 semgrep/mcp 据其页面已于 2025-10-28 归档，现在是主仓的 semgrep mcp 子命令。别接：不需要模型调它，就在 CI 跑 semgrep ci，省下常驻 context。
• ⑪ zizmor（MIT，据其 GitHub 页 2026-09 约 6.6k star）：专审 CI 配置——模板注入（${{ }} 插值变成攻击者可控的代码执行）、凭据残留、runner 权限过宽、冒名 commit。「越权检查」里最容易漏掉的一格：多数人审代码权限，没人审那个能写仓库的 workflow token。支持 SARIF 接 CI。
• ⑫ snyk/agent-scan（Apache-2.0，据其 GitHub 页 2026-09 约 3.1k star）：本榜唯一把「你装的 AI 组件本身」当审计对象的一条——扫 mcp.json、.claude/skills、.agents/skills，找 prompt injection、tool poisoning、可疑下载、硬编码密钥。它自己那条警告最说明这一类的处境：扫 MCP 配置本身就可能执行命令或发出网络请求，所以默认交互式扫描每连一个 server 都问你一次，非交互环境要显式给 --dangerously-run-mcp-servers。需要 SNYK_TOKEN。

为什么这十二条不能混着比：两个轴，四个格

右上角空着不是产品没做完，是设计取舍：模型审查有误报，一条误报硬挡提交，团队第二天就会把整个检查关掉——连报告都没了。所以正确读法是：左列负责「绝不许发生」，右列负责「你最好看一眼」，谁也别替谁。

三种常见的错配：

• 把右列当门禁。 装了 ⑥ 就以为漏洞进不去了——它三层都不阻断。要门禁得在 CI 加 ③ 或 ④，靠退出码说话。
• 把左列当审计。 ③ 只认正则、⑤ 只认清单里的依赖版本。业务逻辑上的越权（谁能读谁的订单）它们看不见，那是 ⑦ ⑨ 的活。
• 只审代码，不审配置和装进来的东西。 ⑪⑫ 这两格最常空着：能写仓库的 workflow token、昨天顺手装的第三方 skill，都是绕过前面所有检查的近路。

三分钟验货：装之前答这六问

1. 它有发现的时候，退出码是几？ 答不出来的就不是门禁。③ 是 1、④ 加 --fail 是 183，能直接进 CI。⑥⑦⑧⑨ 答案都是「不阻断」——记下来，别自我安慰。
2. 它自己跑不起来的时候会怎样？ 这一问最见功底。沙箱默认行为是依赖缺失或平台不支持就打个警告、不沙箱地跑下去——即 fail-open。要它硬失败必须显式写 sandbox.failIfUnavailable: true（官方注明这是给「把沙箱当安全门禁」的部署用的）。
3. 有没有绕过它的合法通道？ 有，官方写明了：沙箱违规时 Claude 可能带 dangerouslyDisableSandbox 重试，allowUnsandboxedCommands: false 关掉这条通道。⑫ 对应的键叫 --dangerously-run-mcp-servers。凡是名字里带 dangerously 的，先弄清它默认是开还是关。
4. 这条配置放在哪一层才算数？ 容易踩的一坑：sandbox.network.strictAllowlist（把「问一下」变成「直接拒」）只有写在用户设置、托管设置或 --settings 里才生效，写进仓库的 .claude/settings.json 完全没用。安全配置放错层等于没放。
5. 它的误报谁来治？ 有机制的才敢开门禁：③ 的 baseline ＋ .gitleaksignore、④ 的 --results=verified、⑨ 那份排除清单。没有治理机制的高误报工具，装上就是等着被关掉。
6. 它自己是不是攻击面？ 这一问专门对付本类工具：⑨ 自己写了「未针对 prompt injection 加固，只审可信 PR」；⑫ 自己写了「扫配置可能执行命令」；⑤ 的 fix 可能执行包管理器脚本。安全工具读的就是不可信输入，这三条警告是它们诚实，不是它们差。

诚实的代价：安全类是最容易「装了等于没装」的一类

三笔账

• 告警疲劳会自己杀死检查。 老仓库上直接开 ③，头一次可能几百条历史命中；没人看，两周后就被从 CI 里注释掉。正确顺序是先出 baseline 再开门禁，④ 的 --results=verified 同理。
• 虚假安心是最贵的一笔。 ⑥⑦⑧⑨ 都产出很像结论的东西，而都不阻断；⑦ 官方还写明扫描不确定，同一份代码两次扫可能不一样。把这类报告当「通过」记进流程，不如什么都不装——那时你至少知道自己没防。
• 安全工具本身在扩大攻击面。 ④ 验证凭据要往外发请求；⑫ 扫配置可能执行命令；⑨ 明说不抗注入。加上沙箱那条默认值：沙箱的默认读权限覆盖整台机器（除若干默认拒绝目录），连 ~/.aws/credentials 和 ~/.ssh/ 都还能读——要挡住得显式配 sandbox.credentials 或把路径加进 denyRead。

不装任何东西，你还能怎么办

1. 先敲 /security-review。 零安装零配置，先知道这个分支大概什么水位。
2. 再开托管方自带的推送保护。 比装任何扫描器都省事，而且它真阻断。
3. 然后才是 ③ 进 pre-commit。 一行 - id: gitleaks，性价比最高的一条 fail-closed。