hevnsnt/CVEngine

如果你需要对自有互联网资产做持续测绘，并希望把扫描结果收敛成可复现的 CVE 命中，cvENGINE 值得花时间评估。它是 GPL-3.0 的自托管工具，整合了一批成熟扫描器；真正的成本在于长期维护和验证其 AI 研判，而不在安装本身。

解决什么问题

常见流程是三件彼此割裂的事：先用子域名发现工具找出暴露面，再用端口和服务扫描确认版本，最后拿漏洞扫描结果对照实际部署去猜哪些 CVE 真适用。等你看完，每份清单都已过期，判断是否受影响还得手工比对指纹。cvENGINE 把它合成一条流水线：输入域名、IP、CIDR 或 URL 后，发现、清点、暴露检查、CVE 关联和研判依次执行，结果进入可搜索的资产库，而不是丢给你一堆告警 流水线说明。最终得到的是持续更新的主机与发现视图，顶点域名每周还会做一次深度扫描。

有什么不同

关键差异是把资产发现与验证放在同一处。cvENGINE 用 bbot 做被动、标准和深度模式下的子域名与资产发现，用 nmap 和 naabu 做清点，用 nuclei 及其模板做已知检查，并可选集成 WPScan 和 RDP 截图 README。然后按项目自定的“fire, smoke, ice”分级给 CVE 排序，并尽可能做只读复现 评级方法。AI 只用于定向的 nuclei 检查和研判，而不是凭空生成漏洞结论，这个取舍对安全工具是合理的。

代价是复杂度和对第三方扫描器与情报源的依赖。cvENGINE 是 reNgine 2.x 的分支，继承了庞大的扫描器栈 上游项目。结论质量取决于 CVE 源、模板集和你配置的 AI 模型，README 没有给出独立的准确率基准。“安全设计”部分是项目对扫描器配置的自我声明——只跑通过只读和目的地检查的模板、数据库只尝试一次空密码、跳过回环、链路本地和云元数据地址——并非审计结论。它还提供 API 和 MCP 端点供开发 Agent 查询结果，对已经在用 Agent 的团队有用，但也多了一个需要加固的访问面 Agent API 文档。

谁值得试

适合手里有一组明确自有域名、又能腾出一台 Linux 主机的小型安全或基础设施团队，尤其是想避开按资产收费的商业攻击面产品的人。也适合希望通过文档中的 API 或 MCP 端点让 Agent 读取扫描结果的团队，项目支持只读 token。不适合只想在笔记本上跑一次临时扫描的人：这是需要 Docker、PostgreSQL 和证书配置的服务器应用。也不适合无法使用 Linux 的环境，文档给出的安装路径面向 Debian/Ubuntu 的一键安装，其他 Linux 主机则可走手动 Docker Compose 路径。

使用条件与边界

README 要求 Linux 服务器，建议至少 4 GB 内存和 20 GB 磁盘；手动路径还需要 Docker Engine、Compose 插件、git、make 和 python3 安装说明。一键安装会自行安装 Docker、生成密钥并创建私有 HTTPS 证书机构，浏览器会一直报警，直到你在各终端信任生成的 CA 证书。这是每个使用该服务的人都要理解的一步；管理员密码只在终端显示一次。

日常维护并不轻松：扫描器栈、CVE 源和模板需要更新，宣传的 AI 研判和搜索还依赖可选的 AI 模型和搜索引擎密钥配置。私网地址默认不扫描，直到你显式放行，这对面向外部的评估工具是正确默认值，但意味着内部测试需要主动改策略。如果计划分发修改版，GPL-3.0 许可证也需要纳入考虑 许可证。

HotRepo 点评

HotRepo 在 2026-10-26 只记录到一次新项目榜观察：Python 分类下 135 个总星、第 25 名。这只是创建一天仓库的单次快照，不是日增数据，也没有可比的日榜历史来判断关注度能否持续。项目太年轻，无法推断势头。投入时间前，建议先看架构文档中的 AI 研判配置，确认你是否能提供它所需的模型和 API 接入。