别再拍脑袋定级了！一份给SRC新手的漏洞定级实战避坑指南（附常见漏洞对照表）

漏洞定级实战手册：从标准文档到真实决策的思维跃迁

第一次收到漏洞报告时，我盯着那份标着"高危"的XSS漏洞愣了十分钟——它真的配得上红色标记吗？三个月后，当我在团队复盘会上解释为什么将某个SQL注入降级处理时，突然意识到自己已经形成了某种"肌肉记忆"。这份手册正是要帮你跨越从标准文档到实战决策的鸿沟，它不是另一份冷冰冰的等级对照表，而是关于如何像安全专家一样思考漏洞风险的生存指南。

1. 定级前的认知重构：理解漏洞背后的博弈

1.1 资产视角：漏洞的舞台效应

同样的SQL注入漏洞，在电商平台的支付系统和员工食堂预约系统里完全是两个量级的安全事件。资产价值评估需要建立三维坐标：

• 业务关键性：直接影响核心营收的支付系统 vs 辅助性的意见反馈系统
• 数据敏感性：包含银行卡号的主数据库 vs 仅存储菜品偏好的缓存表
• 影响范围：全平台用户数据 vs 单个部门内部通讯录

实际操作中可建立简易评分卡：核心业务(3分)/重要业务(2分)/一般业务(1分)；敏感数据(3分)/普通数据(2分)/公开数据(1分)。当乘积≥6分时自动提升漏洞等级一级。

1.2 攻击路径的可实现性检验

某次内部演练中，我们收到一个"理论可行"的RCE报告，但实际测试发现需要同时满足：

1. 使用特定版本的Android客户端
2. 连接企业内网WiFi
3. 在UTC时间0:00-1:00之间触发

这类漏洞应该标注为：

| 条件维度 | 评估要点 | 等级影响 | |-----------------|---------------------------|----------| | 环境依赖 | 是否需要特殊网络/设备 | ↓1级 | | 时间窗口 | 是否限定特定时间段 | ↓0.5级 | | 用户交互 | 需要几次点击/输入 | ↓1级 | | 知识门槛 | 是否需要专业逆向技能 | ↓0.5级 |

1.3 漏洞组合的化学反应

去年某金融APP漏洞处理中最深刻的教训：单独评估时一个中危的URL重定向和一个低危的JSONP劫持，组合后形成了完整的OAuth劫持链。现在我们的定级检查清单包含：

• 是否可能形成漏洞链？（如SSRF+Redis未授权访问）
• 能否扩大影响范围？（如从单个用户到全员数据）
• 是否降低利用门槛？（如从代码执行变为界面点击）

2. 高频争议场景的定决策树

2.1 "这个XSS到底算存储型还是反射型？"

某内容平台的实际案例：

• 漏洞点：用户评论区的输入过滤缺陷
• 载荷存储：在数据库存留但每次展示时经过转义
• 触发条件：需要管理员在特定后台查看

这种情况我们最终定为"条件型存储XSS"，比典型存储型降一级处理。关键区分维度：

1. 持久化程度：
   • 完整存储：载荷完整保存在数据库/文件系统
   • 临时存储：仅在缓存或会话期间存在
2. 触发场景：
   • 自动触发：任何用户访问即执行
   • 条件触发：需要特定用户/操作流程

2.2 越权漏洞的"权限价值"评估

处理过200+越权案例后，我总结出权限的"含金量"公式：

权限价值 = (操作敏感性 × 数据覆盖面) / 认证强度

典型场景对照：

2.3 那些"理论上很严重"的漏洞

安全团队经常要处理这类报告："理论上可以获取系统权限，但需要先获得AWS IAM密钥"。我们的处理原则：

1. 建立利用成本评分表（5分制）：

   • 前置条件数量（每个+1分）
   • 所需专业知识等级（基础/进阶/专家）
   • 时间窗口要求（持续/瞬时）

2. 当总分≥4时，做降级处理并备注：

   "当前漏洞利用链不完整，建议持续监控相关系统"

3. 企业SRC的特殊考量

3.1 漏洞修复的"性价比"平衡

某次处理一个需要重构底层框架的CSRF漏洞时，我们最终给出的方案：

1. [临时方案] 增加关键操作二次确认（1人日） - 覆盖80%高风险场景 - 有效期6个月 2. [根本方案] 接入统一认证中间件（20人日） - 列入下季度技术债清理

对应的定级调整：

• 原等级：高危（直接影响资金操作）
• 调整后：中危（已有有效缓解措施）

3.2 第三方组件的"连带责任"

当发现Log4j2漏洞时，我们的资产测绘显示：

# 快速定位受影响服务 find / -name "log4j-core*.jar" | xargs grep -l "JndiLookup"

处理策略：

• 直接暴露公网的服务：48小时紧急修复
• 仅内网使用的服务：两周内常规更新
• 已EOL的旧系统：网络隔离+监控

3.3 漏洞的生命周期管理

建立漏洞的"健康档案"：

• 初次定级（基于标准）
• 动态调整（根据利用情报）
• 修复后评估（验证效果）

典型工作流：

graph TD A[初始报告] --> B{是否可复现?} B -->|是| C[标准定级] B -->|否| D[补充信息] C --> E[修复方案评估] E --> F[动态监控]

4. 从定级到沟通：避免踩坑的终极技巧

4.1 建立可追溯的决策记录

我们团队的定级模板包含：

## 漏洞ID：2023-XX-001 **核心考量因素：** - [x] 资产类型：核心支付系统（3分） - [x] 利用条件：需登录+特定参数（降1级） - [ ] 已知在野利用：未发现 **类似案例参考：** - 2022-45号漏洞（同组件不同入口） - 行业通报CVE-2023-XXX **最终定级：** 高危 → 中危（条件严格）

4.2 处理争议的"三段论"

当白帽子质疑定级时，我们采用：

1. 事实层：复现步骤中哪一步存在不确定性？
2. 标准层：参照哪条定级条款做出的判断？
3. 例外层：是否有未考虑的关联风险？

4.3 定级不是终点：修复资源的调度艺术

去年处理某API越权漏洞时的资源分配：

真正的专业度往往体现在把"中危"漏洞解释清楚的能力——为什么这个看起来很危险的漏洞不需要全员加班修复，以及我们有哪些保障措施。这比简单给漏洞贴标签困难得多，但也有价值得多。