去年某次应急响应，漏洞分类一台边缘节点被植入后门，漏洞分类日志里看不到任何异常进程，漏洞分类流量也干净得像刚洗过的漏洞分类白衬衫。折腾两天，漏洞分类最后在固件里翻出一段十六进制代码——攻击者根本没碰操作系统，漏洞分类直接改写了网卡的漏洞分类Boot ROM。这事让我重新理解了漏洞分类的漏洞分类意义：它不是学术游戏，是漏洞分类决定你往哪个方向找、用什么工具挖、漏洞分类以及能不能在黄金四小时内定位问题的漏洞分类地图。

按触发位置分，漏洞分类最粗的漏洞分类切法是软件、硬件、漏洞分类协议三层。漏洞分类软件漏洞最常见，缓冲区溢出、SQL注入、竞态条件，都属于这层。但硬件漏洞才是真正让人头疼的。Spectre和Meltdown把CPU的推测执行单元变成了泄密通道，你没法通过打补丁彻底修好，只能靠微码更新缓解，性能还得打折。协议漏洞更隐蔽，TLS降级攻击、DNS缓存投毒，问题出在规范设计本身，所有实现者一起背锅。

换个角度，按成因分，能看清攻击面从哪来。输入验证缺失是经典款，二十年前的栈溢出和今天的命令注入，根子上是一回事——程序太信任外部数据。配置错误则是运维的噩梦，S3存储桶公开、Redis未授权访问，技术含量不高，但架不住量大。还有一类是逻辑缺陷，比如支付系统里把金额参数改成负数，或者越权查看他人订单。这类漏洞扫描器基本扫不出来，得靠人对着业务流程图一行行推。

我习惯再叠一层维度：利用条件。远程无需认证就能触发的，比如永恒之蓝，优先级最高。本地需要用户交互的，像恶意宏文档，危害次之但钓鱼成功率不低。物理接触才能利用的，比如冷启动攻击读取内存密钥，通常不在常规威胁模型里，但边境检查站和取证场景下就是另一回事了。

CVSS评分试图把这些维度量化，可实际用起来经常跑偏。一个CVSS 9.8的漏洞，如果组件根本没对外暴露，实际风险可能低于一个CVSS 6.5但直接面向互联网的接口。我见过团队拿着评分表排期，把高危但不可达的漏洞修了三轮，真正敞开大门的中危漏洞反而晾着。分类不是目的，是决策辅助。知道漏洞属于哪一类，才知道该派谁去修、修的时候会不会引入新问题、以及修完之后怎么验证。

还有个容易被忽略的分类：已知和未知。CVE编号体系管理的是已知漏洞，但攻击者手里往往攥着0day。分类框架对0day基本失效——你不知道它属于哪一类，因为还没人见过。这时候只能靠行为检测兜底，比如监控异常的子进程创建、非工作时间的敏感文件读取。分类是给已知世界用的，未知世界需要另一套逻辑。

写到这里想起一个老安全工程师的话：漏洞分类就像给疾病分科，分得再细，病人不会按科室生病。真正干活的时候，分类是起点不是终点。你拿到一个漏洞报告，先看它属于哪一类，然后立刻要问：这个分类下常见的利用链是什么？同类漏洞在系统里还有没有第二处？修复方案会不会被绕过？这些问题比分类标签本身重要得多。