usercodeX-creator/Trace-core

GitHub: usercodeX-creator/Trace-core

Trace 是一款开源静态分析器,专门检测 AI 生成代码中的 24 种特定故障模式。

Stars: 11 | Forks: 1

Trace

AI 能写。Trace 能读。

npm license stars tests detectors languages

Trace 是一款用于分析 AI 生成代码的开源静态分析器。它能检测 24 种仅由 LLM 产生的故障模式——幻觉导入的包、源码中硬编码的凭据、被静默吞掉的异常、什么也不断言的测试、以及虚假的类型声明。Snyk、Semgrep 和 SonarQube 捕获不到这些,因为它们是为捕获人类编写的 bug 而构建的。AI 编写代码的方式不同。Trace 阅读代码的方式也不同。 ``` npx trace-core your-file.py ``` 无需安装。无需注册。采用 MIT 许可。支持六种语言。 ## Trace 可检测什么 涵盖 6 种语言的 24 种模式。按故障形式分组,而非按语言。 **供应链 (2)** - `hallucinated-deps` — 导入了 npm/PyPI 上不存在的包(或已被攻击者注册的包——参见 *slopsquatting*) - `go/slopsquatting` — 模仿合法模块路径的 Go 模块路径 **凭据 (3)** - `credential-leak` — API 密钥、令牌或密码硬编码在源码中 - `go/hardcoded-secret` — 同上,适用于 Go 二进制文件(通过 `strings ` 可暴露) - `hardcoded-localhost` — `http://localhost:3000` 这样的地址存活到了生产环境 **静默故障 (4)** - `silent-exception` — `except: pass`、`catch {}` 及类似处理程序吞掉错误 - `ruby/silent-rescue` — Ruby 的变体 - `go/error-ignored` — Go 中使用 `_` 忽略 `error` 返回值 - `missing-await` — 调用 `async` 函数时未使用 `await`;任务看似完成,实则不然 **注入 (5)** - `dynamic-eval` — 执行运行时构造的字符串的 `eval()` / `exec()` - `ruby/eval-injection` — Ruby 的 `eval` / `send` / `constantize` 被用户输入触及 - `go/sprintf-sql` — 使用 `fmt.Sprintf` 和用户数据构建 SQL - `ruby/string-interpolation-sql` — 使用 Ruby 字符串插值构建 SQL - `unsafe-sanitize` — 手动编写的输入清理(总存在漏洞) **批量赋值/授权 (1)** - `ruby/mass-assignment` — Rails 控制器绕过强参数直接将 `params` 传入模型 **虚假类型安全 (1)** - `fake-type-safety` — `as any`、`as unknown as Foo`、`@ts-ignore` —— 虚假的类型 **虚假测试 (1)** - `tautological-test` — 形如 `expect(true).toBe(true)` 的测试、被跳过的测试、无法失败的断言 **Rust 正确性 (4)** - `rust/unwrap-abuse` — 对依赖输入的值调用 `.unwrap()` / `.expect()` - `rust/panic-macro` — 在库代码中使用 `panic!` 而非 `Result` - `rust/todo-macro` — `todo!()` / `unimplemented!()` 遗留在发布代码中 - `rust/unsafe-block` — 在安全 API 可行的情况下使用 `unsafe { ... }` **加密与配置 (3)** - `insecure-rng` — 用于令牌的 `Math.random()` / `random.random()` - `env-no-fallback` — `process.env.X` 无验证;`undefined` 静默传播 - `deprecated-api` — 已计划移除的 API;LLM 的训练数据不知道它们已废弃 每次检测都附带[演示场](https://tracecheck.dev/playground)中的双语修复卡片,解释*为什么*这是个问题以及*如何*修复。 ## 为何存在 思考一下 AI 生成代码的形式。 当人类编写 `except: pass` 时,通常是出于懒惰,能在代码审查中被发现。当 LLM 编写 `except: pass` 时,这是模型对“处理错误”的默认答案。它进入生产环境是因为审查代码的人看到了 `except` 这个词,便假设发生了某些处理。 当人类输入 `import super-helper-validator` 时,这是个拼写错误,会被 npm 发现。当 LLM 输入 `import super-helper-validator` 时,这是一种幻觉——而攻击者已经开始在 npm 和 PyPI 上注册这些幻觉出的名称。这种供应链攻击现在有了名字:*slopsquatting*。 当人类编写 `expect(true).toBe(true)` 时,他们知道这是个占位符。当 LLM 编写它时,是因为你要求编写测试,而模型生成了测试形式的东西。CI 显示绿色。覆盖率达到 100%。但生产环境依然会崩溃。 这些并非传统意义上的 bug。它们是模型在教程代码上训练、优化为似是而非、大规模输出的可预测产物。为人类 bug 构建的工具忽略了它们,因为这些工具并非为这种故障分布而构建。 Trace 正是为这种分布而构建。 ## 快速开始 ``` # 扫描单个文件 npx trace-core your-file.py # 扫描目录 npx trace-core src/ # 用于管道传输到其他工具的JSON输出 npx trace-core src/ --format json ``` 如果未发现任何问题,退出码为 `0`;如果存在检测结果,退出码为 `1`。这就是你的 CI 信号。 ## 支持的语言 Python、JavaScript、TypeScript、Go、Rust、Ruby。 检测粒度因语言而异。Python、JS 和 TS 的覆盖最深,因为这些是当前大多数 AI 生成代码所在的地方。Go、Rust 和 Ruby 针对其最高信号的故障模式提供了聚焦检测器。 ## 对比情况 | | Trace | Snyk | Semgrep | SonarQube | Claude /ultrareview | |---|---|---|---|---|---| | 针对 AI 特定故障 | ✓ | ✗ | ✗ | ✗ | 部分 | | LLM 中立 (无供应商锁定) | ✓ | ✓ | ✓ | ✓ | ✗ | | 静态分析 (每次扫描 $0) | ✓ | 免费增值 | 免费增值 | 免费增值 | 每次扫描 $$ | | 开源 | ✓ | ✗ | 部分 | ✗ | ✗ | | 检测幻觉导入 | ✓ | ✗ | ✗ | ✗ | 部分 | | 检测重言测试 | ✓ | ✗ | ✗ | ✗ | 部分 | | 无需安装 | ✓ | ✗ | ✗ | ✗ | 绑定 Claude Code | | 可在任何 LLM 的输出上运行 | ✓ | 不适用 | 不适用 | 不适用 | 仅限 Claude | Trace 并非 Snyk 或 Semgrep 的替代品。它是它们之上的层次。运行 Snyk 进行 CVE 扫描。运行 Semgrep 执行你团队的自定义规则。运行 Trace 检测你的 LLM 置于其中的那些故障。 ## 安装 ``` # One-shot(推荐——无需安装,始终最新) npx trace-core src/ # 项目本地 npm install --save-dev trace-core # 全局 npm install -g trace-core ``` ## CI 集成 ### GitHub Actions 一行代码。在 PR 中发布包含等级和检测结果的评论,将 SARIF 上传到 **Security → Code scanning** 选项卡,在干净缓存下运行时间少于 30 秒。 ``` # .github/workflows/trace.yml name: Trace on: [push, pull_request] permissions: contents: read security-events: write pull-requests: write jobs: trace: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: usercodeX-creator/trace-action@v1 with: path: src/ ``` [Trace Check 在 GitHub 市场](https://github.com/marketplace/actions/trace-check) · [trace-action 仓库](https://github.com/usercodeX-creator/trace-action) ### 其他 CI (GitLab, Bitbucket, CircleCI, Jenkins, ...) ``` - run: npx trace-core src/ ``` Trace 写入 stdout,检测到问题时以非零状态退出,并接受 `--json` 输出机器可读结果。CI 所需的就是这些。 ## 在浏览器中尝试 [tracecheck.dev/playground](https://tracecheck.dev/playground) — 粘贴代码,点击检查,查看检测结果及修复建议。无需安装,无需注册,无需账户。 ## 理念 **针对 AI,而非通用。** Trace 不试图替代 Snyk 或 Semgrep。它狭窄地聚焦于当代码由模型生成时出现的故障模式。每个检测器的存在都是因为团队观察到 AI 在生产代码中大规模产生该模式。 **中立第三方。** Trace 并非由 Anthropic、OpenAI 或任何 LLM 供应商构建。它在所有模型的输出上运行。一家 AI 公司在发布自身模型的缺陷目录时存在结构性利益冲突。中立工具则没有。 **开源,并将保持开源。** 这 24 个检测器采用 MIT 许可。无使用限制。未经明确同意无遥测。无限制核心功能的 “企业” 层级。今天,此仓库中包含检测这些故障所需的一切,且完全免费。 ## 路线图 公开路线图是变更日志加上 GitHub Issues 中的内容。简版: - **v0.8**:基于聚合的自愿参与数据进行检测器调优(首期 *Trace Index* 月度报告将同期发布) - **v0.9**:用于项目级别严重性覆盖和抑制的配置文件 - **v1.0**:稳定性承诺——检测器在一个主要版本内其含义保持不变 无预计时间承诺。准备就绪时即发布。 ## Trace 索引 Trace 发布月度报告:AI 生成代码故障的聚合形式,按语言、模型和检测器细分。基于自愿参与的遥测数据构建。首期:2026 年 5 月。 参见 [tracecheck.dev/insights](https://tracecheck.dev/insights)(即将推出)。 ## 许可证 [MIT](./LICENSE)。 ## 链接 - **网站**:[tracecheck.dev](https://tracecheck.dev) - **演示场**:[tracecheck.dev/playground](https://tracecheck.dev/playground) - **日文 README**:[docs/README-ja.md](./docs/README-ja.md) - **npm**:[trace-core](https://www.npmjs.com/package/trace-core) - **作者**:[@usercodeX-creator](https://github.com/usercodeX-creator) · 东京,日本
标签:AI代码检测, CMS安全, Go, JavaScript, LLM代码分析, Python, Ruby, Ruby工具, Rust, TypeScript, 二进制发布, 云安全监控, 代码安全, 可视化界面, 子域名暴力破解, 安全工程, 安全插件, 工具, 幻觉依赖, 开源工具, 数据可视化, 数据隔离, 无后门, 日志审计, 漏洞枚举, 知识库, 秘密管理, 网络流量审计, 自动化攻击, 自动化检测, 软件开发, 逆向工具, 错误检测, 静态分析, 静默失败