部分修复的处理是什么
同一个漏洞条目往往覆盖多个接口或场景，客户这轮只修了一部分。处理的要点是按接口或场景粒度把状态拆开记录：已修复的部分附验证证据并关闭，遗留部分保持原有等级继续跟踪并重新排期，绝不把部分修复算成整体关闭。
基本信息
| 状态取值 | 已修复 / 部分修复 / 未修复 |
|---|---|
| 拆分粒度 | 按接口、角色或利用场景拆开 |
| 等级处理 | 遗留项保持原等级，不因部分修复降级 |
| 统计口径 | 部分修复不计入已关闭数量 |
| 证据要求 | 已修复部分必须有验证证据 |
典型使用场景
- 越权类问题：详情接口修了、导出接口还在越权
- 注入类问题：主参数做了过滤、排序字段仍可注入
- 上传类问题：后缀校验补齐、内容类型校验缺失
- 多角色场景：普通用户路径修了、管理员路径未覆盖
- 补丁受限：组件无法立即升级，先做部分缓解措施
状态记录示例
状态记录示例
F-01 订单越权（原高危）：
- 详情接口：已修复（返回 403，证据 E-21）
- 导出接口：未修复（仍可越权读取他人订单）
结论：部分修复；导出接口按高危继续跟踪
复测：针对遗留部分重新排期（下一窗口 11-05）
台账：状态列写“部分修复”，不计入已关闭状态判定与动作
| 情形 | 判定 | 后续动作 |
|---|---|---|
| 全部场景验证通过 | 已修复 | 关闭并归档证据 |
| 部分场景仍可利用 | 部分修复 | 遗留项保持等级并重新排期复测 |
| 缓解措施生效但根因未改 | 部分修复 | 注明缓解方式与失效条件 |
| 客户书面接受风险 | 风险接受 | 不写已修复，按接受流程登记 |
已修复部分同样要有验证证据：口头说明或开发自测结果都不构成状态变更依据，复测结论要能指向具体请求响应记录。
把部分修复写成已修复是复测环节最常见的失真：台账数字好看了，真实风险仍在线上，下一轮评估还会以同样方式被重新发现。