CodeCrucible：Block 开源的 LLM 驱动 SAST 蓝图

Block 团队发布了一款名为 CodeCrucible 的新型 LLM 驱动静态应用安全测试（SAST）工具。与同类工具相比，团队更看重工具背后的「蓝图」——设计与权衡——希望其他团队可以参考并按需改造。

背景：从原型到生产化的蓝本

CodeCrucible 最早诞生于 Block 内部，最初的 Python 与 Node.js 原型借助 Repomix 压缩代码库、由具备智能体能力的工作流进行漏洞分析，并配套网页界面用于发起扫描与查看报告。此次对外发布的版本则面向生产环境：采用 Go 原生命令行工具，去掉了网页 UI 与人工引导式的报告流程。

团队认为，已经在市场上证明有效的黑盒 SAST 工具往往难以无缝迁移——下游团队通常要围绕原作者的设计取舍做适配，反而被不曾选择的架构决定束缚。因此他们把项目本身定位为「实现样例」，把可复用的设计、权衡与失败模式作为长期价值。

LLM 驱动 SAST 必须回答的四个问题

团队把同类系统在设计阶段就必须回答的四个问题摆到台面上，并认为这些选择通常比模型本身更关键：

• 压缩（Compaction）：如何把代码库塞进上下文窗口。常见做法包括 AST 摘要、基于 embedding 的检索、智能体式探索以及按发现锚点的片段分析，取舍在于覆盖范围与速度、token 成本之间。CodeCrucible 倾向于最大化上下文利用率与发现质量，而非追求最低成本。
• 识别（Identification）：如何让模型发现漏洞。从开放式提示（「找出 bug」）到针对具体 CWE 的定向检查与自我批评循环，取舍在召回率、精确率与 token 成本。CodeCrucible 将其拆成两阶段：主扫描做开放探索，审计阶段再做 CWE 定向深挖。
• 相关性过滤（Relevance Screening）：如何在模型「言之凿凿」的输出中筛掉无证据支撑的假阳性。常见手段包括二轮 LLM 复核、确定性过滤、污点式验证、人会审。CodeCrucible 使用二轮 LLM 复核配合置信阈值，再叠加去重与按源文件排序等确定性后处理。
• 确定性（Determinism）：如何让随机生成的输出在确定性流水线中可用。常见做法包括 zero-temperature 生成、多采样投票、schema 约束的结构化输出与确定性后处理。CodeCrucible 通过 JSON Schema 约束结构化输出，并叠加多层 JSON 修复与确定性清理。

四个选择并非彼此独立——选了一种压缩策略，往往意味着别处要做不同的决定。

整库打包：与「片段锚定」截然不同的另一条路

市面上的 LLM 驱动 SAST 系统，多半把传统静态分析器（如 CodeQL、Semgrep 或自研数据流引擎）放在模型前面：由规则触发候选发现，再让 LLM 复核该片段，LLM 扮演的是「复核员」而非「主分析器」。

CodeCrucible 走了相反的路——把整个仓库打包送进一次模型调用，附以方向性提示，让模型跨文件推理。代价是 token 消耗，收益是无需预置规则也能发现片段工作流难以触及的漏洞类别。

作者事后归纳了三个原因：首先，现代推理模型在长代码上下文上的稳定性比业内早期假设更好，一个 50K token 的仓库放在 200K token 的窗口里，模型游刃有余；其次，代码在剥离二进制、锁文件、vendored 依赖与生成产物后可压缩得比自然语言更多，省出空间；第三，跨文件推理正是 LLM 相对于传统静态分析的真正优势区，每多一份文件进上下文都可能创造价值。

不过文章也承认，这种思路并非全新想法——学界与 Snyk 等厂商的 CodeReduce 等工作已经在不同前提下论证过「模型只应看到必要片段」的结论。CodeCrucible 的取舍则是：愿意为跨文件推理付出更多 token，换取覆盖面的提升。