4、CVE映射方法论：ATT&CK框架映射、CWE分类映射、软件物料清单（SBOM）关联
拿到一个CVE编号，光知道「哪个版本有漏洞」远远不够。你得回答三个灵魂拷问：攻击者怎么利用它？它属于哪类编码缺陷？我的软件里到底哪个组件中招了？
这就是CVE映射要干的事。说白了，就是把一个孤立的漏洞编号，挂到三个不同的坐标系上——ATT&CK、CWE、SBOM。我做了这么多年漏洞分析，可以负责任地告诉你：不做映射的CVE清单，就是一堆废纸。
4.1 ATT&CK框架映射：把漏洞翻译成攻击行为
MITRE ATT&CK是个知识库，记录了攻击者在各个阶段会干什么。CVE映射到ATT&CK，就是回答一个问题：这个漏洞能帮攻击者完成哪个战术动作？
我个人习惯把映射分成三步走：
- 识别利用入口——漏洞是通过网络触发？本地触发？还是需要用户交互？
- 匹配战术阶段——初始访问？执行？持久化？权限提升？
- 细化技术编号——找到具体的T编号，比如T1190（利用公开漏洞进行外部远程服务利用）。
举个例子：CVE-2021-44228（Log4Shell）。
- 战术：初始访问（TA0001）
- 技术：利用公开漏洞（T1190）
- 子技术：利用面向外部的远程服务（T1190.001）
映射完你就知道：这个漏洞是攻击者从外部打进来的敲门砖，不是内部提权的后手。
我在一次红蓝对抗复盘时发现，很多团队只关注CVE的CVSS分数，忽略了ATT&CK映射。结果呢？一个9.8分的远程代码执行漏洞，他们只修了内网入口，忘了检查VPN网关——因为ATT&CK映射会告诉你，这个漏洞的利用入口是「面向外部的服务」。你想想看，如果当时做了映射，是不是能少走弯路？
我的小技巧：ATT&CK Navigator是个好工具。把CVE映射结果导进去，能直接生成热力图，一眼看出哪个战术阶段风险最高。
4.2 CWE分类映射：从现象到根因
CWE是Common Weakness Enumeration，它描述的是「代码写错了什么」，而不是「攻击者干了什么」。CVE映射到CWE，就是给漏洞做病理分析。
举个例子：CVE-2017-11882（Office公式编辑器漏洞）。
- 现象：远程代码执行
- CWE根因：CWE-119（内存缓冲区错误）→ CWE-787（越界写入）
映射到CWE之后，开发团队就知道该修什么——不是修Office功能，而是修内存拷贝时的长度校验。
我见过最典型的翻车案例：一个团队收到CVE通报，发现是SQL注入，他们只修了那个接口的输入过滤。但CWE映射显示，根因是CWE-89（SQL注入），而CWE-89的父类是CWE-20（输入验证不当）。这意味着整个项目的输入校验框架都有问题。后来我帮他们重新梳理了所有输入点，才发现还有三个隐藏的注入点。嗯，这就是不做CWE映射的代价。
| CVE编号 | 现象描述 | CWE映射（根因） | 修复方向 |
|---|---|---|---|
| CVE-2021-44228 | JNDI注入导致RCE | CWE-917（表达式注入） | 禁用JNDI lookup、升级版本 |
| CVE-2022-22965 | Spring4Shell RCE | CWE-94（代码注入） | 升级Spring框架、修复参数绑定 |
| CVE-2023-34362 | MOVEit SQL注入 | CWE-89（SQL注入） | 参数化查询、升级软件 |
注意：一个CVE可能对应多个CWE。比如一个越界写入漏洞，可能同时触发CWE-787（越界写入）和CWE-122（堆缓冲区溢出）。映射时不要漏掉任何一个根因分类。
4.3 软件物料清单（SBOM）关联：找到「谁中了招」
SBOM就是软件的成分清单。CVE映射到SBOM，就是回答：这个漏洞影响了我项目里的哪个组件？版本对不对？
我习惯把SBOM关联分成四个步骤：
- 解析SBOM——拿到SPDX或CycloneDX格式的清单，提取所有组件名和版本号。
- 匹配CVE影响范围——看CVE描述里的受影响版本区间。
- 交叉比对——SBOM里的版本是否落在受影响区间内。
- 标记风险——命中则标记为「受影响」，否则标记为「不受影响」。
我曾经帮一个客户做供应链安全审计。他们的SBOM里有300多个组件，手动查CVE根本查不过来。后来我写了个脚本，把SBOM的CycloneDX格式直接喂给漏洞库API，自动匹配CVE。结果发现一个不起眼的日志库版本低了0.0.1，正好落在CVE-2021-44228的影响范围内。你猜怎么着？他们之前一直以为Log4Shell只影响2.14.1到2.15.0，但那个日志库是间接依赖，版本号被锁死在2.14.0。SBOM一关联，问题就现形了。
SBOM关联的核心价值：
- 从「我可能受影响」变成「我确定受影响」
- 从「全量升级」变成「精准修复」
- 从「人工排查」变成「自动化扫描」
4.4 三映射联动：一张图看清全貌
单独做ATT&CK映射、CWE映射、SBOM关联，每个都有用。但真正厉害的是把它们串起来。我画了张图，你看看这个逻辑：
你看这张图，CVE是中心，三个映射方向各自输出不同的价值：
- ATT&CK告诉你攻击者会怎么利用——决定修复的紧急程度
- CWE告诉你代码哪里写错了——决定修复的技术方向
- SBOM告诉你哪个组件中招了——决定修复的具体范围
三者合在一起，你才能做出「修不修、修哪里、怎么修」的综合决策。
实战建议：我建议你在漏洞管理平台里，给每个CVE都建一个映射卡片。卡片上至少包含ATT&CK T编号、CWE编号、SBOM组件名+版本。这样不管是安全团队、开发团队还是运维团队，拿到卡片就知道该干什么。
4.5 避坑指南：我踩过的三个坑
做CVE映射这些年，我踩过不少坑。挑三个最典型的说说：
坑一：ATT&CK映射只映射到战术，不映射到技术
我曾经只写到「初始访问」就停了。结果团队只知道这个漏洞是入口，但不知道具体怎么利用的。后来我补上了T1190，他们才意识到需要检查VPN和Web服务。记住：映射到技术编号才有实操价值。
坑二：CWE映射只映射叶子节点，忽略父类
CWE是个树状结构。比如CWE-787（越界写入）的父类是CWE-119（内存缓冲区错误）。如果你只映射到CWE-787，可能漏掉整个内存安全类的检查。我建议至少映射到二级父类。
坑三：SBOM关联只查直接依赖，忽略传递依赖
这是最要命的。很多CVE影响的是间接依赖，比如你的项目引用了A，A引用了B，B有漏洞。如果你只查直接依赖，B的漏洞就漏了。我建议用工具做依赖树分析，把传递依赖也纳入SBOM关联范围。
好了，CVE映射方法论就讲到这里。记住：ATT&CK、CWE、SBOM三个映射不是选择题，是必答题。少做一个，你的漏洞分析就不完整。