2026-07-20 04:22:01 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文反思并重构了LLM代码审计方法论，批判了以模型或技术组件堆叠为中心的旧路线，主张转向以安全声明和证据为中心的新范式。核心结论是平台目标应为在明确边界内以可接受成本增加可验证的风险发现。文章提出将漏洞发现定义为可证伪声明，建立E0至E5的证据阶梯与证据账本替代传统聊天记录。建议首个落地场景选为SAST告警分诊，并强调需通过四类互补数据集与增量消融实验进行严格评测，以克服行业普遍存在的幸存者偏差与指标失真问题。 综合评分： 93 文章分类： 代码审计,AI安全,安全建设

cover_image

LLM 代码审计方法论：反思、反驳与重构

原创

Purpleroc Purpleroc

Purpleroc的札记

2026年7月19日 15:30 广东

在小说阅读器读本章

去阅读

本文为Codex + GPT5.6 Sol对现有已收集文章总结出来的方法论的逐步反思、反驳和重构过程。看着有点引人反思～希望对你有用

0. 结论先行

现有调研的主要方向没有错：纯 LLM 裸扫整仓不可靠，程序分析、上下文工程、验证、人工复核和持续评测都不可缺少。但它仍然带有明显的“技术组件中心主义”：先列出 SAST、CPG、RAG、Agent、Skills、MCP、沙箱，再设想把它们组合成平台。

更合理的顺序应当反过来：

1. 先定义平台要支持哪一种安全决策。
2. 再定义该决策可接受的漏报、误报、延迟、人工成本和证据门槛。
3. 把每个漏洞结论拆成可证伪的安全声明。
4. 让不同工具提供有来源、有局限的证据，而不是把工具输出称为事实。
5. 只在 LLM 能产生可测增量价值的位置使用 LLM。
6. 用隐藏、时间外、项目隔离和真实低基率数据做前瞻性验证。
7. 最后才决定是否需要 Agent、CPG、RAG、微调或多模型。

新版方法论的核心目标不是“让 AI 尽可能多报漏洞”，而是：

在明确覆盖范围内，以可接受的人工与计算成本，持续增加经过验证、可行动的安全风险发现，并诚实报告没有覆盖和无法判断的部分。

可以把平台的北极星指标写成一个决策函数：

净安全收益
= 已验证发现带来的预期风险降低
- 误报造成的审查与打断成本
- 漏报和错误阻断成本
- 计算与平台运营成本
- 执行不可信代码、泄露源码等平台自身风险

这个函数不要求把所有风险伪装成精确金额；它要求所有技术指标最终能解释对真实安全决策的影响。

1. 先反思资料和结论是怎样产生的

1.1 公众号材料不能按篇数投票

现有资料库有 175 个公众号原文文件，其中 147 个被标记为“正文可分析”。但当前的“逐篇结构化梳理”由脚本按照关键词匹配，从关键词周围截取文本，并根据主题套用固定的“平台启发”。这能做索引和候选筛选，不能等同于逐篇语义精读。

例如，正文只要出现“平台”“模型”“评测”等高频词，就可能同时被归入多个主题；“平台/产品/工程化 166 篇”并不能说明 166 篇都为平台方法论提供了独立证据。部分文章是产品宣传、新闻聚合、LLM 应用安全或通用模型评测，与源代码漏洞发现只有间接关系。

因此，公众号材料应重新分成四种用途：

后续若要让公众号材料真正参与方法论，应对高价值子集逐篇人工或高质量模型精读，并记录“原文主张—原始证据—我们的判断—是否复现”，不能继续用文章数量强化共识。

1.2 论文和开源仓库也不天然是强证据

“同行评审”“有 GitHub 仓库”“公开了数据集”都只是最低门槛，不代表结论可以直接迁移到生产：

• 已知 CVE 定位不等于开放世界漏洞发现。
• 函数二分类不等于仓库审计。
• 修复 Agent 不等于发现 Agent。
• 可构建的 CVE 存在严重选择偏差。
• 在 15 个项目上发现真实 bug，不能证明对其他语言、框架和组织有效。
• 论文中的模型、工具、依赖和提示可能已经变化，仓库也可能无法完整复现。
• 同一研究团队构造的数据、系统和评测，存在无意中适配基准的风险。

所以证据分级不应只按“论文/博客”分类，还要评估：任务是否相同、标签是否可信、数据是否泄漏、是否独立复现、是否开放世界、是否符合目标组织的漏洞分布。

1.3 现有调研存在检索与幸存者偏差

当前语料主要通过“LLM、代码审计、大模型、漏洞挖掘、Agent、MCP、Skills”等关键词找到。它天然更容易收集：

• 宣称使用 LLM 的成功案例；
• 愿意公开的研究结果；
• 热门模型和平台；
• 能形成文章叙事的真实漏洞。

它不容易收集：

• 没有发现任何漏洞的扫描；
• 被安全团队放弃的内部试点；
• 误报和漏报明细；
• 运行失败、构建失败和成本长尾；
• 被普通规则或人工更快发现的对照案例。

新版方法论因此不把“大家正在这样做”解释为“这样做已经有效”，而把它视为待实验的设计空间。

2. 对现有方法论的逐条反驳

2.1 反驳：“LLM 是审计系统的核心推理部件”

这句话仍然以模型为中心。生产平台真正不可替代的核心应是：组织安全语义、程序证据、验证资产、历史判断和评测闭环。LLM 应是可替换的推理执行器。

如果更换模型就导致平台的发现定义、证据格式、严重度和工作流全部变化，说明平台没有形成稳定的方法论，只是包装了一个模型会话。

2.2 反驳：“程序分析负责事实，LLM 负责语义”

AST、调用图、污点路径、CPG 和 SAST 结果也不是无条件事实。它们依赖构建是否成功、框架模型是否正确、动态分派是否解析、反射和代码生成是否覆盖、配置是否匹配生产环境。

更准确的说法是：

程序分析输出可追溯的工具证据；
LLM 输出可审查的语义假设；
验证器和人工根据多种证据作出结论；
所有结论同时保留适用条件和覆盖缺口。

2.3 反驳：“神经符号路线是最值得优先投入的总路线”

IRIS 等工作证明了 LLM 补全静态分析规格在特定 Java 污点任务上可能有显著价值，但不能据此推导它对业务逻辑、竞态、密码学误用、内存安全、供应链配置和跨服务授权都最优。

神经符号是一类很有价值的局部模式，而不是统一答案。应先按任务做基线和消融，再决定是否需要 CodeQL、Joern、符号执行、模糊测试或其他验证器。

2.4 反驳：“动态验证是从 Demo 到生产的统一分水岭”

动态验证很强，但不是万能真值机：

• PoC 失败可能只是环境、覆盖或输入生成失败，不能证明没有漏洞。
• PoC 成功可能依赖不现实的配置或测试夹具，不能自动证明生产可利用。
• 授权、竞态、密码学、侧信道和跨服务状态漏洞常难以在通用沙箱中复现。
• 执行不可信仓库、构建脚本和依赖本身会引入严重安全风险。

正确做法是建立证据阶梯，而不是把“有 PoC/无 PoC”作为二元门槛。形式化证明、确定性静态路径、差分测试、生产配置证据和人工复核都可能形成高强度证据。

2.5 反驳：“发现 Agent 和反证 Agent 分离即可减少偏差”

如果两个 Agent 使用同一模型、相似提示、相同上下文和相同错误工具，它们的错误高度相关。多角色讨论和多数票不会自动产生独立证据，有时只会把错误说得更流畅。

真正的反证应优先来自不同机制：

• 用编译器、查询、测试或运行时观测验证模型主张；
• 让验证阶段看不到发现阶段的严重度和说服性叙述；
• 单独检索 guard、sanitizer、权限检查和不可达条件；
• 对关键样本做盲化人工复核；
• 把“不确定”和“证据不足”作为正常输出。

2.6 反驳：“Skills/MCP 是平台能力的重要中心”

Skills 和 MCP 主要解决流程封装与工具接入，不直接提高检测的 soundness 或 completeness。一个错误的审计流程被 Skill 固化后，只会更稳定地制造错误；接入更多 MCP 还会扩大权限、供应链和提示注入风险。

它们应被定位为可版本化的执行协议和适配层。平台护城河不在 Skill 数量，而在经过评测的组织语义、上下文编译器、验证器、证据数据和真实反馈闭环。

2.7 反驳：“RAG 能解决上下文和知识不足”

RAG 只能让某些材料更容易被取到，不能保证取到的是完成安全判断所需的材料。代码审计更需要的是任务相关的程序切片：调用者、被调用者、权限路径、数据约束、配置、部署条件和修复历史。

相似代码或相似 CVE 还可能诱导模型套用错误模式。RAG 应服务于“上下文编译”，而不是成为独立卖点。

2.8 反驳：“从五类 CWE 和 50 个修复对开始即可证明 MVP”

50 个修复对可以验证数据格式、工具接入和回归流水线，不能可靠估计生产 precision、recall 或跨项目泛化。修复对还可能泄露补丁线索，模型学会比较 diff，却不会在未知仓库中发现漏洞。

起点不应由容易收集的 CWE 决定，而应由一个明确决策场景决定。例如：

• 对 Java/Spring 的现有 CodeQL 告警做分诊；
• 对某类框架补全 source/sink/sanitizer 规格；
• 对单个业务域的 PR 做授权不变量检查；
• 对高价值仓库做夜间开放式漏洞狩猎。

这四种任务需要不同数据、指标和工作流。

2.9 反驳：“评测金字塔代表能力逐级提升”

片段识别、函数分类、仓库发现、PoC、修复和在线运营不是一个单调阶梯。某系统可能很会复现已知漏洞，却不擅长发现；也可能擅长生成候选，却不会修复。

应把它们设计成相互独立的测试套件，禁止用低层分数推断高层能力。

2.10 反驳：“Precision、Recall、F1、PR-AUC 足以说明效果”

这些指标仍然没有完整表达生产价值：

• 开放世界审计没有完整的漏报分母，所谓 recall 往往只是“已知漏洞召回”。
• PR-AUC 会受样本构造和 prevalence 影响，不能直接代表分析师工作负荷。
• F1 默认同等看待误报和漏报，不符合不同严重度与场景的成本。
• 同一漏洞可能产生十条重复告警，告警级 precision 会失真。
• 模型可以大量弃权来提高 precision，因此必须同时报告 coverage。

生产评测应增加：已验证发现/分析师小时、每个仓库的有效发现量、审查队列长度、弃权率、证据完整率、覆盖清单、成本/真阳性、修复接受率和后续逃逸漏洞。

2.11 反驳：“时间切分和项目隔离足以防止污染”

模型训练数据和检索来源通常不可见，公开 CVE 即使在时间切分之后也可能以镜像、讨论、补丁或派生代码形式泄漏。项目隔离也不能消除框架模板和复制代码的近重复。

更可信的最终测试必须包含未公开内部漏洞、真正未来发生的提交、私有变换样本和前瞻性 shadow 运行。公开集适合回归，不适合独自决定上线。

2.12 反驳：“人工复核会兜住模型错误”

人工复核不是免费的真值层。流畅报告会诱发自动化偏见和确认偏差；审查者可能只验证模型提供的路径而不搜索遗漏路径。若没有盲化、统一标注规范、第二审查者和分歧处理，Human-in-the-loop 只是把风险转移给人。

2.13 反驳：“把业务不变量交给 LLM 抽取即可审计逻辑漏洞”

代码、文档和测试记录的是当前实现，不一定记录正确业务规则。让 LLM 从实现反推不变量，可能把缺陷本身当作设计。

业务不变量必须有权威来源和责任人：产品规则、合规要求、威胁模型、数据所有者或人工确认。LLM 可以提出候选不变量，但不能自行宣布其为安全真值。

2.14 反驳：“严重度和置信度可以由报告 Agent 生成”

模型口头给出的 0.9 置信度通常没有校准意义；CVSS 也不能替代部署环境、资产价值和攻击前置条件。严重度、技术可信度和业务优先级必须拆开：

• 技术可信度：证据是否支持漏洞声明；
• 可利用性：攻击前置条件在目标环境是否成立；
• 影响：受影响资产和权限边界；
• 业务优先级：组织的暴露、补偿控制和修复成本。

2.15 反驳：“平台模块越全，平台越完善”

15 个模块的清单很容易演变成长期基础设施工程，却没有证明任何安全收益。多语言、统一 CPG、模型路由、Skill 市场和自动 PoC 都可能在产品价值尚未成立前消耗团队。

完善不等于功能多。完善意味着：边界清楚、证据可靠、失败可见、指标稳定、升级可回归、输出能被修复团队消费。

3. 重新定义问题：不是一个“代码审计任务”

必须先选择运行模式，因为不同模式的目标函数互相冲突。

建议首个生产切入点选择“SAST 告警分诊与证据补全”。它的输入和分母比较明确，能够与现有流程做盲测，也不会让 LLM 一开始承担开放世界召回责任。

同时可以保留一条研究线：针对一个框架和一个污点类漏洞，验证 LLM 生成/补全规格是否真的带来增量召回。两条线必须独立计分。

4. 新方法论：以安全声明和证据为中心

4.1 每条发现首先是一项可证伪声明

一条合格的发现不是“这里可能有 SSRF”，而是：

在版本 V 和配置 C 下，攻击者 A 能控制输入 S；
该输入沿路径 P 到达敏感操作 K；
路径上的约束 G 不足以阻断攻击；
因此资产 X 会受到影响 I；
目前证据为 E，反证为 N，仍未知的条件为 U。

所有 Agent、工具和人工都围绕这个声明提供支持、反证或“不知道”。模型不得把缺失字段用合理猜测补齐。

4.2 建立证据账本，而不是聊天记录

平台的最小数据模型应包含：

• claim_id：稳定的漏洞声明标识；
• scope：仓库、commit、构建、配置和部署假设；
• attacker_precondition：攻击者需要的身份、网络和已有权限；
• source/path/sink：带文件、行、符号和版本；
• supporting_evidence：工具结果、查询、测试、运行日志、文档；
• counter_evidence：guard、sanitizer、不可达、补偿控制；
• coverage_gaps：未构建模块、未解析语言、超时路径；
• validation_state：假设、已支持、已反证、已复现、人工确认；
• provenance：模型、提示、Skill、规则、工具和环境版本；
• decision：接受、抑制、修复、延期及其理由。

自然语言报告只是证据账本的一种视图，不是平台真相源。

4.3 使用证据阶梯

| 等级 | 含义 | 可做的决定 | | — | — | — | | E0 | 只有模型模式匹配或安全直觉 | 仅保留研究假设 | | E1 | 有准确文件/行/API 与攻击前置条件 | 进入人工初筛 | | E2 | 调用、控制或数据路径由工具/人工确认 | 可作为有根据候选 | | E3 | 已检查 guard、sanitizer、配置和反证 | 可进入高优先级验证 | | E4 | 查询、差分测试、单元/集成测试或形式化条件支持 | 可进入修复流程 | | E5 | 在代表性环境复现，或获得同等强度的证明 | 可确认技术漏洞 |

证据等级与业务严重度正交。一个潜在影响很大的 E1 候选仍是低证据；一个 E5 的低影响漏洞也不应被夸大。

4.4 把系统拆成“事实平面、推理平面、决策平面”

代码、构建、配置、文档、历史

事实平面：解析、索引、SAST、依赖、运行观测

上下文编译器：按安全声明生成最小充分证据包

推理平面：LLM 提出假设、解释路径、寻找反证、生成验证方案

验证平面：查询、测试、PoC、fuzz、人工核验

证据账本

决策平面：优先级、阻断、修复、抑制

评测与运营反馈

事实平面也必须报告置信边界；推理平面没有直接生产权限；决策平面由显式政策控制，不能由模型自由决定。

4.5 让 LLM 只做它有增量价值的工作

适合 LLM 的任务：

• 从路由、模型、策略和代码中提出攻击面候选；
• 补全框架特定的 source/sink/sanitizer 候选；
• 将多文件路径转成可审查的安全声明；
• 识别授权、租户、状态机中的语义不一致；
• 主动寻找反证和缺失条件；
• 生成最小测试、查询或验证计划；
• 聚类重复告警并解释修复影响。

不应交给 LLM 独立完成的任务：

• 声称完整遍历所有路径；
• 把模型自信度当作漏洞概率；
• 自行定义正确业务规则；
• 无政策地执行仓库脚本、联网或读取凭据；
• 仅凭文本决定自动阻断；
• 把生成成功的 PoC 当作最终严重度。

4.6 用受约束状态机代替开放式 Agent

每个任务应有明确的：输入范围、允许工具、证据要求、预算、停止条件、失败状态和未覆盖清单。建议状态如下：

Scope
→ Build/Index
→ GenerateClaim
→ CollectEvidence
→ SeekCounterEvidence
→ SelectVerifier
→ Validate or Abstain
→ HumanDecision
→ Regression

“预算耗尽”“构建失败”“无法解析反射”“缺少生产配置”必须成为一等结果，不能被模型总结成“未发现漏洞”。

5. 正确的评测方法

5.1 先定义评测单位

至少区分：

• 漏洞：同一根因跨多个文件只算一个；
• 声明：一条可证伪的攻击结论；
• 告警：系统输出给审查者的工作项；
• 仓库/PR：真实运营单位；
• 路径：用于验证的技术证据。

禁止把十条重复告警当成十次真阳性，也禁止用文件命中替代漏洞命中。

5.2 建立四类互补数据，而不是单一金标集

1. 能力诊断集：小型、可控，用于测试解析、定位、结构化输出和特定语义。
2. 历史回放集：完整漏洞引入前后的仓库，用于已知漏洞召回和修复对一致性。
3. 困难负例集：真实 guard、sanitizer、不可达、测试代码、生成代码和相似但安全的实现。
4. 前瞻性隐藏集：未公开内部漏洞、未来提交和 shadow 期间后来确认的问题，用于最终决策。

合成漏洞和 Juliet/SARD 适合能力诊断，不应用于估算生产 precision。公开 CVE 适合回归，不应作为唯一上线依据。

5.3 金标必须有证据和分歧处理

每个样本至少记录：

• 漏洞声明与适用环境；
• 根因、入口、路径、影响和修复；
• 负例为什么安全；
• 标签来源和标注者；
• 两名审查者是否一致；
• 分歧如何裁决；
• 是否可以动态复现；
• 数据谱系、公开时间和去重指纹。

用户抑制告警不能直接标为 false positive。抑制可能意味着重复、风险接受、非生产代码、补偿控制、修复成本过高或真正误报，这些标签对模型学习含义完全不同。

5.4 做增量消融，而不是只比较最终平台

对同一批样本和相同预算比较：

任何新 Agent、RAG、CPG、Skill、模型或微调都应通过同样的增量消融证明价值。没有增益的组件应删除，而不是因为架构图完整而保留。

5.5 指标分四组报告

检测质量

• 漏洞级 precision、已知漏洞 recall 和 precision-recall/workload 曲线；
• 修复对一致性、困难负例通过率、重复告警率；
• 按 CWE、语言、框架、路径长度和项目分层结果；
• 95% 置信区间，而不只给点估计。

证据质量

• 文件/行/符号准确率；
• 路径可重放率；
• 反证检查完整率；
• E0–E5 证据等级分布；
• 生产配置适用性和人工复核一致率。

运营价值

• 经验证发现/分析师小时；
• 人工分钟/真阳性；
• 每仓库告警和队列积压；
• 修复接受率、修复时长和撤回率；
• token、计算、构建、存储及人工总成本/真阳性。

可靠性与覆盖

• 重复运行一致性；
• 构建、解析、工具、超时和模型失败率；
• 弃权率与 coverage-risk 曲线；
• 未扫描文件、语言、服务和动态路径；
• 模型/规则升级后的回归退化。

5.6 50 个样本只是烟雾测试

样本量应由需要估计的指标精度决定。例如，若观测 precision 约为 80%，希望 95% 置信区间半宽约为 5%，在简单独立近似下需要约 246 条经过裁决的系统告警；仓库内样本相关时还需要更多，并应采用按仓库聚类的区间估计。

这不是统一的固定门槛，而是在提醒：20–50 个修复对只能发现流程错误，不能支持“生产可用”或“误报降低多少”的宣传。

5.7 开放世界 recall 必须诚实命名

现实仓库中不存在完整的“所有未知漏洞”标签，所以不能宣称全局 recall。可以分别报告：

• 对历史已知漏洞的 recall；
• 对人工种植或变异漏洞的 recall；
• 对专家限定范围审计发现的 recall；
• shadow 期内对后来确认漏洞的前瞻命中；
• 与多个独立检测渠道的新增交集和独有发现。

“未发现”只表示在已报告覆盖、预算和工具条件下没有得到达到门槛的声明。

5.8 上线评测应按三个关口推进

1. 离线关口：隐藏集、困难负例、消融、稳定性和安全边界通过。
2. Shadow 关口：不阻断真实开发；盲化比较现有流程与新系统的人工时间和有效发现。
3. 受控决策关口：只对证据门槛明确、历史表现稳定、可以快速回滚的少数类型启用自动动作。

自动阻断不应只看模型历史 precision。它还需要确定性、影响范围、失败模式、业务容忍度、回滚能力和申诉机制。

6. 从哪里开始建设

阶段 A：选择唯一的首要决策场景（1–2 周）

推荐首选：对一个组织内 Java/Spring 或 Python Web 栈的既有 SAST 高风险告警做分诊、补上下文和证据化。

需要明确：

• 谁消费结果；
• 每天能处理多少告警；
• 哪些资产和攻击者最重要；
• 哪些误报最浪费时间；
• 哪些漏报不可接受；
• 平台只能读什么、可以执行什么。

产物不是大平台架构，而是一个任务契约、威胁模型、基线指标和发现 schema。

阶段 B：建立证据账本与真实基线（2–4 周）

• 采样真实历史告警和处置结果；
• 重新区分真漏洞、重复、不可达、非生产、风险接受和证据不足；
• 由两名审查者对关键样本盲化裁决；
• 记录现有流程的人工时间、队列、接受率和漏检案例；
• 用 20–50 个样本打通流水线，但不作效果宣传。

阶段 C：实现最小闭环（4–8 周）

最小闭环只需要：

1. 仓库和构建状态采集；
2. SAST 告警及相关程序切片；
3. 上下文编译器；
4. LLM 生成结构化声明和反证清单；
5. 一到两个确定性验证器；
6. 证据账本和人工裁决界面；
7. 离线回归 harness。

暂时不需要多 Agent 市场、通用多语言 CPG、自研基础模型或全自动 PoC。

阶段 D：做盲化增量实验（4–6 周）

• 在相同告警预算下比较 B0–B4；
• 让审查者不知道结果来自哪个版本；
• 报告分层指标、置信区间和失败案例；
• 专门检查系统是否错误抑制高危真阳性；
• 记录构建失败、超时和长尾成本。

只有在真实人工工作量或有效发现上产生稳定增益，才进入 shadow。

阶段 E：Shadow 与前瞻性验证（至少一个完整开发周期）

• 不阻断生产；
• 维护隐藏的未来样本；
• 对新确认漏洞回看系统当时是否命中；
• 跟踪模型漂移、框架升级和规则退化；
• 对高价值独有发现进行专家复盘。

阶段 F：逐任务扩展

扩展顺序由缺口数据决定，而不是按技术热度决定：

• 如果告警缺上下文，投资上下文编译和框架模型；
• 如果新漏洞召回不足，试验规格生成或新的候选通道；
• 如果证据不足，增加查询、测试或运行验证；
• 如果人工瓶颈在重复告警，优先聚类和根因合并；
• 如果业务逻辑是主要风险，先建立权威不变量库和责任人流程；
• 只有稳定任务积累了高质量数据，才评估微调或小模型蒸馏。

7. 平台应该建设的真正资产

优先自建和长期积累：

1. 组织威胁模型与资产语义：什么数据、身份和边界最重要。
2. 权威业务不变量：角色、租户、资源、状态、金额、配额和生命周期规则。
3. 上下文编译器：把程序、配置、历史和运行事实组合成最小充分证据包。
4. 证据账本：支持、反证、覆盖缺口、版本和最终裁决。
5. 困难负例与隐藏评测集：尤其是真实 guard、sanitizer 和不可达案例。
6. 验证器资产：查询、测试、PoC harness、框架语义和安全回归。
7. 人工裁决数据：保留处置原因，避免把所有 suppress 都当误报。
8. 持续评测系统：模型、规则、Skill、工具和索引变化都能回归。

优先复用而不是重造：解析器、编译器、SAST、SCA、secret scanner、通用 CPG、容器调度和模型网关。除非实验已经证明这些通用组件是主要瓶颈。

8. 平台自身安全必须先于自动执行

被审计仓库是恶意输入。README、注释、测试、构建脚本、依赖和生成文件都可能攻击 Agent 或执行环境。

最小安全边界：

• 控制平面与不可信分析平面隔离；
• 模型没有直接凭据、网络和生产写权限；
• 默认只读源码、无密钥、限制出网；
• 构建和测试在一次性沙箱中运行，资源和系统调用受限；
• 工具调用经过策略引擎，参数结构化，不执行模型拼接的任意 shell；
• 仓库文本永远作为不可信数据，不能覆盖系统政策；
• 第三方 Skill/MCP 固定版本、审查来源、最小权限并有回归测试；
• 模型输入输出、工具调用、文件访问和网络请求完整留痕；
• PoC 只允许非破坏性目标和授权环境；
• 任何自动修复、提交、工单或阻断都是独立授权动作。

如果平台不能安全地处理恶意仓库，它不适合承担代码安全审计。

9. 做好 LLM 代码审计的十条原则

1. 先选安全决策，再选模型和工具。
2. 把漏洞写成可证伪声明，不接受泛泛风险描述。
3. 所有输出都是带来源和局限的证据，不把任何单一工具当真值。
4. 发现、分诊、验证、修复和阻断分别建数据集、指标和门槛。
5. 用 LLM 处理语义和不确定性，用确定性机制处理遍历、解析、约束和执行。
6. 反证优先，并允许系统弃权；证据不足不等于安全。
7. 公开基准用于回归，隐藏时间外数据和前瞻性 shadow 才决定上线。
8. 优化经验证发现/分析师小时，而不是告警数、模型自信度或演示案例。
9. 每个新组件都做消融；不能证明增益的 RAG、Agent、Skill 或 CPG 就删除。
10. 把平台自己当作高风险供应链和代码执行系统来防护。

10. 最终建议

如果现在就开始，不应先做“完善的万能 LLM 代码审计平台”。应先做一个可验证的窄闭环：

一个语言/框架
+ 一个明确决策场景
+ 一套真实历史告警和困难负例
+ 一个证据账本
+ 一个上下文编译器
+ 一个 LLM 语义分诊器
+ 一到两个独立验证器
+ 盲化人工裁决
+ 离线回归与 shadow 评测

首个推荐场景是“SAST 告警分诊和证据补全”，不是因为它代表最终愿景，而是因为它最容易建立真实分母、基线和人工成本对照。确认方法有效后，再扩展到框架规格生成、仓库级未知漏洞狩猎、业务不变量审计和自动修复。

一个真正成熟的平台应当能够清楚回答四个问题：

1. 这条漏洞声明由哪些独立证据支持，又有哪些反证？
2. 哪些代码、配置和执行路径实际没有被覆盖？
3. 相比原流程，它增加了多少经验证发现，节省了多少人工，又引入了什么风险？
4. 更换模型、规则、Skill 或工具后，这些结论是否仍然成立？

答不出这四个问题的平台，即使能生成漂亮报告、调用很多工具、拥有多个 Agent，也还只是一个代码安全演示系统。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Purpleroc的札记 Purpleroc Purpleroc《LLM 代码审计方法论：反思、反驳与重构》