它做的事情不花哨，就是在你让 Claude 写代码、改文件、准备收工或者提交代码时，把命令注入、XSS、反序列化这类常见安全坑提前拎出来。我的判断是：这不是“AI 自动安全审计”的终点，但它把安全提醒从 PR Review 往前挪了一大步。
这次发布小，但方向不小
北京时间 5 月 27 日，ClaudeDevs 官方账号发布了 Security Guidance 插件：一个面向 Claude Code 的安全指导插件，可以在写代码的过程中帮助识别和修复漏洞。
它已经面向所有 Claude Code 用户开放，安装入口在插件市场。官方插件页面给出的安装命令是：
💡 PROMPT
安装命令：
/plugin install security-guidance@claude-plugins-official
也可以在 Claude Code 里输入 `/plugin`，进入 Discover 里搜索 Security Guidance。
这个发布真正有意思的地方，不是“Claude 又多了一个插件”。
更准确地说，它说明 Anthropic 正在把 Claude Code 从一个会写代码的 CLI，慢慢变成一个带工程流程和防护机制的开发环境。以前安全检查通常发生在写完之后：lint、CI、PR Review、人工审计。现在它开始前移到“AI 正在改文件”的那一刻。
这件事对 AI 编程很关键。
因为 AI 写代码的速度越快，风险也越容易被批量放大。一个人手写错一处 innerHTML，可能只是一个小 PR；Agent 一次批量改十几个文件，错误就会沿着项目结构扩散。Security Guidance 解决的不是“所有安全问题”，而是先把那些最常见、最容易被模型顺手写出来的危险模式拦一下。
它不是普通 linter
如果只看表面，它有点像安全版 linter：看到危险写法就提醒。
但源码里能看到，它的机制更贴近 Claude Code 的运行过程。插件通过 Hook 接入几个关键时刻：用户提交需求时、Claude 改完文件后、会话停止时，以及 git commit / git push 这类动作发生后。
这几个时刻的分工不一样：
| 时机 | 它在做什么 | 价值 |
|---|---|---|
| UserPromptSubmit | 记录本轮开始前的 git 基线 | 后面只看本轮新增改动 |
| PostToolUse | 每次 Edit / Write 后跑规则检查 | 及时提醒明显危险写法 |
| Stop | 对本轮 git diff 做安全复查 | 收工前再过一遍 |
| git commit / push | 对提交或推送做后台安全 review | 防止问题跟着提交走 |
这里有个细节值得注意：Stop 阶段不是扫整个仓库，而是拿本轮开始时的 baseline 和当前状态做 diff。也就是说，它更关心“Claude 这轮刚改出来什么”，而不是把旧代码里的历史问题重新翻出来吓你。
这很重要。
如果一个安全工具每次都把项目旧账全翻出来，开发者很快就会麻木。真正有用的提醒，应该尽量贴近这次改动本身。Security Guidance 的设计方向就是：少一点泛泛而谈，多盯住本轮新增风险。
它到底盯哪些风险
官方插件页写得很直接：它会提醒 command injection、XSS 和不安全代码模式。源码里的规则更具体，覆盖了不少 AI 写代码时常见的危险捷径。
比如这些：
| 风险 | 典型写法 | 它会提醒什么 |
|---|---|---|
| 命令注入 | child_process.exec()、os.system()、shell=True | 避免把用户输入拼进 shell |
| XSS | innerHTML、dangerouslySetInnerHTML、document.write() | 用安全 DOM API 或消毒库 |
| 反序列化 | pickle.load()、yaml.load()、torch.load() | 不要加载不可信对象 |
| CI/CD 注入 | 修改 GitHub Actions workflow | 注意触发器、权限和 secret 暴露 |
| 加密误用 | ECB、无 IV 的 cipher、关闭 TLS 校验 | 避免看似能跑但不安全的实现 |
| 远程脚本风险 | 外链 script 缺少 SRI | 第三方资源要有完整性校验 |
这类问题有个共同点：它们经常不是“模型不知道安全”，而是模型在追求最快能跑通的答案。
比如你让 Agent 写一个小工具，它很容易顺手来一句 exec("curl " + url)；让它做一个后台展示页，它可能为了快直接把 HTML 字符串塞进 innerHTML；让它读模型文件，它也可能没认真区分可信文件和用户上传文件。
这些写法不一定每次都会立刻变成漏洞，但它们是安全事故最喜欢藏身的入口。
Security Guidance 的价值，就在于把这些“看起来只是方便一下”的选择，变成一个需要你停下来确认的提示。
安装简单，真正重要的是团队规则
安装本身没什么门槛。对普通用户来说，在 Claude Code 插件市场里装上，然后正常写代码就行。
但我觉得它对团队更有价值。
原因是安全问题从来不只是“有没有某个危险 API”。不同公司、不同项目的安全边界是不一样的：有的项目必须所有 tenant 查询都带 org_id，有的项目允许内部域名走特殊代理，有的项目要求密钥只能走 Vault，有的项目对日志里的用户内容特别敏感。
Security Guidance 预留了项目级扩展方式。源码里有两个入口：
💡 PROMPT
项目安全规则示例：
.claude/claude-security-guidance.md
.claude/security-patterns.yaml
第一个用于补充团队安全策略，第二个用于添加自定义正则或字符串规则。
这就比单纯装一个通用扫描器更实用。
你可以把团队内部的“不要这样写”沉淀成规则，让 Claude Code 在写代码现场就知道。不是等新人提 PR 后被 reviewer 反复教育，也不是等安全团队月底扫报告，而是在 Agent 生成代码的第一时间就把提醒塞回去。
当然，规则写得越贴近项目，效果越好。通用插件能帮你兜住最常见的坑；项目规则才能帮你兜住最容易在自己业务里出事的坑。
别把它当银弹
我不建议把 Security Guidance 理解成“装上就安全了”。
它更像是安全工程里的早期提醒层：能帮你拦掉一批明显危险写法，也能让 Claude 在结束前对本轮 diff 多想一次。但它不能替代威胁建模、权限设计、依赖审计、测试覆盖，也不能保证所有业务逻辑漏洞都被发现。
尤其是那些和业务语义强相关的问题，比如“用户 A 能不能改用户 B 的订单”“某个 webhook 签名是不是绑定了租户”“后台导出是不是绕过了数据范围”，这类问题往往不是一个正则能看出来的。
所以更合理的用法是：把它放在第一道门。
Claude Code 写代码时先过一遍 Security Guidance；提交前再跑测试和安全检查；PR 里继续人工 review；高风险模块再做更深入的审计。这样它的位置就很清楚：不是替你做完安全，而是让低级安全坑别那么容易混进代码里。
AI 编程真正危险的地方，不是它会犯错，而是它能把错误写得又快又像真的。
这也是我觉得这个插件值得装的原因。
它没有承诺“自动消灭漏洞”，这个承诺太大了。但它做了一件很实际的事：让 Agent 写出危险代码时，马上有人拉它一下。
对重度使用 Claude Code 的开发者来说，这种小护栏会越来越重要。
AI 写代码越快，安全提醒越要靠近代码生成现场。
