现在的 AI coding 工作流，真正越来越难管的，已经不是“能不能接到工具”，而是：

你到底敢不敢把别人写的 skill、hook、MCP server 和 plugin 直接装进自己的环境。

只要开始频繁试第三方 artifact，很快就会碰到一些很现实的问题：

  • 它会不会顺手把环境变量、API key 或 SSH key 发出去；
  • 它是不是默认给了过宽的工具权限；
  • 它有没有藏着会改 crontab、写 authorized_keys、删文件的脚本；
  • 它的描述、schema 或安装脚本里有没有把 agent 往错误方向带的注入内容。

今天想记下的 ryo-ebata/cc-audit，切的就是这层风险，而且思路相当直接：

不要先安装再祈祷，先扫描，再决定要不要装。

按 GitHub 仓库页、README、releases 页面和 GitHub API 在 2026-07-02 能看到的公开信息，这个项目当前约有 22 stars、1 fork。仓库主语言是 Rust，许可证是 MIT。仓库创建于 2026-01-24，最近一次公开代码推送时间是 2026-07-02。最新 release 是 v3.2.14，发布时间是 2026-02-02。

项目概览

属性详情
仓库ryo-ebata/cc-audit
定位面向 AI coding artifact 的静态安全审计工具
Stars22
Forks1
主语言Rust
仓库创建时间2026-01-24
最近公开代码推送2026-07-02
最新版本v3.2.14
版本发布时间2026-02-02
代码许可证MIT
核心思路在安装前对 skill、hook、MCP 和相关 artifact 做确定性安全扫描

它解决的不是“怎么写 skill”，而是“怎么先别把自己坑进去”

cc-audit 最值得看的地方，是它把 AI coding 生态里的安全问题说得很明白。

README 开头就把目标定得很窄也很准：这是一个 Security auditor for Claude Code skills, hooks, and MCP servers。也就是说，它不是又一个技能市场，不是更大的 agent 框架，也不是泛化的代码扫描 SaaS。

它盯的是一个非常具体的入口：

第三方 artifact 准备进入你本机工作流的那个瞬间。

这个切点很重要，因为很多风险不是来自模型本身，而是来自你愿不愿意把别人写的脚本、配置和 tool 边界，直接拉进自己的环境里执行。

风险模型非常贴近真实使用场景

README 里列出的几类风险都不是抽象口号，而是实际会踩到的东西：

  • 数据外传；
  • 提权；
  • 持久化；
  • 提示注入；
  • 过度授权。

如果你已经装过一些第三方 skill 或 MCP server，这些词基本不用翻译就能懂。

真正有用的是，cc-audit 没有把问题停在“请谨慎安装”这种软提醒上，而是尝试把它变成一条明确流程：

  1. artifact 先落地；
  2. 用确定性的规则扫描；
  3. 按严重级别给出结果和风险分数；
  4. 再决定是否安装、是否允许进仓库、是否进入 CI。

这比把安全完全寄托在 README 观感或市场评分上靠谱得多。

它扫的不只是 skill 目录

我觉得 cc-audit 第二个很强的点，是扫描对象并不只限于一个 SKILL.md 文件夹。

从 README 当前列出的能力看，它已经覆盖了不少 AI coding artifact 类型，包括：

  • skills；
  • hooks；
  • MCP 配置；
  • Docker 相关内容；
  • dependencies；
  • subagents；
  • plugins。

命令层也比较清楚：

cc-audit check ./my-skill/
cc-audit check --type mcp ~/.claude/mcp.json
cc-audit check --type docker ./
cc-audit check --type dependency ./
cc-audit check --all-clients

这意味着它不是只在“单个技能包体检”这个窄场景里有用，而是有机会变成一条更完整的本地准入门。

尤其 --all-clients 这个方向很实用。很多人现在并不是只用一个宿主，而是 Claude、Cursor、Windsurf、VS Code 一起装一圈。问题也常常不是某个 skill 自己危险，而是你根本已经忘了哪些 client 下面挂着哪些配置。

它强调的是可复现规则，不是“让另一个模型帮你判断”

这类工具如果要真的能进工作流，我最在意的一点是：

结果是不是确定性的。

cc-audit 的路线很明确。它走的是静态规则审计，不是再叫一个 LLM 帮你读 artifact 然后给一句模糊建议。

README 里可以看到它已经把输出做成比较工程化的样子：

  • 明确的规则编号；
  • 严重级别；
  • 风险分数；
  • 失败退出码；
  • JSON、HTML、SARIF、Markdown 等输出格式。

这类格式化输出很关键，因为它让工具可以进入：

  • 本地预检；
  • Git pre-commit hook；
  • CI；
  • 安全审计报告；
  • 仓库合规门禁。

一旦结果可以稳定复现，讨论才不会停留在“我感觉这个 skill 有点怪”。

不是只看安装前，它还想延伸到运行期和变更漂移

很多安全工具都会卡在一次性扫描这里，但 cc-audit 在 README 里已经明显往后多走了一步。

当前公开能力里比较值得注意的还有：

  • baseline / drift detection；
  • MCP pinning；
  • remote repository scanning；
  • proxy mode；
  • watch mode；
  • CVE vulnerability scanning。

这里最有价值的不是 feature 数量本身，而是作者显然意识到：

artifact 的风险不只在第一次安装，也在后续更新和运行期变化。

如果一个原本看起来没问题的 skill，后面偷偷改了权限、脚本或依赖，这就不再是“初次审计”能单独解决的事。baseline、pinning 和 proxy 这些能力，都是在补这条链路。

最新 release 暴露了项目正在补“坏天气”细节

最新的 v3.2.14 release 不算华丽，但我觉得方向挺对。

这次 release 页面里最直接的一条 bug fix，是：

  • 遍历目录时遇到 WalkDir 错误，不再静默吞掉，而是明确记录日志。

这听起来不大，但很重要。

因为安全工具最怕两件事：

  • 你以为它扫过了，其实有路径没扫到；
  • 它遇到异常时悄悄跳过，让“通过”看起来比实际更干净。

换句话说，这个修复不是在做 demo 功能，而是在修“失败时别装作成功”。这对安全工具比再多一个 marketing feature 更关键。

它适合谁

我觉得 cc-audit 特别适合下面几类人：

  • 经常试第三方 Claude Code skill、hook 或 MCP server；
  • 同时维护多个 AI coding client；
  • 想把本地 artifact 准入做成流程，而不是靠经验；
  • 希望扫描结果能进入 hook、CI 或合规报告；
  • 对 agent 工具链的供应链风险比较敏感。

如果你只是偶尔装一个自己写的小脚本，它未必马上是刚需；但只要你开始复用社区 artifact，或者团队里不止一个人往工作流里加东西，这种“先审计再安装”的工具很快就会变得很值。

小结

ryo-ebata/cc-audit 吸引我的地方，不是它把安全说得多宏大，而是它把问题切得非常具体：

  • 第三方 skill、hook、MCP 和 plugin 到底能不能进本机；
  • 哪些风险能在安装前就先拦住；
  • 扫描结果能不能变成明确的工程门禁。

它没有试图成为更大的 agent 平台，而是老老实实做一件很重要的小事：

在 AI coding artifact 进入工作流之前，先给你一份可复现、可自动化、可解释的安全体检。

如果说很多 agent 工具在解决“还能多做什么”，那 cc-audit 更像是在解决：

哪些东西根本不该先被放进来。