Cisco Foundry 实测：把 LLM 的安全猜测变成可验证发现

Foundry 并非让模型更聪明，而是给模型输出套上一层可运营的治理层。它由四个角色组成：Indexer 把代码切成函数级单元，Detector 让模型提出可能适用的安全规则并做探索性扫描，Triager 为每个候选给出带文件、行号和原文引用的结论，Reporter 为每条发现生成稳定身份并按严重度排序；外层 Orchestrator 负责硬性 token 预算、声明的停止条件、只追加的来源日志和去重存储。两个关键设计是：检测阶段追求召回，判定阶段严格把关；证据门不问模型“你确定吗”，而是把每条引用拿到磁盘字节上核对，文件必须存在、行号必须在范围内、引文必须真实出现，否则降级为待复核或直接丢弃。 第一个实测目标是 Langflow 1.7.3 的整个 v1 API，共 25 个模块、289 个函数级单元。基线使用同一模型、同一代码和一份要求同样严格的资深应用安全提示词。结果 Foundry 呈现 32 条发现，基线 15 条；确认/待复核为 28/4，由证据门强制，基线则是 14/1 自评；两者引用解析率均为 100%，幻觉引用均为 0；Foundry 消耗 2,053,308 tokens，约为基线的 10 倍，但完成了全部 289 个单元的扫描，基线没有声明停止条件。该轮最严重的发现是 Langflow 的一处严重代码注入：用户可控的 flow 显示名被拼进 Python 源码后交给 exec() 执行，仅做了小写化和空格替换下划线，无法处理括号、冒号或换行。 为验证可重复性，完整流水线以独立模型调用跑了两次，两次共 122 条发现记录，收敛为 67 个不同指纹，其中 56 条复现并落到既有身份上，重叠约 90%。第二个目标是 MLflow 2.9.0，仅改配置文件，引擎和 13 条规则语料不变，覆盖 830 个函数级单元，41 次批量调用，消耗 4,816,743 tokens，低于声明的 6M 上限，产出 123 条发现，其中 13 条真阳性、110 条待复核。34 条路径穿越发现集中在 MLflow 的 artifact 存储层和文件/URI 工具，与 CVE-2023-6909、CVE-2023-6977 所在区域一致。第三个目标是 OWASP 的 PyGoat，约 1 MB、180 个单元，六分钟内产出 45 条发现，42 条确认、3 条待复核、14 条评为严重，覆盖 11 类弱点。所有演示均在公开仓库中，可按固定 tag、先圈定外部输入面、用自然语言写明目标、设定 token 上限、加入自有规则的方式在自己的代码库上复现。