本文目录导读：
- 第一层：基础筛选（环境上下文）
- 第二层：量化评分模型（CVSS + 环境修正）
- 第三层：行业实战排序法（DREAD模型）
- 第四层：动态优先级调整（实战中的“特危险区”）
- 避坑指南（常见反例）
- 科学排序的三步决策树
漏洞优先级排序是安全运营中的核心难题,常见的“拍脑袋”排序往往导致资源错配，科学排序需要综合资产价值、威胁程度、可利用性和影响范围四个维度，并引入量化模型来减少主观偏差。
以下是一套被业界广泛验证的排序逻辑和方法：
第一层：基础筛选（环境上下文）
在考虑分数之前,必须回答三个前置问题：
- 该资产是否暴露于公网？
- 是：立即升级为高优先级，内网漏洞的风险通常远低于公网。
- 该资产是否承载关键业务（如核心数据库、身份认证系统、支付网关）？
- 是：风险等级乘以2。
- 是否已有公开的PoC（概念验证代码）或在野攻击？
- 是：无论CVSS（通用漏洞评分系统）分数多低，都应视为紧急。
科学起点：如果以上三个问题有一个答案为“是”，就不要单纯依赖CVSS分数，而是进入下一层加权排序。
第二层：量化评分模型（CVSS + 环境修正）
CVSS 3.1是目前最通用的基准，但它只描述漏洞“本身”的严重性，不描述对你“具体环境”的风险，科学排序必须修正它：
- 原始CVSS分数：基础分（0-10）。
- 环境因子：
- 权限要求（PR）：如果攻击者需要“管理员权限”才能触发，且该系统中很少有管理员登录，则降权。
- 用户交互（UI）：需要用户点击链接的漏洞（如钓鱼邮件）比无需交互的RCE（远程代码执行）漏洞（如Log4Shell）风险更低，除非目标用户是高权限人员。
- 攻击向量（AV）：本地攻击 < 相邻网络攻击 < 网络攻击。
- 修正公式：最终风险分 = CVSS_base × 环境因子 × 业务权重
举例：
- A漏洞：CVSS 9.0，存在于公网的管理后台（环境修正0.9），业务权重10（核心业务），最终分 = 9.0 × 0.9 × 10 = 81分。
- B漏洞：CVSS 9.8，存在于内网的非核心日志服务器（环境修正0.5），业务权重1，最终分 = 9.8 × 0.5 × 1 = 9分。 → ：A的修复优先级远高于B，尽管B的CVSS分更高。
第三层：行业实战排序法（DREAD模型）
如果你的团队需要直接决定“今天修哪个”，可以结合DREAD进行简单量化打分（每项1-10分）：
| 维度 | 核心问题 | 权重参考 |
|---|---|---|
| Damage（破坏力） | 被利用后会造成数据泄露、系统瘫痪还是业务中断？ | 40% |
| Reproducibility（可复现性） | 攻击者能否稳定触发？还是极其苛刻的条件？ | 20% |
| Exploitability（可利用性） | 是否需要特殊工具？是否有公开脚本？ | 20% |
| Affected users（受影响用户） | 影响多少用户？是全体员工（内网）还是全球客户（公网）？ | 10% |
| Discoverability（可发现性） | 攻击者能否通过常规扫描或搜索引擎（如Shodan）轻易发现？ | 10% |
排序策略：优先级 = Damage × 4 +（Reproducibility + Exploitability）× 2 + （Affected + Discoverability）× 1，得分最高的先修。
第四层：动态优先级调整（实战中的“特危险区”）
以下情况可以跳过所有分数计算，直接标记为紧急：
- APT（高级持续性威胁）组织正在利用的0-day：不管物理机还是虚拟机，直接断网或修补。
- 供应链核心漏洞：如涉及Log4j、Spring4Shell、OpenSSH这类底层组件，且你的应用直接调用。
- 涉及身份认证和支付的漏洞：如SSRF（服务端请求伪造）+ 云元数据泄露，或JWT（JSON Web令牌）密钥硬编码。
- 合规红线：GDPR（通用数据保护条例）、PCI-DSS（支付卡行业数据安全标准）等法规明确要求限期修复的漏洞。
避坑指南（常见反例）
- 不要只看CVSS分：一个CVSS 10.0的漏洞如果只存在于一个报废的演示服务器上，可能比一个CVSS 7.5的、存在于公网核心API上的漏洞更不重要。
- 不要忽略“蠕虫性”：即使CVSS只有中危（如6.5），但如果漏洞能被远程利用且无需认证、自动传播（如EternalBlue），应视为最高优先级，因为它会像病毒一样扩散。
- 静态扫描的误报：SAST（静态应用安全测试）工具常报高危（如SQL注入），但若该函数根本没有外部输入，或者输入经过了严格过滤，则需降级处理。
科学排序的三步决策树
- 第一问：攻击者能否直达关键资产？（公网 + 核心业务 = 紧急）
- 第二问：有没有现成的武器？（PoC/在野攻击 = 高）
- 第三问：修复它会影响业务吗？（补丁可能重启服务？降级评分，考虑虚拟补丁或WAF（Web应用防火墙）规则）
最终输出：建议团队采用 “定量 （CVSS+环境修正） + 定性 （DREAD/业务影响） + 威胁情报 （是否在野）” 的三维评分卡，每周或每天对托管资产进行复评，因为一个漏洞在昨天可能是低危，而今天因为出PoC变成了高危。
如果你们团队没有专门的SRC（安全响应中心）工具，可以用最简化的方式：把所有漏洞扔进一个共享表格，列出“是否公网”、“是否核心资产”、“是否有PoC”三列，然后排序。 这通常比复杂的模型更有效。
