AutoCVE 漏洞审计平台
将项目筛选、源码审计、漏洞验证与 CVE 报告整理连成自动化流程。
按维度查看评分与理由
证据显示：README 声明了权限保护（架构文档提及），但未提供具体实现细节；用户交互功能存在（交互式审计），但未明确确认机制；数据流透明度有限，仅提及工具调用追踪；敏感数据处理未详细说明；依赖安全未提及漏洞扫描；外部影响（如扫描目标）有安全警告，但未提供沙箱细节；回滚机制未提及；来源归属有致谢 DeepAudit，但未提供完整依赖来源。扣分原因：多数标准仅有表面提及，缺乏具体实现证据。
证据显示：README 和测试文件描述了一致的 Multi-Agent 流程，自洽性较好；依赖可用性未明确说明，但提供了 Docker 部署；失败消息未详细说明。扣分原因：依赖可用性和失败消息缺乏具体证据。
证据显示：README 明确了目标用户（安全研究人员）和多种审计模式，适应不同场景；能力边界通过三种模式划分；触发精度未明确；环境适配提供了 Docker 部署和源码部署。扣分原因：触发精度和部分环境细节不足。
证据显示：README 提供了文档链接（用户手册、架构设计、接口文档），信息架构清晰；安装说明详细（一行命令和源码部署）；命名稳定性未明确；示例和 FAQ 有 CVE 成果展示，但无 FAQ；已知限制未明确；许可证为 AGPL-3.0，完整；版本变更通过 release workflow 生成 changelog；维护责任有联系方式。扣分原因：命名稳定性、已知限制和 FAQ 缺失。
证据显示：输出为 CVE 报告，格式明确；边际价值高（自动化 CVE 挖掘）；成本效益未详细说明，但提供了一行命令部署。扣分原因：成本效益缺乏具体数据。
证据显示：README 声称发现 30 个 CVE，但未提供验证方法；跨来源佐证有 CVE 编号链接，但未独立验证；事实与推断未明确分离。扣分原因：缺乏可验证的测试结果和独立验证。
- 该仓库声称发现 30 个 CVE，但未提供可复现的验证方法，需谨慎对待。
- 权限保护、沙箱隔离等安全机制仅在文档中提及，未提供实现细节，实际安全性未知。
- 依赖安全未提及，可能存在已知漏洞的依赖。
这个 Agent 能做什么，适合哪些场景？
AutoCVE 是一个面向授权安全研究和源码审计的自托管平台，覆盖项目筛选、仓库导入、审计任务创建、漏洞验证和报告生成。它由 Orchestrator 调度 Recon、Scan、Triage、Finding 与 Verification Agent，并在完成后合并审计结果。平台提供增强扫描、智能审计和综合审计三种模式，分别侧重扫描结果过滤、深度漏洞挖掘或二者结合。部署后的界面运行在 React 前端，后端为 FastAPI，并配套 PostgreSQL 与 Adminer。漏洞可在平台内去重并结构化入库，CVE 申报报告由系统生成，但提交仍需用户自行复制内容并按目标项目的披露流程操作。
用户先导入项目并创建审计任务，随后由 Orchestrator 编排 Recon、Scan、Triage、Finding 和 Verification Agent：Recon 进行信息收集，Scan 调用扫描工具，Triage 过滤误报，Finding 直接分析源码，Verification 进行动态验证，最后 Merge / Finalize 汇总结果。Finding Agent 使用 ReAct Loop、专项工具调用、Nudge 纠偏和 FinalizeFinding 结构化终止机制产出发现结果。审计过程可在界面中查看活动日志、Agent Tree、工具调用、阶段进度、初步报告和审计会话；用户还可针对结果继续追问以补充证据、攻击链或复现步骤。发现的漏洞会经过去重后以结构化形式保存，并可编辑或导出报告用于后续 CVE 申报。
- 授权安全研究人员需要对一个导入的开源项目开展端到端 CVE 挖掘，并保留审计过程与报告。
- 安全团队已有扫描工具结果，希望使用“增强扫描”模式经 Scan → Triage 过滤误报。
- 漏洞研究人员要直接审查源码、寻找高价值漏洞时，可选择以 Finding 为核心的“智能审计”。
- 代码审计团队希望在同一任务中结合工具扫描和源码分析时，可选择“综合审计”。
- 负责漏洞披露的人员需要将审计发现去重入库，并整理可复制提交的 CVE 申报报告。
这个 Agent 有哪些优点和局限？
- 将项目筛选、仓库导入、审计、验证和报告生成串联为一个明确的工作流。
- Orchestrator 将 Recon、Scan、Triage、Finding 和 Verification 分工编排，支持扫描结果过滤与源码深挖并行覆盖。
- Finding Agent 明确采用 ReAct Loop、Nudge 和 FinalizeFinding 来组织审计与结构化终止。
- 提供审计日志、Agent Tree、工具调用和会话追踪，便于复盘与补充漏洞证据。
- 材料只说明需要配置模型，未说明支持哪些模型提供商、所需凭据、费用或模型失败时的行为。
- CVE 报告生成不等于自动申报；用户仍需自行提交，并遵守目标项目的披露政策。
- 平台仅限获得明确授权的扫描、验证和 PoC 测试，不能作为未授权目标的安全评估工具使用。
- 当前材料未提供 API 鉴权、模型配置、导入仓库方式或生产环境运维细节，部署评估前仍需补足这些信息。
如何安装或部署这个 Agent？
Linux、macOS 或 Git Bash 可执行：
curl -fsSL https://raw.githubusercontent.com/larlarua/AutoCVE/v1.0.5/docker-compose.prod.yml | docker compose -f - up -dWindows PowerShell 或 CMD 可执行：
curl.exe -fsSL https://raw.githubusercontent.com/larlarua/AutoCVE/v1.0.5/docker-compose.prod.yml | docker compose -f - up -d如需源码部署：
git clone https://github.com/larlarua/AutoCVE.git
cd AutoCVE
docker compose up -d --build启动后访问 http://localhost:3000。开始审计前需要在产品中配置模型；所提供材料未说明支持的模型提供商、凭据字段或配置方式。
如何使用这个 Agent？
打开 http://localhost:3000，按界面流程配置模型、导入项目并创建审计任务。根据目标选择增强扫描、智能审计或综合审计，然后在活动日志、Agent Tree、工具调用和阶段进度中跟踪执行。审计完成后，在漏洞管理模块查看去重后的结构化发现，编辑或导出报告。若要申请 CVE，复制生成的报告内容，并依照目标项目的 SECURITY.md、GitHub Private Vulnerability Reporting、CNA 或其他负责任披露流程自行提交。
这个 Agent 与同类方案有什么区别？
README 将 DeepAudit 列为开发早期参考的工程架构项目，但未提供两者的功能对照、性能测试或迁移说明。
常见问题
它会自动把漏洞提交为 CVE 吗？
运行前需要什么模型凭据？
能否对任意互联网目标执行扫描？
部署后有哪些本地入口？
http://localhost:3000，后端 API 为 http://localhost:8000，Swagger 为 http://localhost:8000/docs，Adminer 为 http://localhost:8080。