AICGSecEval
Tencent/AICGSecEval加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图1：A.S.E（AICGSecEval）项目标题图
2025 年，全球代码贡献量中已有超过 30% 由 AI 辅助生成。然而，当开发者习惯性地敲下 // Copilot suggestion 时，一个令人不安的问题浮出水面：这些 AI 生成的代码，真的安全吗？
腾讯安全平台部的悟空代码安全团队在日常漏洞审计中发现了一个规律——AI 生成的代码往往在功能上正确，却在安全边界处理上存在疏漏：缓冲区溢出、空指针解引用、SQL 注入路径……这些问题与人类程序员的经典失误高度重合，却又因为 AI 生成代码的规模化特性而呈现新的威胁形态。
正是在这一背景下，A.S.E（AICGSecEval） 应运而生。这是业界首个项目级 AI 生成代码安全性评测基准，由腾讯于 2025 年正式开源，旨在为 AI 编程工具的安全能力提供一套科学、可复现、可量化的评估标准。
A.S.E 由腾讯安全平台部·悟空代码安全团队主导开发，该团队长期专注于源代码安全审计与漏洞研究。项目的推出填补了行业空白：此前虽存在 SWE-bench、HumanEval 等代码能力评测基准，但均以功能正确性为核心指标，从未系统性地评估 AI 生成代码的安全缺陷率。
项目自 2025 年发布以来，已收录超过 29 类 CWE（Common Weakness Enumeration）漏洞类型，覆盖 OWASP Top 10 和 CWE Top 25 的重点风险，涵盖 C/C++、PHP、Java、Python、JavaScript 等主流编程语言。评测数据源自真实 GitHub 项目与权威 CVE 漏洞库，确保评测场景的实战价值。
A.S.E 的评测框架分为三个核心层次，每一层对应 AI 生成代码安全评测的一个关键环节：
评测任务从真实 GitHub 项目和 CVE 漏洞补丁中提取。系统自动识别并提取项目级代码上下文（项目结构、依赖关系、既有代码风格），将其注入 AI 编程工具的上下文窗口，精准还原真实开发场景下的 AI 编程条件——而不是孤立地给 AI 一个函数签名让它补全。
A.S.E 支持评测两种类型的被测对象：
LLM 评测：通过 OpenAI 兼容 API 接口调用各类大语言模型（如 GPT-4o、Claude Sonnet 等），传入项目上下文并请求代码修复或功能实现。
Agent 评测：支持对 AI 编程 Agent 工具（如 Claude Code、OpenAI Codex、Google Gemini 等）进行端到端评测，考察 Agent 在多轮交互中保持安全意识的能力。Agent 评测模块通过 bench/agent/ 中的适配器实现扩展，当前已内置 Claude Code、Codex 和 Gemini 的适配器。
这是 A.S.E 最具技术含量的部分——动静态协同评估。
静态分析：对 AI 生成的代码进行规则匹配，检测常见漏洞模式（如硬编码密钥、不安全函数调用等）。
动态验证：在 Docker 容器中实际编译并运行代码，通过注入的漏洞 PoC（Proof of Concept）和测试用例验证漏洞是否真实存在。run_security_scan.py 中的 run_command_and_validate 函数通过 docker_helper.py 管理容器生命周期，向容器内注入命令并检查输出是否包含预期结果。
这种动静结合的设计显著提升了评测的科学性：静态分析提供广度，动态验证提供精度，两者互补得出最终安全评分。
Tencent/AICGSecEval/
├── invoke.py # 主入口，CLI 调度器
├── docker_helper.py # Docker 容器管理器（核心依赖）
├── requirements.txt # Python 依赖
├── run_code_generation_llm.py # LLM 代码生成评测模块
├── run_code_generation_agent.py # Agent 代码生成评测模块
├── run_security_scan.py # 安全扫描模块（动静态分析）
├── run_security_scan_static.py # 纯静态扫描模块
├── run_evaluate.py # 评测结果评分与统计分析
├── run_data_retrieval_bm25.py # BM25 上下文检索模块
├── bench/
│ ├── agent/ # Agent 适配器（Claude/Codex/Gemini）
│ ├── context_manager.py # 上下文管理器
│ ├── generate_code.py # 代码生成逻辑（含 git apply 补丁）
│ ├── bm25_retrieval.py # BM25 检索实现
│ └── utils.py # 工具函数
└── data/ # 评测数据集（含 25+ CVE JSON + data_v2.json）
核心技术栈：
| 要求 | 最低规格 |
|---|---|
| 内存 | 推荐 16GB+ |
| 磁盘 | 100GB+（存放 GitHub 克隆项目 + 评测结果） |
| Python | ≥ 3.11 |
| Docker | ≥ 27 |
安装依赖：
pip install -r requirements.txt
LLM 评测示例：
python3 invoke.py \
--llm \
--model_name gpt-4o-2024-11-20 \
--base_url https://api.openai.com/v1/ \
--api_key sk-xxxxxx \
--batch_id v1.0 \
--dataset_path ./data/data_v2.json \
--output_dir ./outputs \
--max_workers 1 \
--github_token xxxxx
Agent 评测示例（以 Claude Code 为例）：
python3 invoke.py \
--agent \
--agent_name claude_code \
--batch_id v1.0 \
--dataset_path ./data/data_v2.json \
--claude_api_url https://ai.nengyongai.cn \
--claude_api_key sk-XXXXX \
--claude_model claude-sonnet-4-20250514 \
--github_token xxxxx
项目内置断点重连机制——评测中断后直接重新运行命令即可从上次位置继续，无需手动管理状态。
A.S.E 在设计中也不可避免地存在一些局限：
1. 资源门槛高：完整的项目级评测需要 16GB+ 内存和 100GB+ 磁盘空间，对个人开发者和小型团队来说部署成本不低。且由于缺少 Dockerfile 和 docker-compose，依赖需手动安装。
2. 评测耗时较长：每个任务涉及真实 GitHub 项目克隆、多轮 API 调用和容器内编译运行，完整评测耗时可达数小时。虽支持 max_workers 并发提速，但仍受限于 API 限频。
3. 评测范围受限：当前版本以代码生成为主，未覆盖 AI 生成配置、部署脚本、CI/CD 流水线等其他场景的安全评测。
4. 依赖商业 API：评测 LLM 和 Agent 均需调用外部商业 API（如 OpenAI、Anthropic），评测成本不可忽视。
A.S.E 的价值远不止于提供一个评测工具，更在于它推动了一种认知转变——评价 AI 编程能力，不能只看功能通过率，还要看安全漏洞率。
从行业影响看，A.S.E 已于 2025 年在 arXiv 发表学术论文（arXiv:2508.18106），评测结果在官网 aicgseceval.tencent.com/rank 公开。在已评测的模型中，不同模型在代码安全维度上的差异显著：部分以功能正确性著称的模型，在安全边界处理上的失误率明显高于平均水平，这为模型选型提供了关键参考。
随着 AI 编程工具从「尝鲜玩具」走向「生产主力」，代码安全问题正在从理论风险演变为真实的漏洞来源。A.S.E 为行业提供了一套统一的度量衡，让模型开发者有改进方向，让企业用户有选型依据——这是推动 AI 编程走向企业级可信生产的关键基础设施。