文章总结： 本文提出ESAA-Security架构，旨在解决AI生成代码安全审计缺乏治理与可追溯性问题。该架构融合事件溯源与CQRS范式，将审查转化为受约束、可重放验证的证据导向流程，定义了四阶段工作流及六条核心不变量确保状态一致性。研究覆盖16个安全领域与95项检查，建立了基于证据链而非模型意见的信任体系。该方案重新定义了AI时代软件安全审计标准，显著提升了审计结果的可靠性与可操作性。 综合评分： 85 文章分类： AI安全,代码审计,安全建设,应用安全

【论文速读】| ESAA-安全：一种面向 AI 生成代码智能体辅助安全审计的事件溯源、可验证架构

原创

知识分享者 知识分享者

安全极客

2026年3月10日 17:35 北京

基本信息

原文标题：ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code

原文作者：Elzo Brito dos Santos Filho

作者单位：[email protected]（巴西圣保罗州）

关键词：事件溯源、智能体安全审计、AI 生成代码、ESAA、安全治理、可重放验证

原文链接：https://arxiv.org/abs/2603.06365

开源代码：https://github.com/elzobrito/ESAA-Security

论文要点

论文简介：随着 AI 辅助软件生成工具的普及，开发速度大幅提升，但一个长期被忽视的工程问题随之被放大——功能上看似正确的系统，在结构层面往往存在严重的安全隐患。传统的 prompt-based安全审查依赖大语言模型（LLM）进行开放式对话，这种方式在实践中暴露出覆盖范围参差不齐、审查结果难以重现、发现依据不充分、以及缺乏不可篡改审计轨迹等问题。本文提出的 ESAA-Security正是针对上述治理困境而设计的领域专属解决方案，它将安全审查从一次”自由对话”转化为一个有治理约束、可重放验证的证据导向审计流程，适用于对软件代码仓库（尤其是 AI 生成或 AI 改写的代码）进行系统性安全审计。

研究目的：本研究的核心目标在于解决 AI 时代软件安全审计中的治理空缺。当 LLM 驱动的智能体开始参与代码生成与修改，原有的安全审查模式——依赖人工prompt、凭借模型生成散文式报告——已无法提供足够的结构性保证。研究者希望通过将事件溯源（Event Sourcing）与 CQRS架构范式引入安全审计领域，建立一套以”证据链”而非”模型意见”为信任基础的审计体系，使安全发现能够被精确追溯、独立验证，并在整个审计生命周期内保持状态一致性与可重放性。

研究贡献：

第一，作者将 ESAA-Security 定义为 ESAA 架构的领域专属化扩展，为 AI生成代码的软件仓库提供证据导向的安全审计能力。

第二，文章定义了一套有治理约束的审计流水线，将受约束的智能体输出、仅追加事件持久化、确定性重投影与重放验证融合为一个统一执行模型。

第三，研究将安全审查操作化为四个阶段、26个任务、16 个安全领域与 95 项可执行检查的结构化工作流，并能够产出从检查级发现到最终风险导向报告的完整制品链。

第四，文章提出了一套全新的评估框架，将评估维度从单纯的漏洞数量扩展到可追溯性、可重放性、覆盖显式性、制品完整性和修复有效性等多个复合指标。

背景与相关工作

理解 ESAA-Security 的意义，需要先理解它所处的技术背景。近年来，以 LLM 为核心的软件工程范式正经历从”孤立辅助”向”自主工作流”的根本性跨越。ReAct、AutoGen、MetaGPT等研究相继证明，语言模型已经可以进行推理、调用工具、浏览代码仓库并参与多智能体协作执行。然而，这种能力的跃升同时暴露了一个结构性治理缺口：软件工作需要在文件、任务与状态迁移之间保持长时间、跨步骤的一致性，而语言模型本质上是在上下文约束下运作的概率生成器，并不具备原生的状态保持能力。一旦智能体在长时执行场景下出现关键信息被”遗忘”或指令被降级处理的情况，整个工作流的可靠性就会崩解。

在结构化输出与状态可追溯性方面，现代 LLM 系统已经越来越多地依赖 schema 约束输出来减少解析歧义，语法约束解码和 schema感知生成显著提升了下游可靠性。但这些方法只解决了单步输出的结构问题，并未定义多步工作流中状态应如何演化。ESAA架构在这一基础上更进一步：它要求智能体发出经过契约验证的结构化意图，由确定性编排器执行状态变更，而非允许模型直接修改系统状态。

在安全领域的特定背景下，ESAA-Security 的实质性覆盖范围与 OWASP Top 10 和 OWASP 应用安全验证标准（ASVS）高度对齐，这使框架的领域覆盖有了公认的安全风险族和验证类别作为锚点，而非依赖临时的 prompt

措辞。特别值得关注的是，ESAA-Security 还额外引入了 AI/LLM 安全领域的专属检查，以应对传统 AppSec 框架在代码仓库层面往往未被前置考虑的新型风险。在”vibe coding”（直觉驱动编程）盛行的当下，模型生成的代码在认证、授权、输入验证、密钥处理、会话控制、依赖卫生、基础设施加固等方面暴露的系统性缺陷，正是本框架重点关注的对象。

ESAA-Security 架构设计

ESAA-Security 的设计目标极为明确：将安全审查从开放式 prompt交互转变为一个状态显式、可重放、可审计的治理工作流。整个架构由五个协作层次组成，分别是审计路线图（roadmap）、安全剧本（playbooks）、智能体与编排器契约（contracts）、仅追加事件存储（eventstore），以及投影只读模型（projected read-models）。这五层通过代码仓库中的目录结构显式呈现，路线图、契约、运行时策略、剧本和按阶段组织的 reports/ 层级共同构成可操作的架构实体。

整个审计工作流被划分为四个阶段。第一阶段是侦察（Reconnaissance），负责识别技术栈、架构结构、数据流向与攻击面。第二阶段是领域审计执行（Domain Audit Execution），按照剧本对代码仓库进行驱动式审查，每个安全领域对应一个任务单元。第三阶段是风险分类（Risk Classification），将各领域发现整合为漏洞清单、严重性分级和风险矩阵。第四阶段是最终报告（Final Reporting），生成技术修复建议、最佳实践指南、执行摘要和最终审计报告。

这套架构中最重要的设计原则是”覆盖显式化”。ESAA-Security 定义了 16 个安全领域，涵盖密钥与配置管理、认证与授权、输入验证、依赖与供应链、API 安全、文件上传、密码学、AI/LLM 安全，以及 DevSecOps 等。整个框架共包含 95项可执行检查，分布在四个阶段的 26 个任务中。这种编码式覆盖是该架构与纯 prompt 审查的核心区别所在——它明确约束了系统预期检查的范围，而不是依赖模型的临时召回能力。

编排器的角色始终保持核心地位。智能体不能直接修改审计状态，它们只能在显式契约约束下发出结构化意图，这些意图在任何效果被持久化之前必须经过验证。经验证接受的输出被追加到事件存储中，投影为当前状态视图，并通过重放和哈希校验完整性。最终报告因此不是一个从头叙述的自由体叙事，而是一系列有效状态迁移序列的终端产物。

执行协议与审计不变量

ESAA-Security 的执行协议由一套严格的审计不变量体系支撑，确保审计进度不是从模型散文中推断，而是从经过验证的可接受状态迁移序列中确定。当前协议采用”每任务两步”的执行纪律：每个任务必须先被认领（claim），完成工作后才能带着验证证据和制品写入完成（complete）。

框架定义了六条核心不变量。第一条是”先认领后工作”——任务处于待办状态时，唯一允许的操作是认领；实质性工作和文件更新在此阶段被明确禁止。第二条是”工作完成后才标记完成”——只有当任务处于进行中状态且分配给同一执行者时，智能体才能发出完成信号，并附上验证检查和边界内的文件更新。第三条是”状态一致性先验”——智能体必须复述其认为自己所处的状态，允许编排器在任何追加操作发生之前拒绝过期上下文或越阶段执行尝试。第四条是”锁所有权”——只有当前任务的持有者才能完成该任务。第五条是”边界纪律”——制品写入仅允许在 complete 操作下，且只能在当前任务类型的可接受边界范围内进行。第六条是”完成不可变性”——一旦任务进入终态，不得被静默重新打开，修正必须通过显式的 issue 或 hotfix流程路由。这六条不变量共同将审计轨迹构建为一个受治理的状态机，而非无约束的文本主张序列。

验证模型采用显式的”失败关闭”策略：无效的状态迁移、schema违规、边界越界、状态不匹配，或将多个动作合并为单一发射的尝试，都会在影响状态之前被拒绝。基于重放的验证则充当最终完整性层，确保投影的审计状态能够仅从已接受的事件中重建出来。

审计输出与风险导向报告

ESAA-Security 的输出模型按阶段分类并具有累积特性。第二阶段产出领域叙述和结构化检查结果；第三阶段产出漏洞清单、经分类的漏洞条目和风险矩阵；第四阶段产出技术修复方案、最佳实践指南和执行摘要；最终产物是人类可读的Markdown 最终报告和结构化的 JSON 报告。

在输出体系的最底层，检查级发现是结构化证据对象，而非自由叙述式声明。每个发现需要绑定检查标识符、状态、严重性等级、代码或配置证据、技术解释以及修复指南。这一设计既有认知层面的意义（约束什么算作有效的审计观察），也有操作层面的价值（使下游整合成为可能）。

漏洞清单层将领域局部发现转化为系统级安全状态。ESAA-Security 使用 CRITICAL、HIGH、MEDIUM、LOW 和 INFO 五个等级进行严重性分类，并结合CIA（机密性、完整性、可用性）三维影响推理。风险矩阵则按严重性、影响程度和修复优先级对发现进行排序，成为从分析到行动的核心枢纽。

推荐层包含两类产出：技术修复方案为高优先级问题提供具体的工程指导；最佳实践产出则按领域组织常见教训和加固建议。执行摘要将整个审计压缩为一个决策导向制品，包含 0 到 100 的安全评分和最高优先级风险列表。这一报告级联结构是ESAA-Security 与 prompt-only 审查最显著的区别之一：在自由 prompt 审查中，模型的叙述往往被直接当作审计产物本身；而在 ESAA-Security中，叙述是证据与状态的下游投影，最终报告的权威性仅取决于它是否忠实地投影了已接受的事件序列。

评估设计与研究问题

本文提出了三个核心研究问题，方向清晰地指向架构贡献而非单纯的漏洞发现能力。研究问题一（RQ1）询问：事件溯源执行模型能否使智能体辅助的安全审计在发现、分类和最终报告层面实现重放可验证性与可追溯性？研究问题二（RQ2）询问：安全审查能否被操作化为一个具有显式领域覆盖、检查级证据和风险导向输出的结构化审计过程，而非自由的 prompt 活动？研究问题三（RQ3）询问：ESAA-Security 能否产出对 AI生成软件的优先级排序和修复有实际帮助的制品，包括严重性分级、风险矩阵、技术修复方案和执行报告？

评估应至少覆盖五个维度：协议合规性、重放可验证状态完整性、覆盖完整性、制品完整性和风险报告有效性。这一设计比仅统计发现数量更能客观反映框架的真实价值。一个能产出大量无溯源、无结构修复建议的投机性发现的系统，未必比一个发现较少但输出完全可重放、有证据支撑、导向决策的系统更强。初步验证建议使用至少两个规模和复杂度不同的代码仓库进行案例研究，其中至少一个应以 AI 生成为主，以匹配框架的核心应用场景。

局限性与讨论

尽管架构设计清晰严谨，论文作者在讨论部分诚实地指出了框架当前版本的若干局限。第一个局限是对剧本质量的依赖：安全领域的实质性逻辑编码在剧本和检查中，弱质量的剧本可能产出治理完善但实质薄弱的审计结果。第二个局限是对仓库上下文的依赖：如果基础设施细节、部署配置或操作上下文缺失，审计可能在协议层面有效但在内容层面严重不足。第三个局限是语义模型错误：结构化输出减少了结构缺口，但并不能消除对框架约定、补偿控制或可利用性的误解。

在有效性威胁方面，内部有效性的威胁在于早期案例研究可能将协议成功与实质性审计质量相混淆。外部有效性的威胁在于仓库多样性：来自少数结构良好仓库的结果可能不能推广到大型单体仓库或文档匮乏的生产系统。构建有效性的威胁则指向评估焦点的偏移风险：若只衡量发现数量，噪音更大的基线可能看起来更强；若只衡量协议整洁性，框架可能在没有展示实质安全价值的情况下显得出色。因此，正确的评估构建应是复合指标：治理审计质量必须同时包含可追溯性、可重放性、覆盖显式性、制品完整性和修复有效性。

结论

ESAA-Security 的核心贡献并非又一份漏洞检查清单，而是对 AI 辅助安全审计应当是什么的一种根本性重新定义：它必须在范围上明确，在证据上结构化，在执行上受约束，在最终状态上可验证。这是针对 AI生成软件兴起这一时代背景的一次及时且在技术层面具有实质意义的架构转变。论文展示了一个完整的四阶段、26 任务、16 安全领域、95项检查的操作化模型，通过将信任单元从自由形式的模型意见转变为协议有效、可重放验证的审计状态，从根本上重构了 AI 时代软件安全审计的可信度基础。未来工作将沿路线图进一步推进，包括 CVSS集成、混合动态应用安全测试（DAST）、多仓库审计、合规映射与跨审计运行的时序对比等能力扩展。

-End-

免责声明：

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

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

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

本文转载自：安全极客 知识分享者 知识分享者《【论文速读】| ESAA-安全：一种面向 AI 生成代码智能体辅助安全审计的事件溯源、可验证架构》