elzobrito/ESAA-Security
GitHub: elzobrito/ESAA-Security
基于事件溯源的LLM智能体自动化安全审计框架，通过结构化剧本驱动覆盖16个安全领域并生成可验证的审计报告。
Stars: 168 | Forks: 17
# ESAA-Security — 基于事件溯源的自主安全审计
ESAA-Security 是 [ESAA 架构](https://github.com/elzobrito/ESAA---Event-Sourcing-Agent-Architecture) 在安全审计领域的专业化扩展，专门用于软件仓库的自动化安全审计，特别关注 AI 生成或 AI 修改的代码。其治理方法论——将启发式智能体认知与确定性状态变更分离，通过仅追加事件、边界契约、约束结构化输出和基于重放的验证——源自 ESAA 本身。ESAA-Security 继承这一核心，并围绕安全证据、以剧本驱动的领域覆盖和风险导向的报告重新定义了工件空间。每个发现、分类和修复都被记录为一条事实——最终报告是审计轨迹的确定性投影。
📄 **ESAA 论文：** [ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering](https://arxiv.org/abs/2602.23193) — 治理核心：事件溯源、确定性编排、边界契约、重放验证
🔒 **ESAA-Security 论文：** [ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code](https://arxiv.org/abs/2603.06365) — 领域专业化：审计阶段、安全剧本、风险导向输出
🧩 **PARCER 论文：** [PARCER as an Operational Contract to Reduce Variance, Cost, and Risk in LLM Systems](https://arxiv.org/abs/2603.00856) — 运营契约：决策规范、自适应预算、结构化验证
🛡️ **源框架：** [PARCER v1.6.0 Security Auditor](docs/PARCER_v1.6.0-security-audit.yaml)
## 为什么选择 ESAA-Security？
由 LLM 智能体执行的安全审计继承了自主智能体的所有结构性问题——再加上领域特定的风险：
| 问题 | ESAA-Security 的解决方案 |
|---|---|
| **虚构的漏洞** — 智能体编造不存在的发现 | 护栏要求每个发现都必须有技术证据；剧本定义客观的通过/失败标准 |
| **覆盖不一致** — 智能体任意跳过领域或检查 | 16 个领域、95 个可执行检查，具有依赖顺序执行 |
| **无审计轨迹** — 无法验证实际测试了什么 | 每个检查结果都是仅追加日志中的事件；报告是可验证的投影 |
| **结果不可复现** — 同一系统每次运行产生不同的发现 | 确定性重放 + SHA-256 验证；相同事件始终产生相同报告 |
与临时性的"让 LLM 审查我的代码"方法不同，ESAA-Security 提供**结构化剧本**、**模式验证结果**和**从发现到证据的取证追溯**。
### 架构传承
ESAA-Security 构建在三个不同的层之上，每层都有各自的论文和贡献：
| 层 | 贡献 | 论文 |
|---|---|---|
| **ESAA**（治理核心） | 方法论：以仅追加事件存储为真相来源，验证并持久化智能体意图的确定性编排器，按任务类型划分的边界契约，SHA-256 重放验证，"完成"的不可变性，用于上下文注入的净化视图。通过异构多智能体编排（Claude Sonnet 4.6、Codex GPT-5、Gemini 3 Pro、Claude Opus 4.6）验证。 | [arXiv:2602.23193](https://arxiv.org/abs/2602.23193) |
| **PARCER**（运营契约） | 智能体级治理：声明式 YAML 契约，强制执行决策规范（7 个程序）、自适应代币预算、上下文回退（Map-Reduce/RAG）、带硬门的结构化验证，以及 OpenTelemetry 可观测性。PARCER 配置文件（`PARCER_PROFILE.agent-spec.yaml`、`agent-impl.yaml`、`agent-qa.yaml`）将每个智能体角色绑定到其工具预算、验证要求和升级规则。 | [arXiv:2603.00856](https://arxiv.org/abs/2603.00856) |
| **ESAA-Security**（领域专业化） | 安全审计管道：4 个阶段（侦察 → 领域审计 → 风险分类 → 报告），26 个任务，16 个安全领域，95 个可执行检查，带严重性分类的结构化发现、风险矩阵、修复指导和执行报告。最终报告不是自由形式的叙述——而是受治理审计状态的投影。 | [arXiv:2603.06365](https://arxiv.org/abs/2603.06365) |
关键洞察是，安全审查不应被建模为提示问题，而应被视为**受治理的执行问题**。ESAA 提供机制（状态如何演变）。PARCER 提供智能体纪律（智能体如何行为）。ESAA-Security 提供领域语义（审计什么以及如何结构化发现）。
## 架构
```
┌─────────────┐ check_result ┌──────────────────┐ append event ┌─────────────┐
│ Audit Agent │ ───────────────► │ Orchestrator │ ─────────────► │ Event Store │
│ (finding) │ │ (deterministic) │ │ (.jsonl) │
└─────────────┘ ◄─────────────── └──────────────────┘ └──────┬──────┘
▲ output.rejected │ │
│ │ project
│ ┌──────────────┐ │ │
│ │ Playbook │ │ ▼
│ │ + Contract │ ┌────┴─────────┐ ┌──────────────┐
│ └──────────────┘ │ JSON Schema │ │ Read-Model │
│ │ Validation │ │ (.json) │
│ └──────────────┘ └──────┬───────┘
│ │
└──────────────────── purified view ────────────────────────────────┘
```
**核心原则（继承自 ESAA）：** 智能体调查，编排器裁决。
- **智能体**执行剧本检查并发出结构化结果（`agent_result`、`issue.report`）——它们**不能**编写报告、变更状态或直接追加事件。
- **编排器**根据 JSON Schema + 边界契约验证结果，持久化事件，并投影读取模型。
- **事件存储**（`activity.jsonl`）将每个检查执行、发现和分类记录为不可变的事实。
- **读取模型**（`roadmap.json`）跟踪审计进度——哪些检查通过、哪些失败、哪些领域已完成。
## 安全领域
ESAA-Security 覆盖 16 个安全领域，源自 PARCER Security Auditor 框架：
| 领域 | 检查数 | 优先级 | 剧本 ID |
|---|---|---|---|
| 密钥与配置 | 8 | 关键 | SC-001 → SC-008 |
| 身份验证 | 8 | 关键 | AU-001 → AU-008 |
| 授权 | 6 | 关键 | AZ-001 → AZ-006 |
| 输入验证 | 7 | 关键 | IV-001 → IV-007 |
| 数据安全 | 5 | 关键 | DA-001 → DA-005 |
| 依赖项与供应链 | 6 | 高 | DS-001 → DS-006 |
| API 安全 | 7 | 高 | AP-001 → AP-007 |
| 文件上传 | 6 | 高 | FU-001 → FU-006 |
| 会话安全 | 6 | 高 | SS-001 → SS-006 |
| 密码学 | 5 | 高 | CR-001 → CR-005 |
| 基础设施 | 6 | 高 | IF-001 → IF-006 |
| AI/LLM 安全 | 5 | 高 | AI-001 → AI-005 |
| 安全响应头 | 5 | 中 | SH-001 → SH-005 |
| 日志与监控 | 5 | 中 | LM-001 → LM-005 |
| DevSecOps | 6 | 中 | DO-001 → DO-006 |
| 前端安全 | 4 | 中 | FE-001 → FE-004 |
**总计：** 16 个领域、26 个任务、95 个可执行检查。
## 仓库结构
```
.roadmap/
├── activity.jsonl # Event store (append-only, source of truth)
├── roadmap.json # Read-model: audit progress (derived, verifiable)
├── issues.json # Read-model: open/resolved audit issues
├── lessons.json # Read-model: learned constraints
├── snapshots/ # Integrity snapshots
│
├── AGENT_CONTRACT.yaml # What audit agents CAN and CANNOT do
├── ORCHESTRATOR_CONTRACT.yaml # Orchestrator invariants
├── RUNTIME_POLICY.yaml # TTLs, retries, escalation, rollback
├── STORAGE_POLICY.yaml # Event store format and field constraints
├── PROJECTION_SPEC.md # How events → state (pure function spec)
│
├── agent_result.schema.json # JSON Schema: validates every agent output
├── roadmap.schema.json # JSON Schema: validates roadmap.json (v0.4.0)
├── issues.schema.json # JSON Schema: validates issues.json
│
├── agents_swarm.yaml # Agent registry and role resolution
│
├── PARCER_PROFILE.agent-spec.yaml # Profile: reconnaissance agent
├── PARCER_PROFILE.agent-impl.yaml # Profile: audit execution agent
├── PARCER_PROFILE.agent-qa.yaml # Profile: risk classification and reporting agent
└── PARCER_PROFILE.orchestrator-runtime.yaml # Profile: orchestrator runtime
playbooks/
├── playbooks.security.json # Agent-executable playbooks (95 checks, 16 domains)
└── global_input_contract.json # Required/optional inputs for audit execution
reports/
├── phase1/ # Reconnaissance outputs
│ ├── tech-stack-inventory.md
│ ├── architecture-map.md
│ ├── data-flow-diagram.md
│ └── attack-surface-inventory.md
├── phase2/ # Audit execution outputs (boundary: agent-impl write)
│ ├── {domain}-audit.md # Narrative audit per domain
│ └── results/
│ └── SEC-{NNN}.json # Structured check results per task
├── phase3/ # Risk classification outputs (boundary: agent-qa write)
│ ├── vulnerability-inventory.json
│ ├── classified-vulnerabilities.json
│ ├── risk-matrix.json
│ └── risk-matrix.md
├── phase4/ # Recommendations and reporting
│ ├── technical-remediations.md
│ ├── best-practices.md
│ └── executive-summary.md
└── final/ # Final compiled report
├── security-audit-report.md
└── security-audit-report.json
```
## 审计阶段
### 阶段 1 — 侦察（`spec` 任务）
在任何安全检查运行之前，智能体会绘制地形图：
| 任务 | 输出 |
|---|---|
| SEC-001: 识别技术栈 | 语言、框架、数据库、云服务、依赖版本 |
| SEC-002: 映射架构 | 组件、数据流、集成点、信任边界 |
| SEC-003: 枚举攻击面 | 端点、接口、上传、WebSocket、外部 API |
这些输出通过 `depends_on` 供给每个阶段 2 任务。
### 阶段 2 — 审计执行（`impl` 任务）
核心审计：16 个任务，每个安全领域一个。每个任务执行相应的剧本：
```
Agent receives: playbook (checks + agent_instructions) + reconnaissance outputs
Agent executes: grep/find/curl commands per check, applies pass/fail criteria
Agent emits: structured result per check (status, severity, evidence, remediation)
```
示例——来自 `input_validation` 剧本的检查 IV-001（SQL 注入）：
```
{
"check_id": "IV-001",
"name": "SQL injection",
"status": "fail",
"severity_if_fail": "CRITICAL",
"evidence": {
"files": ["src/controllers/userController.js"],
"lines": ["42: db.query(`SELECT * FROM users WHERE id = ${req.params.id}`)"],
"description": "String interpolation in raw SQL query with unsanitized user input."
},
"remediation": "Use parameterized queries: db.query('SELECT * FROM users WHERE id = $1', [req.params.id])"
}
```
### 阶段 3 — 风险分类（`qa` 任务）
将所有阶段 2 的发现整合为优先的风险矩阵：
| 任务 | 输出 |
|---|---|
| SEC-030: 整合漏洞 | 统一清单，包含 ID、领域和证据 |
| SEC-031: 分类严重性和影响 | CRITICAL/HIGH/MEDIUM/LOW/INFO，带 CIA 影响评估 |
| SEC-032: 生成风险矩阵 | 漏洞 × 类别 × 严重性 × 影响 × 修复 |
### 阶段 4 — 建议和报告（`spec` + `qa` 任务）
| 任务 | 输出 |
|---|---|
| SEC-040: 技术修复 | 针对 CRITICAL 和 HIGH 发现的代码/配置修复 |
| SEC-041: 最佳实践 | 按领域组织的实践，带ASP/CIS/NIST 参考 |
| SEC-042: 执行摘要 | 1 页摘要，包含安全评分（0-100）和前 5 大风险 |
| SEC-043: 最终报告 | 完整审计报告——所有章节，所有发现可追溯到检查 |
## 剧本结构
`playbooks.security.json` 中的 16 个剧本均遵循以下结构：
```
{
"task_ref": "SEC-015",
"domain": "input_validation",
"priority": "critical",
"input_requirements": {
"required": ["repo_path"],
"optional": ["endpoint_base_url"]
},
"checks": [
{
"check_id": "IV-001",
"name": "SQL injection",
"severity_if_fail": "CRITICAL",
"agent_instructions": {
"strategy": "static_analysis",
"steps": [
"grep -rn ... (concrete commands)",
"Verify ORM usage consistency",
"Check raw queries for parameterization"
],
"pass_criteria": "ORM used consistently. Raw queries use parameterization. Zero concatenation of input in SQL.",
"fail_criteria": "Any concatenation of user input in SQL string. Raw queries without parameterization.",
"false_positive_guidance": "ORM query builders that use parameterization internally are safe."
},
"remediation": "Use ORM or prepared statements. Never concatenate input in SQL."
}
]
}
```
**智能体策略：**
| 策略 | 数量 | 描述 |
|---|---|---|
| `static_analysis` | 77 | 在源代码和配置文件中 grep/find 模式 |
| `hybrid` | 16 | 静态分析 + 实时端点测试（当 `endpoint_base_url` 可用时） |
| `tool_execution` | 2 | 运行安全工具（`npm audit`、`pip-audit` 等） |
每个检查都提供**客观的通过/失败标准**——智能体不决定什么算漏洞；剧本定义它。
## 路线图模式合规性
审计路线图（`roadmap.json`）符合 ESAA v0.4.0 规范模式：
```
{
"meta": {
"schema_version": "0.4.0",
"immutable_done": true,
"run": {
"run_id": "RUN-SEC-0001",
"status": "initialized",
"last_event_seq": 0,
"projection_hash_sha256": "0000000000000000000000000000000000000000000000000000000000000000",
"verify_status": "unknown"
}
},
"project": {
"name": "PARCER Security Audit",
"audit_scope": "Full-stack security audit covering 16 domains..."
},
"tasks": [ ... ],
"indexes": {
"by_status": { "todo": 26, "in_progress": 0, "review": 0, "done": 0 },
"by_kind": { "spec": 5, "impl": 16, "qa": 5 }
}
}
```
所有 [ESAA 不变量](https://arxiv.org/abs/2602.23193) 适用：
- **`immutable_done: true`** — 已完成的审计任务无法修改；更正需要热修复工作流
- **`verify_status`** — 每次状态变更后进行 SHA-256 重放验证
- **`additionalProperties: false`** — 每层严格模式合规
- **索引一致** — `by_status` 和 `by_kind` 匹配实际任务计数
## 任务状态机
任务生命周期由 [ESAA 架构](https://arxiv.org/abs/2602.23193) 定义，并强制执行 claim-before-work、done-不可变性和 prior-status 一致性不变量：
```
claim complete review(approve)
[todo] ─────────► [in_progress] ─────────► [review] ─────────► [done] ✗
▲ │ (immutable)
└───────────────────────┘
review(request_changes)
```
应用于安全审计上下文：
- **`claim`** — 智能体接管某个安全领域审计（例如，SEC-015：输入验证）
- **`complete`** — 智能体完成所有剧本检查并提交带 `verification.checks` 的结构化结果
- **`review(approve)`** — QA 智能体确认发现基于证据、分类合理且没有跳过检查
- **`review(request_changes)`** — QA 智能体发现覆盖不完整或分类不合理
## 契约与策略
### 智能体契约 — 安全审计上下文
**按任务类型的边界：**
| 类型 | 审计角色 | 读取 | 写入 |
|---|---|---|---|
| `spec` | 侦察（阶段 1） | `.roadmap/**`, `docs/**` | `reports/phase1/**` |
| `impl` | 审计执行（阶段 2） | `.roadmap/**`, `playbooks/**`, `reports/phase1/**` | `reports/phase2/**` |
| `qa` | 分类 + 报告（阶段 3-4） | `.roadmap/**`, `reports/**` | `reports/phase3/**`, `reports/phase4/**`, `reports/final/**` |
### 运行时策略
| 参数 | 值 | 理由 |
|---|---|---|
| 尝试 TTL | PT30M | 某些领域（基础设施、数据安全）需要深入分析 |
| 每任务最大尝试次数 | 3 | 防止在模糊代码库上无限循环 |
| 尝试间冷却时间 | PT2M | 允许重试间上下文重置 |
| 自动升级 | 3× medium → high | 重复模式 = 系统性问题，而非孤立发现 |
### 问题升级
| 严重性 | 操作 | 审计上下文示例 |
|---|---|---|
| `low` | 仅记录 | 缺少 `Referrer-Policy` 响应头 |
| `medium` | 记录并标记 | 非凭证端点上的 CORS 通配符 |
| `high` | 阻止任务 + 通知 | 认证控制器中的 SQL 注入 |
| `critical` | 停止管道 + 通知 | 私钥提交到仓库 |
### 护栏
特定于安全的护栏强制执行审计质量：
- **永不编造不存在的漏洞** — 每个发现都需要证据（文件、行、命令输出）
- **始终在技术上为风险辩护** — 严重性必须被辩护，而非假设
- **区分真实风险与改进** — 内部工具上的"缺少 WAF"是 INFO，而非 HIGH
- **避免无证据的警报** — 误报会削弱对审计的信任
- **一致地分类严重性** — CRITICAL/HIGH/MEDIUM/LOW/INFO，带客观标准
## 验证协议
ESAA-Security 继承完整的 [ESAA 验证协议](https://arxiv.org/abs/2602.23193)。事件存储是真相来源；读取模型是通过重放和 SHA-256 哈希验证的确定性投影。智能体或操作员可以通过重放事件日志并将计算的哈希与存储的投影哈希进行比较来随时验证完整性：
```
def esaa_verify(events, roadmap_json):
projected = project_events(events) # pure function — no I/O
hash_input = {
"schema_version": projected["meta"]["schema_version"],
"project": projected["project"],
"tasks": projected["tasks"],
"indexes": projected["indexes"]
}
canonical = json.dumps(hash_input, sort_keys=True, separators=(',', ':')) + '\n'
computed = hashlib.sha256(canonical.encode('utf-8')).hexdigest()
stored = roadmap_json["meta"]["run"]["projection_hash_sha256"]
if computed == stored:
return {"verify_status": "ok"}
else:
return {"verify_status": "mismatch"}
```
**验证对安全审计的意义：**
| 状态 | 含义 | 编排器响应 |
|---|---|---|
| `ok` | 审计状态一致 — 所有发现可追溯到事件 | 继续 |
| `mismatch` | 审计状态与事件日志偏离 — 发现可能被篡改 | `reproject_or_halt` |
| `corrupted` | 事件存储格式错误 — 审计完整性受损 | `halt_and_snapshot` |
这保证**最终报告是审计轨迹的忠实投影**——没有发现可以在事件存储中不留痕迹地被添加、删除或重新分类。
## 编排周期
编排周期遵循 ESAA 事务管道，专门针对安全审计调度进行了调整：
```
1. parse_event_store → project current audit state
2. select_next_eligible_task (depends_on all done; status=todo)
└─ if none eligible and all done → emit run.end(success) → compile final report
└─ if deadlock detected → emit issue.report(severity=high)
3. dispatch_agent → inject: playbook + reconnaissance outputs + roadmap subset
└─ start TTL timer (PT30M)
4. validate_agent_output (7-layer, fail-closed)
├─ on reject → emit output.rejected → increment attempt_count
│ └─ if attempt_count >= 3 → emit issue.report(severity=high)
└─ on accept:
5. emit agent action event (claim | complete | review | issue.report)
6. emit orchestrator.file.write (one per report/result file)
7. emit orchestrator.view.mutate (roadmap.json update)
8. project_views → rebuild roadmap.json, issues.json
9. verify_projection → replay + SHA-256
├─ verify.ok → continue to next eligible task
└─ verify.fail → reproject_or_halt | halt_and_snapshot
10. emit run.end (success | failed | halted)
```
## 输入契约
要执行审计，智能体需要访问目标系统。全局输入契约定义：
| 输入 | 必需 | 描述 |
|---|---|---|
| `repo_path` | **是** | 被审计仓库的绝对路径 |
| `endpoint_base_url` | 否 | 实时应用 URL，用于混合检查（响应头、CORS、速率限制） |
| `docs_path` | 否 | 技术文档或架构文档的路径 |
| `infra_config_path` | 否 | 基础设施配置路径（docker-compose、k8s、terraform） |
| `ci_config_path` | 否 | CI/CD 配置路径（.github/workflows、.gitlab-ci.yml） |
每个剧本声明它需要哪些输入。编排器在调度前验证可用性。
## 安全评分
最终报告包含基于检查结果计算的安全评分（0-100）：
| 范围 | 分类 |
|---|---|
| 0–30 | **严重** — 需要立即采取行动的严重漏洞 |
| 31–50 | **差** — 多个领域存在重大安全缺口 |
| 51–70 | **一般** — 存在基线控制但仍有明显弱点 |
| 71–85 | **良好** — 坚实的安全态势，有加固空间 |
| 86–100 | **优秀** — 所有审计领域全面覆盖 |
评分根据严重性加权计算，确保单个 CRITICAL 发现的影响比例上大于多个 LOW 发现。
## 审计级别
ESAA-Security 适用于**L1/L2 成熟度的内部审计**：
| 用例 | 适合度 |
|---|---|
| 开发/部署检查单 | 可用——无需治理即可提取检查 |
| 内部审计（L1/L2） | **最佳点** — 完整覆盖并具有 ESAA 可追溯性 |
| 监管合规（LGPD） | 技术组件——需要补充流程文档 |
| 正式认证（ISO 27001、PCI-DSS） | 单独使用不足——需要组织控制和正式方法论 |
16 个领域很好地映射到 OWASP Top 10、ASVS Level 1 和部分 Level 2。AI/LLM 安全领域（AI-001 → AI-005）将覆盖范围扩展到大多数传统框架未涵盖的类别。
## 入门
### 前置条件
- 至少一个已认证的智能体 CLI 已本地安装：
- [Codex](https://github.com/openai/codex) (OpenAI)
- [Claude Code](https://docs.anthropic.com/en/docs/claude-code) (Anthropic)
- [Gemini CLI](https://github.com/google-gemini/gemini-cli) (Google)
- 访问要审计的目标仓库
### 运行审计
ESAA-Security 不需要专用 CLI。审计由 LLM 智能体（Codex、Claude Code 或 Gemini CLI）在项目目录内执行。智能体读取初始化文件，遵循 ESAA 工作流契约，并通过 `claim → complete → review` 周期顺序执行任务。
1. 克隆仓库并设置目标：
git clone https://github.com/elzobrito/esaa-security.git
cd esaa-security
. 在 `.roadmap/init.yaml` 中配置目标仓库：
# .roadmap/init.yaml — 指向被审计的仓库
repo_path: /path/to/target/repo
# 可选：用于混合检查的实时端点（响应头、CORS、速率限制）
endpoint_base_url: http://localhost:3000
3. 在智能体 CLI 中打开项目并指示其开始：
# 使用 Codex 的示例
codex
# 使用 Claude Code 的示例
claude
# 使用 Gemini CLI 的示例
gemini
然后指示智能体：
Read .roadmap/init.yaml and begin executing the audit roadmap.
Follow the ESAA workflow: claim each task before working,
complete with structured results and verification evidence.
智能体将：
- 读取 `init.yaml` 获取项目配置和目标路径
- 读取 `roadmap.json` 识别符合条件的任务（状态为 `todo`，依赖已满足）
- 声明下一个符合条件的任务
- 执行 `playbooks/playbooks.security.json` 中相应的剧本
- 发出结构化结果（检查状态、严重性、证据、修复）
- 带验证检查完成任务
- 继续下一个符合条件的任务，直到所有阶段完成
4. 监控进度：
cat .roadmap/roadmap.json # 当前审计状态 — 任务、状态、索引
cat .roadmap/activity.jsonl # 仅追加事件日志 — 每个声明、完成、发现
5. 阅读最终报告（在阶段 4 生成）：
cat reports/final/security-audit-report.md
cat reports/phase4/executive-summary.md # 带安全评分的 1 页摘要
cat reports/phase4/technical-remediations.md
cat reports/phase4/best-practices.md
## 工件
| 工件 | 模式 | 描述 |
|---|---|---|
| `roadmap.security.json` | ESAA v0.4.0 | 审计路线图 — 26 个任务、4 个阶段、模式验证 |
| `playbooks.security.json` | playbooks.security.v1 | 16 个领域、95 个可执行检查，带智能体指令 |
| `PARCER_v1.6.0-security-audit.yaml` | — | 源框架，定义安全领域、护栏和智能体治理（[论文](https://arxiv.org/abs/2603.00856)） |
## 与现有方法的比较
| 特性 | 临时 LLM 审查 | OWASP 检查清单 | 商业扫描器 | ESAA-Security |
|---|---|---|---|---|
| 结构化覆盖 | ✗ | ✓ | ✓ | ✓（95 个检查、16 个领域） |
| 智能体可执行 | ✗ | ✗ | ✗ | ✓（带具体命令的剧本） |
| 审计轨迹 | ✗ | ✗ | 部分 | ✓（仅追加事件存储） |
| 确定性重放 | ✗ | ✗ | ✗ | ✓（SHA-256 验证） |
| AI/LLM 领域覆盖 | ✗ | ✗ | ✗ | ✓（5 个检查） |
| LGPD 感知 | ✗ | ✗ | 部分 | ✓（DA-005） |
| 开放框架 | ✗ | ✓ | ✗ | ✓ |
## 案例研究：ESAA-Supervisor — 氛围编程下的审计
ESAA-Security 针对 [ESAA-Supervisor](https://github.com/elzobrito/esaa-supervisor) 进行了验证，ESAA-Supervisor 是一个用于 AI 智能体监督的全栈 Web 应用，完全通过氛围编程由五个前沿 LLM 构建：**GPT 5.4**、**GPT 5.3-codex**（OpenAI Codex）、**Claude Opus 4.6**、**Claude Sonnet 4.5**（Anthropic）和 **Gemini 3.1 Pro**（Google DeepMind）。系统包括 FastAPI 后端、React/TypeScript 前端、多智能体 CLI 编排、SSE 日志流、文件系统支持的规范状态、持久化聊天和代币遥测。所有 18 个路线图任务均已完成——功能上，系统运行正常。
ESAA-Security 审计管道执行了所有四个阶段——侦察、16 个领域的域审计执行、风险分类和最终报告——产生了结构化检查结果、漏洞清单、风险矩阵、技术修复建议、最佳实践指导和执行摘要。
### 审计结果
| 指标 | 值 |
|---|---|
| **安全评分** | **19.5 / 100 — 严重** |
| 严重漏洞 | 9 |
| 高危漏洞 | 15 |
| 漏洞总数 | 24 |
| 受影响领域 | 12 / 16 |
| 预估修复工作量 | 约 61.5 小时，跨越 3 个冲刺 |
### 按领域评分细分
| 领域 | 评分 | 分类 |
|---|---|---|
| 依赖项与供应链 | 92.3% | 良好 |
| 前端安全 | 80.0% | 良好 |
| 密码学 | 37.5% | 不足 |
| 密钥与配置 | 36.4% | 不足 |
| AI/LLM 安全 | 5.3% | 严重 |
| 认证/授权 | 0.0% | 不存在 |
### 前 5 大严重发现
| ID | 漏洞 | 严重性 | 影响 |
|---|---|---|---|
| AZ-001 | 访问控制缺失 — API 完全开放，任何网络参与者都可以执行智能体、修改状态、读取主机文件 | 严重 | 全面 |
| AI-001 | 提示注入 — 聊天消息直接发送到 LLM，无分隔符、转义或注入过滤器 | 严重 | 高 |
| AZ-002 | IDOR/路径遍历 — `/browse` 端点允许在主机上任意浏览文件系统 | 严重 | 中 |
| SC-004 | 宽松 CORS（`*`）— 任何网站都可以向 API 发出认证请求 | 严重 | 中 |
| AI-002 | LLM 无限制访问 — `--approval-mode yolo` 和 `--permission-mode bypassPermissions` 启用无需人工批准的执行 | 严重 | 高 |
### 关键观察
审计揭示了一个系统性模式：所有五个模型都擅长生成功能正确、依赖干净且前端安全性合理的代码，但**没有一个主动实现安全控制**。身份验证、授权、输入清理、速率限制、会话管理、RBAC 和 CSP 响应头完全缺失——不是因为它们被明确排除，而是因为从未被要求。
模型一贯选择**最小摩擦路径**：`CORS: *`、`--approval-mode yolo`、`bypassPermissions`——这些配置使代码在首次尝试时就能工作，但会造成严重的攻击面。安全是一个横切架构问题，需要深思熟虑的设计决策；氛围编程系统性地消除了这些决策通常会发生的摩擦。
由于核心领域中有超过 3 个未缓解的严重漏洞，全局评分被限制（上限 50），反映了现实世界的方法论：当 API 完全开放时，前端质量无关紧要。
### 修复路线图
技术修复文档将修复组织成三个冲刺：
| 冲刺 | 重点 | 工作量 | 关键修复 |
|---|---|---|---|
| 冲刺 1 | 生产阻塞器 | 约 14 小时 | CORS 限制、认证中间件、路径沙箱、bypass 模式移除 |
| 冲刺 2 | 运营安全 | 约 17 小时 | 日志脱敏、速率限制、提示注入防御、RBAC、安全响应头 |
| 冲刺 3 | 完全加固 | 约 25 小时 | bcrypt + JWT、HTTPS/TLS、输出清理、上传验证、LGPD 保留策略 |
所有发现都映射到 **OWASP Top 10:2021**、**OWASP ASVS 5.0**、**CIS Controls v8.1**、**NIST CSF 2.0** 和 **NIST SP 800-53 Rev. 5**。
## 路线图
- [x] **首个案例研究** — ESAA-Supervisor 审计：19.5/100，24 个漏洞，完整工件链已生成
- [x] **arXiv 发表** — [arXiv:2603.06365](https://arxiv.org/abs/2603.06365)
- [ ] **评估模式** — 用于第三方自评估的平面检查清单（源自剧本）
- [ ] **CVSS 评分集成** — 将发现映射到 CVSS v4.0 以获得标准化严重性
- [ ] **实时 DAST 集成** — OWASP ZAP / Nuclei 执行作为混合检查策略
- [ ] **多仓库审计** — 跨微服务仓库编排审计
- [ ] **合规映射** — 检查到 LGPD 条款、OWASP AS、CIS Controls 的自动映射
- [ ] **时间比较** — 审计运行间的安全态势差异
## 引用
如果您在研究中使用 ESAA-Security，请引用：
```
@article{santos2026esaasecurity,
title={ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code},
author={Brito dos Santos Filho, Elzo},
journal={arXiv preprint arXiv:2603.06365},
year={2026},
url={https://arxiv.org/abs/2603.06365}
}
```
对于底层 ESAA 架构：
```
@article{santos2026esaa,
title={ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering},
author={Brito dos Santos Filho, Elzo},
journal={arXiv preprint arXiv:2602.23193},
year={2026},
url={https://arxiv.org/abs/2602.23193}
}
```
对于 PARCER 运营契约框架：
```
@article{santos2026parcer,
title={PARCER as an Operational Contract to Reduce Variance, Cost, and Risk in LLM Systems},
author={Brito dos Santos Filho, Elzo},
journal={arXiv preprint arXiv:2603.00856},
year={2026},
url={https://arxiv.org/abs/2603.00856}
}
```
## 许可证
MIT
## 作者
**Elzo Brito dos Santos Filho**
📧 elzo.santos@cps.sp.gov.br
标签：AES-256, Agentic AI, AI生成代码, Append-only Log, Autonomous Agents, Boundary Contracts, Deterministic Projection, DLL 劫持, ESAA架构, Event Sourcing, Hash Verification, LLM, PARCER框架, Replay Verification, Risk-oriented Reporting, Security Auditing, Software Security, TLS抓取, Unmanaged PE, Vulnerability Assessment, 事件溯源, 代理AI, 代码安全, 哈希验证, 大语言模型, 安全领域覆盖, 对称加密, 漏洞枚举, 漏洞评估, 确定性投影, 结构化输出, 自主代理, 自动化审计, 软件安全, 边界契约, 追加日志, 重放验证, 风险导向报告