Gach0ng
Gach0ng
威胁情报Z分析
2026年7月17日%2011:18
海南
在小说阅读器读本章
去阅读
最近在梳理%20AI%20代码审计的落地方案，看下来大致是两条路线。一条是给大模型套个壳的黑盒扫描器，报告拉出来误报密度并不比传统%20SAST%20低，一个Runtime.exec就标红;另一条是单%20Agent%20端到端，丢一个仓库进去让它自主发挥，demo%20阶段能挖出注入类漏洞，但流程完全是黑箱，很难放到%20CI%20里无人值守地跑——你无法预判它下一步会执行什么。
今天早上七点%20Google%20开源了%20Mantis，我的判断是它在工程化这件事上想得比较透。它真正的特点不在效果，而在设计前提：整套架构默认%20AI%20是不可靠的，然后用工程手段把这种不可靠约束住、过滤掉、再沉淀下来。这跟\"模型能力越强、效果自然越好\"的思路方向相反。
这篇不讲安装和使用，README%20已经写得很完整。我想说的是它背后的设计取舍——一家大厂认真做%20AI%20安全审计时，底层的工程逻辑是什么，哪些决策是想清楚了才这么定的。
多数团队做%20AI%20代码审计，大概率会做成一个端到端%20Agent：接入仓库，内部一次性完成读代码、找洞、验证、出报告。这个形态的问题在于它是个黑箱——中间某一步偏了很难定位，上下文一超模型就开始编，而且整个流程的调度权都握在模型手里，跳步、漏步都不受控。
Mantis%20的选择相反。它把审计流程拆成十几个彼此独立的%20Skill(一个监督者加十五个执行阶段)，每个%20Skill%20是一份带提示词的SKILL.md。阶段之间不通过对话传递上下文，而是通过文件系统传递状态——所有中间产物落在workspace/findings/\*.json这类文件里。
这个看似朴素的选择，实际上解掉了几个具体问题。
一是解耦。每个环节可以独立调优、替换、测试。粗筛用便宜的快模型，深挖换旗舰模型，互不干扰;某一步出问题，直接看那一步的输入输出文件即可定位，不必在几十万%20token%20的对话里回溯。
二是状态落地、流程可追溯。findings%20里每个漏洞是一个独立%20JSON，带一份history记录它经过哪些阶段、被改了什么。更关键的是，模型能写哪些字段、能流转到哪些状态，schema.json里已经用契约固定死了。这等于把\"模型失控\"的影响范围，压缩到了单个文件的边界之内。
三是可按需拼装。你完全可以只取它的知识库构建和计划阶段，初筛替换成已有的商业%20SAST，后续验证复现再接回来。官方对自身的定位也是\"起点和地基\"，而非成品方案。
这个拆分的目的很清楚：把一个不确定的系统，变得可控、可观测、可替换。这一层立住了，后面的设计才有意义。
真实审计从来不是打开文件就逐行找洞。Mantis%20这条链路，大致可以拆成三段来看。
不少%20AI%20审计工具的通病，是上来就逐文件把代码喂给模型。这么做既消耗%20token，又缺乏全局视角——模型面对单个%20controller，并不清楚参数来自哪个不可信入口，也不知道这段代码在整个系统的信任结构里处于什么位置。
Mantis%20的顺序是反的。挖洞之前，它先用几个阶段把项目摸清：扒版本控制历史，提取过去修复过的漏洞、安全补丁和反复出问题的模式;为每个目录生成摘要，建立粗粒度地图;最核心的一步是architecture阶段，把整个代码库合成一个结构化知识库，用互相链接的%20Markdown%20梳理实体、数据流和历史漏洞类别。
这一步是它的关键设计。传统%20SAST%20依赖%20AST、控制流图、数据流图这套精确的图结构做污点分析，从%20source%20一路跟到%20sink。LLM%20没有这套结构，整个仓库的图也放不进上下文。Mantis%20的替代物就是这个知识库——一张用自然语言描述、可压缩的语义地图：实体是节点，数据流是边，只不过停留在语义层而非语法层。
\"什么算有害\"这件事同样被语义化了。传统%20SAST%20的%20source/sink%20是硬编码规则表，$\_GET是源、某函数是汇。Mantis%20把它交给威胁模型文档里的信任边界定义：哪里是不可信入口、攻击者从何处进入、哪些资产受损才算真正的问题。审计时模型不是匹配函数名，而是推理\"数据来自外部边界，未经校验流入了高危操作\"。这也是它能覆盖业务逻辑漏洞和越权的原因——这类问题没有固定的%20source/sink%20签名，规则表覆盖不到。
省%20token%20的机制也来自这里。有了分层知识库和目录摘要，后续大部分环节只需读取知识库中相关的片段，不必反复塞入全量代码。审认证相关代码时，计划阶段只注入知识库里认证相关的摘要，而不是整个仓库——用压缩后的语义，替代了%20AST%20的全图遍历。
这是%20Mantis%20里我认为最务实的部分。它并不指望模型一步输出精准结果，而是接受一个现实前提：初筛就应该广撒网，宁可多报，再逐层过滤。
挖洞环节本身分波次。第一波用便宜的快模型高并发扫描，每个文件只输出一句判断——是否可疑、原因是什么，纯粹用于注意力聚焦;第二波才把旗舰模型投给第一波标出的热点，复杂文件甚至让多个%20Agent%20以不同视角并行审同一文件，重叠部分交给后续去重。
真正体现设计的是过滤链。一个疑似点上报后要连过数关：先去重，把并行%20Agent%20报出的重复项按代码位置合并;再由专门的验证阶段用一组严格的负面规则滤除明显误报;然后判断该问题在%20release%20构建里是否可达——很多\"漏洞\"只在%20debug%20模式或断言开启时成立，生产环境无法触发;最后一关，把%20PoC%20放进隔离沙箱实际执行一次。
最后这步是它与传统%20SAST%20的分水岭。前面几关都还是在推理漏洞是否成立，到复现环节则不再推理，直接执行：能触发即为真，不能触发则大概率是误报。用动态执行给静态推理兜底，置信度由此拉高。几层筛完仍然存活的，基本都达到了可上报的质量。
我逐渐觉得，AI%20审计的关键问题常被问错。大家纠结\"模型能否不犯错\"，但模型必然会犯错，这是前提而非变量。更该问的是\"是否有一套机制把它的错误筛出去\"。Mantis%20给出的答案就是这条过滤链。
多数扫描工具扫一次和扫一百次是同一水平，不长记性。Mantis%20构建了一个闭环：每轮结束后，有一个反思阶段解析本轮所有%20Agent%20的执行轨迹，把误报、未复现、走不通的攻击路径提炼成结构化经验，追加进learnings.jsonl。下一轮运行时，这些经验会回流到知识库和计划阶段，主动规避此前踩过的坑。
这让工具具备了进化能力。某个模式在第一轮被误报、被%20critic%20抓出，教训随即沉淀，后续轮次不会在同一处重复出错。工具不再是一次性交付，而是对特定代码库越扫越熟。
再提两个我比较认可的设计。一个是漏洞链拼接——它不满足于报单点漏洞，有专门的阶段把已验证的多个发现串联，判断能否组合成完整的多步利用链，生成所谓\"超级发现\"。这恰恰是%20AI%20相对传统工具的优势所在：传统%20SAST%20给出的是孤立告警，而把这些点连成一条真实可行的攻击路径，最吃语义理解和推理能力。另一个是风险评分，它不是简单套用%20CVSS，而是结合影响、可利用性、暴露面综合计算，并引入了与威胁模型挂钩的\"暴露程度\"维度，帮助把真正应优先修复的问题排到前面。
抛开具体模块，有几个更底层的取舍，是这套框架里最值得借鉴的部分。
从设计之初就默认%20AI%20不可信。沙箱、断网、最小权限、隔离部署，在%20Mantis%20里不是事后补救，而是架构前提。复现和打补丁阶段被明确约束：AI%20生成的%20payload%20只能在隔离容器内执行，且要求--network%20none断网运行。原因很直接——模型可能生成破坏宿主机的代码，也可能被目标代码中的恶意内容反向提示注入。既然无法保证它始终可控，就从架构上确保它即便出问题也逃不出沙箱边界。这个前提比任何单项技术都更重要。
不回避非确定性，而是加以利用。通常做法是把模型的不稳定当缺陷去压制。Mantis%20的处理相反——它承认同一段代码，模型这一遍可能漏掉某个越权，下一遍因注意力偏移反而能命中。因此它索性设计成多轮循环扫描，靠每一轮的注意力差异补齐覆盖度，而非强求一次扫净。它也保持了清醒：轮次过多会导致发现质量下降，模型开始报一些吹毛求疵的非问题，何时停止需要人依据风险分自行判断。把一个看似棘手的缺陷转化为提升覆盖率的手段，这个视角值得留意。
LLM%20只承担执行层，流程控制权交给确定性程序。这是它对生产环境的核心建议。交互式场景可以让模型自主驱动流程，但真正上生产时不应如此——应当用脚本或流水线编排这些%20Skill，把沙箱、权限、网络策略固化在编排层。这样\"记得断网\"不再依赖模型自觉，而成为程序层面的硬约束;critic%20这类验证环节也不会因模型\"忘记调用\"而被跳过。无人值守运行的底气正来源于此。
经验可沉淀为先验。前面提到的学习闭环，抽象一层就是这个判断：一个工具是否值得长期投入，取决于它踩过的坑能否成为下一次的起点。Mantis%20至少在单代码库维度做到了这点。官方路线图里还有更进一步的设想——用积累的教训反向自动改写%20Skill%20的提示词，但它很克制地强调这种自我修改必须人工把关，以防被提示注入利用、把某类漏洞全局屏蔽掉。
大致分三档，按风险承受能力和自动化程度选择。
个人或小团队适合交互式运行。在%20CLI%20里逐条输入斜杠命令，模型每次执行敏感操作——运行%20Docker、写文件等——都会暂停等待确认。效率略低，但每一步的意图都可见，安全且灵活，也是熟悉整套流程的最佳方式。
企业内部建议自建一套确定性编排流水线，把这些%20Skill%20当作读写%20JSON%20状态的微服务来调度。沙箱、权限、网络策略固化在编排层，模型只在受控范围内工作，不接触宿主环境。这样既保留了%20AI%20的分析能力，又把提示注入和越权操作的风险摁在架构层。CI/CD%20集成和横向扩容，也只有在这个形态下才谈得上。
大规模持续审计则需要真正隔离的云环境：独立%20VM、出口网络管控、最小权限服务账号、只可追加不可删除的存储。以无人值守方式循环运行，一旦复现出高置信度漏洞，直接推送到告警系统。把扫描环境与内部系统彻底解耦，是这种模式的前提。
需要客观指出两点局限。Mantis%20不是开箱即用的产品：默认提示词明显是针对%20C/C++/Rust%20这类内存安全语言调校的，通篇是%20crash、buffer、release%20构建复现的语境，用它审%20Java%20Web%20或%20Python，至少要重写\"挖什么\"和\"如何判定复现成功\"这几个阶段的提示词。落地有门槛，官方也反复说明这是\"起点\"而非\"终点\"。
它也不能替代人。文档里的警告很实在：AI%20会幻觉，所有发现在上报前必须经人工复核，不要拿未经验证的%20AI%20报告去大量提交给开源项目维护者。工具再进化，最终拍板的仍是人。
但这些不影响我的整体判断。AI%20代码审计的瓶颈从来不在模型强弱——模型只会越来越强。真正的难点在于，能否用工程化手段把这个不确定的系统约束住、用好，并让它逐步沉淀出能力。Mantis%20的价值，正是把这套思路完整地呈现了出来：如何拆分、如何过滤、如何兜底、如何进化。相比之下，具体的模块和提示词反而是最容易被替换的部分。真正可以借鉴的，是这套工程化的设计思路。
限于个人视野，文中观点难免存在疏漏。
感兴趣 AI 安全、网络安全的朋友，欢迎一起交流探讨。
联系方式：Gach0ng
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论