heidericklucas/go-security-swe-bench

# go-security-swe-bench 一个 SWE-bench 风格的 RL 环境，用于评估 AI 模型在真实安全漏洞修复任务上的能力。 ## 是什么 该 benchmark 包含 6 个单缺陷 Go 应用实例，每个实例都提出了一个真实的安全漏洞（SSRF、JWT 伪造、SQLi、IDOR、XSS、路径遍历）。模型会收到问题描述和存在漏洞的源代码，然后被要求对其进行修复。性能评估采用二元方式：修复方案通过所有测试（奖励 1.0）或未通过（奖励 0.0）。 ## 为什么 安全漏洞是生产软件中的主要威胁载体，但很少有 benchmark 会评估与 AI 安全相关的修复工作流。此 benchmark 旨在测试： - 识别和修复真实 exploit 模式的能力 - 抵抗破坏合法功能的“修复”方案的能力 - 防御看似有效但遗漏了关键情况的对抗性 patch 的鲁棒性 ## 怎么做 ### 构建 ``` make build ``` 离线编译检查每个 package（`go build -mod=vendor ./...`）。grader 本身不会进行任何构建——它是在固定的 container 中从源码运行 `go test`。 ### 运行测试（离线） ``` make test ``` 在基础 app 上运行单元测试和功能测试。这些测试在基础 app 上会**通过**——app 的合法功能完好无损。安全缺陷由 grader 保留的 exploit 测试（通过 `make verify`）单独证明，而不是通过 `make test`。 ### 对基础应用评分（预期奖励为 0） ``` make verify ``` 在 Docker 中运行测试工具，针对所有 6 个实例对基础 app 进行评分。所有实例都应失败（未应用任何修复）。 ### 使用 Golden Patches 评分（预期奖励为 1.0） ``` make verify-solution ``` 应用每个标准解决方案 patch 并进行评分。所有实例都应通过。 ### 对抗性 Patch 评分（预期奖励为 0） ``` make verify-attacks ``` 应用故意写坏的“修复”来验证测试套件是否能捕获不充分的修复。所有实例都应失败。 ### 覆盖率 ``` make cover ``` 报告 `app/` 代码中每个函数的覆盖率。这仅在仓库自身的 CI 中运行——它**绝不**是奖励函数的一部分。 ## 实例 每个实例包含： - **问题描述**（对模型可见）：`tasks/.md` - 包含测试契约的 **manifest**：`tasks/.json` - **golden patch**：`solution/.patch` | ID | 漏洞 | CWE | OWASP | 问题描述 | |---|---|---|---|---| | `ssrf-import` | 通过重定向跟随引发的 SSRF | CWE-918 | A10:2021 | [tasks/ssrf-import.md](tasks/ssrf-import.md) | | `jwt-forged-token` | JWT 伪造（未验证签名） | CWE-347 | A07:2021 | [tasks/jwt-forged-token.md](tasks/jwt-forged-token.md) | | `sqli-note-search` | 笔记搜索中的 SQL 注入 | CWE-89 | A03:2021 | [tasks/sqli-note-search.md](tasks/sqli-note-search.md) | | `idor-note-read` | 损坏的对象级访问控制 | CWE-639 | A01:2021 | [tasks/idor-note-read.md](tasks/idor-note-read.md) | | `xss-note-export` | 存储型 XSS（缺少输出编码） | CWE-79 | A03:2021 | [tasks/xss-note-export.md](tasks/xss-note-export.md) | | `pathtraversal-attachment` | 文件下载中的路径遍历 | CWE-22 | A01:2021 | [tasks/pathtraversal-attachment.md](tasks/pathtraversal-attachment.md) | ## 模型评估 该测试工具向每个模型展示： 1. 问题描述（以症状为主，无修复提示） 2. 对 `app/` 源代码的只读访问权限 3. 预期的失败测试列表 4. 模型必须对 `app/` 打补丁以使所有测试通过 模型**无法看到**： - `tests/exploit/` 中的 exploit 代码 - `solution/` 中的 golden patch - 此 README 或任何 grader 内部细节 修复方案在 Docker 中进行确定性评估： - 二元奖励（0.0 或 1.0） - 必须通过所有 `fail_to_pass` 测试 - 不得破坏任何 `pass_to_pass` 测试 - 构建错误或超时将给予 0 奖励 ## 文档 - [REVIEW.md](REVIEW.md) — 对候选 patch 的代码审查，包括那些**通过了自动化 grader（奖励 1.0）但仍然是错误**的 patch，以及性能和可维护性发现 - [DECISIONS.md](docs/DECISIONS.md) — 架构决策记录 - [solution/WRITEUP.md](solution/WRITEUP.md) — 每个实例的 exploit 叙述和标准推理过程（仅限 grader 使用；不向模型展示） ## 仓库结构 ``` . ├── app/ # Application source (Go packages; the model patches this) ├── tests/ │ ├── exploit/ # Exploit proofs — FAIL_TO_PASS (grader-only) │ ├── functional/ # Positive contracts + happy path — PASS_TO_PASS │ ├── harness/ # Shared in-process test app (held-out) │ └── adversarial/ # Reward-hacking patches proven to score 0 ├── tasks/ # Instance manifests (*.json) + model-visible statements (*.md) ├── solution/ # Golden patches + WRITEUP (grader-only) ├── harness/ # Python grader (run_eval.py) + schema ├── docs/ # DECISIONS.md and review-samples/ ├── REVIEW.md # Code review of candidate patches ├── Makefile └── go.mod, go.sum, vendor/ # Vendored deps (hermetic, offline build) ``` ## 许可证 MIT — 查看 [LICENSE](LICENSE)。

标签：EVTX分析, Go, Ruby工具, 人工智能, 代码大模型评测, 强化学习, 日志审计, 漏洞修复, 用户模式Hook绕过, 网络安全培训, 请求拦截, 逆向工具