Cisco首席工程师Julio Gomez：LLM安全发现的瓶颈是信任，不是模型能力

大模型可以自信地告诉你代码里有漏洞，但你无法知道哪些说法被检查过、下周还能不能得到同样的答案、六个月后审计员追问时这条发现为什么存在。Cisco首席工程师Julio Gomez认为，这就是LLM安全工具从演示走向安全项目的全部距离。

他实现了Cisco发布的Foundry安全治理规范——一份设计文档而非产品——然后把它指向真实代码：Langflow 1.7.3的完整v1 API（289个函数级单元、25个模块）、MLflow 2.9.0（830个单元）、以及OWASP的PyGoat训练应用（180个单元）。他给自己定了一条硬规则：不设稻草人基线。对照组使用同一个模型、同一段代码、一个公平、有纪律、同样要求结构化发现和精确行号引用的资深应用安全提示。

结果是这样的：Foundry在Langflow上为人类呈现了32条发现，基线呈现15条；两者引用准确率都是100%；但基线把15条中的14条标为'已确认'，没有任何机制强制执行这个判断，而Foundry的28条确认和4条待审是由机械检查划出的。Gomez对此的总结是：模型从来不是瓶颈，信任才是。

Foundry的核心设计决策有两个。第一，检测是包容的，决策是严格的。Detector被要求偏好召回率——任何说得过去的都提出来；所有纪律都放在下游。这让同一个模型可以同时做到彻底和可信，而不是逼你在两者之间选一个。第二，证据门不是第二意见。它从不问模型'你确定吗'。它把每一条引用拿回去和磁盘上的字节核对：文件必须存在于目标中，行号必须在范围内，引用的文本必须真的出现在那里。只有引用存活的发现才被标为'已确认'，其余降级为'待审'或直接拒绝。模型无法靠争辩绕过不存在的行号。

这个分离为什么重要，Gomez用重复运行来说明。他独立跑了两次完整流水线，存储中122条记录折叠为67个不同指纹，56条在两次运行中复现并落在已有身份上——大约90%重叠，尽管模型输出本身不确定。这意味着下一次CI运行可以计算差异（新增、复现、消失），而不是让团队重新阅读一堵措辞不同的文字墙。第二次运行之后，团队通常就不跑了；有了稳定身份，他们才会继续跑。

在更大范围的MLflow上，治理同样成立：830个单元、41次批量调用、480万token在声明的600万上限内完成，发现落在MLflow历史CVE所在的同一区域（artifact存储层的路径遍历）。但只有13条被标为已确认，110条是待审线索——门在大范围陌生代码上变得更保守，这恰恰是分层在做它的工作。

Gomez明确声明他不是在宣称Foundry更聪明或更便宜。同一个模型，Foundry之所以发现更多，是因为它穷举扫描而不是让一次agent回合做策展。token成本约为单次调用的十倍，换来的是覆盖、机械门和去重。'已确认'意味着经过验证且值得审查者花时间，不意味着已被利用——证明可利用性需要活体测试台，那是规范中他未实现的独立角色。

他的结论是：当发现需要接入流程——一个不能被重复淹没的问题跟踪器、需要知道检查了什么的审查者、随代码变更重复运行的流水线——治理层的价值才显现。对于一名工程师看一小段熟悉代码的一次性检查，一个普通agent更便宜也更实用，直接用就好。

这篇是Security Loop系列的第二部分，发表于2026年11月2日。所有运行记录、溯源日志、规则缺口和评分比较公开在github.com/juliogomez/foundry。