AI 修复静态扫描漏洞，该验收什么

dev.to · AI#代码安全#漏洞修复#静态分析

Editor brief · 编辑速览

文章讨论 AI 为 SAST 告警生成修复代码时的安全边界，指出修复往往需要整份文件及相关调用上下文。重点提醒防范附带行为变更、细微缺陷和表面修复带来的错误信任。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

SAST（静态应用安全测试）能指出哪一行可能有漏洞，却很难替团队完成修复。AI 可以接过写补丁的工作，但这篇文章给出的边界很明确：它负责提出修改，正确性仍要靠测试、复扫和人工审查确认。

作者以 Onam 的实现说明，修复质量取决于上下文、规则指引和交付流程。不过，原文没有提供修复成功率或对照实验，适合拿来检查流程，不能直接当作工具效果的证明。

一次 SAST 扫描通常会给出规则、文件、行号和严重程度。这些信息足以定位问题，却未必足以写出补丁。

比如一处 SQL 注入，问题显示在某一行，真正的修改可能涉及同文件里的查询辅助函数、参数列表和 import。规则告诉开发者「使用参数化查询」，但具体怎么传参数，还得看项目使用的语言、库和封装方式。

接手告警的人也未必是代码作者。他需要先理解旧代码，再判断修改会影响哪些调用路径。一个遗留文件如果同时包含多条告警，逐条生成补丁还可能互相冲突。

因此，作者主张把完整文件、文件内的全部待修复告警，以及每条规则的修复建议一起交给模型。规则还应附带目标语言的合规示例，帮助模型沿着已知的安全模式修改。

这套输入方式有明确目的：让模型看见相关调用和代码风格，并协调同一文件里的多处改动。完整文件能补足片段缺失的上下文，但原文没有证明它足以覆盖所有跨文件依赖。

模型可以为注入、不安全的加密函数使用、硬编码凭据、不安全反序列化等常见问题起草修复。作者用的是「合理的修复草案」这个尺度，没有承诺它一定正确。

AI 生成的补丁应当作为待审提案，进入团队已有的 review 和 CI 流程。

限制首先要写进指令：只修列出的告警，保留变量名、缩进和风格；只有修复确实需要时才添加 import。小范围 diff 更容易核查。模型顺手重写函数、调整返回值，即使代码能编译，也会增加判断行为是否变化的成本。

规则元数据则负责限制修复方向。例如，规则要求参数化查询，就应检查补丁是否采用了这一模式，不能只看输入是否经过某种手工转义。已经被人工标为误报的告警也应跳过，避免反复修改团队已经审查接受的代码。

原文还划了两条工程边界。用于写入仓库的凭据，应按请求传递、限制到目标仓库，并且不存储、不记录日志；模型不可用或没有返回有效结果时，仍要展示规则解释和合规示例，让开发者能够继续处理。

按作者描述，Onam 从已经完成的扫描读取告警，跳过误报，并允许按严重程度筛选。随后读取规则标题、描述、修复建议，以及存在时与目标语言匹配的合规示例，再浅克隆源代码仓库。

告警按文件分组。每个文件的完整内容、全部待修复告警和规则指引，一起发送给大语言模型。修正后的文件提交到以扫描命名的独立修复分支，再推送到仓库供团队审查；引擎不执行合并或部署。

推送所需的 Git token 通过每次请求的 header 传入，作者称其不会被存储或记录。每条告警也会记录处理状态，便于区分哪些已在分支中打补丁、哪些尚未处理。

这里必须分清两件事：状态显示已打补丁，只能说明工具完成了修改；要判断漏洞是否消失，还得复扫。要判断业务是否仍然正确，还得测试和人工审查。

原文要求合并前同时检查：diff 范围是否必要，是否采用规则指定的安全模式，有无无理由新增的依赖或 import，错误处理和返回值是否保持预期。已有测试要通过，也要有测试覆盖修复路径；复扫既要确认原告警消失，也要检查是否产生新告警。最后，审查人需要理解业务代码，而不只是认识安全规则。

我认同它把「生成补丁」和「接受补丁」分开的做法。规则指引、集中处理同文件告警、限制改动范围，都有助于降低审查难度，比把一条告警直接丢给通用聊天窗口更容易约束输出。

但这是设计上的合理性，尚不是效果证据。作者没有提供样本量、模型信息、直接合并比例，也没有比较整文件输入与代码片段输入的实际差异。哪些规则修得稳定、哪些容易误改，原文没说清。

另外，同文件分组只解决了一部分上下文问题。跨文件的调用约定、数据库封装行为，可能仍需审查人补充判断。对于缺少测试的遗留项目，自动生成越快，也可能只是让待审补丁堆得更快。

原告警消失，是合并前的必要检查，不能单独证明修复正确。

Onam 的流程可以参考，但采用类似产品时，仍需核实其凭据处理、状态含义和失败回退是否符合描述，不能用文章中的产品自述替代验证。