16｜发现安全漏洞后怎么定级、怎么报告和跟进？

开场先给定级的两个标准维度——发现漏洞只是开始，推动修复并闭环才是价值兑现。

回答思路

第一步：双重定级再取高

维度	依据
技术维度	参考 CVSS——攻击复杂度、所需权限、影响范围、数据机密性完整性可用性算分
业务维度	按后果定——资损、批量用户数据泄露、服务中断、仅内部可见

国内业务更看重业务后果：支付篡改哪怕技术上手法简单也是最高级。双重定级取高的务实做法。

第二步：报告要素按「开发能直接修」的标准写

漏洞类型、攻击路径（一步步怎么利用的）、复现步骤（请求报文、payload、截图）、危害论证（能拿到什么、影响多少用户）、修复建议（对应防御方案）、环境信息。

写不出修复建议的漏洞报告是半成品——安全测试的专业度一半体现在建议质量上。

第三步：跟进流程讲闭环

提交 → 确认（防误报复核）→ 定级评审（安全或架构参与）→ 修复 → 复测验证（用原 payload 重放，注意修复是否引入新问题）→ 关闭沉淀（payload 进安全用例库做回归）。

闭环和 bug 生命周期同构，但多了「复测要防绕过」这层。

第四步：讲两个实战难点

• 修复推不动（业务方觉得「又没人攻击」）：用风险量化推动（监管处罚案例、行业事件）+ 升级机制（高危漏洞直通安全委员会）
• 延期风险（修复周期长）：先上临时缓解——WAF 规则、功能开关下线

收尾：讲沉淀

每次漏洞沉淀攻击样本和检查项，年度做漏洞趋势分析（哪类反复出现说明哪层薄弱）——安全测试要从救火走向体系。

考察重点

维度	说明
企业动机	大量企业有「安全测试做了但漏洞烂尾」的痛——企业要的是能把安全闭环跑通的人
过线标准	定级有依据 + 报告含修复建议 + 复测防绕过
区分度	讲修复推不动的推动策略、临时缓解手段的是真跟进过漏洞的
加分项	年度漏洞趋势分析驱动的体系化思维
减分项	报完漏洞就结束（「修不修是开发的事」），闭环意识为零

来源

整理自知识星球帖《面试情报 05｜安全测试 20 题》，返回题库。