CVE2CAPEC：把 CVE 自动映射到 CAPEC、ATT&CK 与 D3FEND 的流水线
该项目围绕「Galeax/CVE2CAPEC maps CVE identifiers into CAPEC attack patterns and generates practical threat reports for security response workflows.」构建，适用于实际场景的开源实践，提供可复用的工具链与集成方式。
秒懂
- 它是什么？
- CVE2CAPEC 是一个用 Python 写的开源工具，每天自动拉取新 CVE，并逐级关联到 CWE、CAPEC、MITRE ATT&CK、D3FEND 和 ATLAS。它的价值在于把孤立的漏洞编号串成攻击链知识，但它的映射深度和更新机制有明确的边界。
- 适合谁用？
- CVE2CAPEC 适合安全运营团队、威胁情报分析师和自动化平台维护者，尤其是那些需要每天跟踪新漏洞并快速获得攻击模式上下文的人。它不适合需要精确到单个 CVE 的战术级映射的团队，因为 CAPEC 到 ATT&CK 的映射是粗粒度的，且依赖上游数据的质量。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题：从漏洞编号到攻击模式的桥梁
安全团队拿到一个 CVE 编号时，通常只知道这是个漏洞，但不知道攻击者会怎么利用它。CVE2CAPEC 试图填补这个空白。它把 CVE 映射到 CWE（弱点分类），再映射到 CAPEC（攻击模式），然后进一步关联到 MITRE ATT&CK（战术和技术）、D3FEND（防御技术）和 ATLAS（AI 系统威胁）。这个链条的价值在于，运营人员可以从一个漏洞编号出发，直接看到对应的攻击手法和可能的防御措施。这个项目面向的是需要批量处理漏洞数据的人，比如 SOC 分析师、威胁情报平台维护者，或者做安全自动化的工程师。它不是一个漏洞扫描器，而是一个数据转换和关联工具。
数据流：六个脚本组成的流水线
CVE2CAPEC 的核心是一组按顺序执行的 Python 脚本。首先，retrieve_cve.py 从 NVD 拉取新 CVE 列表。接着 cve2cwe.py 为每个 CVE 关联 CWE 弱点。然后 cwe2capec.py 把 CWE 映射到 CAPEC 攻击模式。之后 capec2technique.py 将 CAPEC 映射到 ATT&CK 技术。再往后 technique2defend.py 把 ATT&CK 技术映射到 D3FEND 防御措施。最后 technique2atlas.py 把 ATT&CK 技术映射到 ATLAS，这是针对 AI 系统的威胁框架。整个过程是线性的，每一步依赖前一步的输出。这种设计让每一步可以单独运行和调试，但也意味着如果中间任何一步的数据源不可用，整个链条就会中断。
安装与运行：真实命令与配置
运行 CVE2CAPEC 需要 Python 环境。安装步骤很简单：git clone 仓库，进入目录，然后 pip install -r requirements.txt。更新基础数据库需要分别运行五个脚本：update_capec_db.py、update_cwe_db.py、update_technique_db.py、update_defend_db.py 和 update_atlas_db.py。之后按顺序运行六个映射脚本。所有 CVE 数据存储在 database 文件夹中，最终结果写入 results/new_cves.jsonl。这个 JSONL 文件是每行一个 JSON 对象，方便用 jq 或 Python 处理。如果你不想自己运行，项目提供了 GitHub Actions 自动更新，每天 00:05 UTC 执行，结果直接放在 results/new_cves.jsonl 里。
自动更新：双刃剑
README 明确说 CVE2CAPEC 不需要你自己运行，因为 GitHub Actions 每天自动更新数据库。这对用户来说很方便，你只需要定期拉取仓库或直接下载 results/new_cves.jsonl。但这也意味着你依赖项目的维护者持续运行 Actions。如果项目停止维护，或者 Actions 因为仓库被禁用而停止，数据更新就会中断。另一个问题是，自动更新的数据只包含新 CVE，不包含历史漏洞。如果你需要回溯某个特定 CVE 的映射，可能需要自己运行脚本，或者从其他来源获取。这种设计适合持续监控新漏洞，但不太适合做历史分析。
映射的深度：从 CWE 到 CAPEC 的粗粒度
CVE2CAPEC 的映射链条中，最关键的步骤是 cwe2capec.py，它把 CWE 映射到 CAPEC。但 CWE 到 CAPEC 的映射通常是多对多的，一个 CWE 可能对应多个 CAPEC，反之亦然。这意味着最终的映射结果是概率性的，而不是精确的。例如，一个 CVE 被分类为 CWE-79（XSS），它可能映射到多个 CAPEC 攻击模式。这种粗粒度对运营参考是有用的，但如果你需要精确到某个 CVE 的具体攻击路径，它可能不够。另外，CAPEC 到 ATT&CK 的映射也是类似的，一个 CAPEC 可能对应多个 ATT&CK 技术。整个链条的精度取决于最弱的一环。
许可证与商业使用限制
CVE2CAPEC 采用 GPL-3.0 许可证。这意味着如果你在自己的产品中集成或修改了它的代码，你的产品可能也需要以 GPL 协议开源。README 特别提到，对于需要非 GPL 商业使用的用户，可以联系项目方获取其他授权选项。这个条款对商业公司来说是一个明确的信号：如果你不想被 GPL 感染，要么联系作者，要么避免使用这个工具。对于内部使用，GPL 通常没有问题，但如果你计划将 CVE2CAPEC 作为服务提供给客户，就需要仔细考虑许可证的影响。
替代方案：cve-search 与 Vulnogram
如果你不需要完整的 MITRE 框架链，只想做 CVE 到 CAPEC 的映射，可以考虑 cve-search。cve-search 是一个更成熟的漏洞管理工具，它提供 CVE 的全文搜索和 API，也包含 CWE 和 CAPEC 的关联数据，但它的重点在漏洞管理而不是攻击模式映射。另一个选择是 Vulnogram，它是一个 CVE 条目创建工具，支持 CWE 和 CAPEC 的关联，但它是面向 CVE 提交者的，不是批量处理工具。相比之下，CVE2CAPEC 的优势在于自动化和全链条覆盖，但它的替代方案在特定场景下可能更精准或更易集成。
维护成本与升级风险
CVE2CAPEC 的维护成本主要在于依赖上游数据源的格式变化。MITRE 的 CWE、CAPEC、ATT&CK 等框架会不定期更新，如果数据结构发生变化，项目可能需要更新脚本。此外，NVD 的 API 也可能有变更，导致 retrieve_cve.py 失效。项目的最后推送时间未知，也没有发布版本，这意味着你只能依赖 main 分支的代码。如果你长期使用，建议定期检查仓库的提交历史和 Actions 运行状态。另一个风险是，项目的数据库文件可能很大，特别是 ATT&CK 和 ATLAS 的数据，需要足够的磁盘空间。
编辑结论
CVE2CAPEC 适合安全运营团队、威胁情报分析师和自动化平台维护者，尤其是那些需要每天跟踪新漏洞并快速获得攻击模式上下文的人。它不适合需要精确到单个 CVE 的战术级映射的团队，因为 CAPEC 到 ATT&CK 的映射是粗粒度的，且依赖上游数据的质量。在采用前，应先检查 results/new_cves.jsonl 的字段完整性，确认它覆盖的 CVE 时间范围是否满足你的需求，并评估 GPL-3.0 许可证对商业集成的限制。如果你只需要 CVE 到 CAPEC 的映射，且不想引入整个 MITRE 框架链，可以考虑用 cve-search 或 Vulnogram 等更轻量的方案。最终判断：CVE2CAPEC 是一个有用的数据管道，但它的价值在于持续运行和结果积累，而不是单次查询的精度。
社区笔记