为什么必须先聚合
同一问题常被多个工具与多轮扫描重复上报：渗透测试报一次、漏扫报一次、SAST 又一次，规则 ID 各不相同但指向同一处代码或同一台主机。不聚合就会得到一张永远清不完的清单，修复进度也无法统计。去重的关键是设计好聚合键：资产标识加问题类型或编号，再加位置（URL、文件行号或端口）。
基本信息
| 聚合键 | 资产标识 + 问题编号/类型 + 位置 |
|---|---|
| 统一字段 | 资产、问题类型、编号、位置、等级、状态、首末次发现 |
| 已知项清单 | 历史已评估项自动关联，避免重复研判 |
| 统计口径 | 按资产汇总，按主编号去重 |
| 治理要求 | 去重规则要有评审记录 |
典型使用场景
- 多工具汇总：把漏扫、SAST、DAST 结果并入同一台账再派单
- 多轮扫描对比：同一问题连续出现时只更新最后发现时间，不重复建单
- 误报沉淀：研判为误报的条目进已知项清单，下轮自动关联
- 进度统计：按去重后的条目统计修复率，避免数字虚高
- 责任划分：按资产归属把聚合后的条目一次性派给对应团队
聚合键设计
聚合键设计
聚合键 = 资产标识 + 问题类型/编号 + 位置（URL/文件/端口）
- 同一资产同一 CVE 的多条命中 → 合并为一条，保留规则 ID 列表
- 同一漏洞在多个资产 → 保留明细，另做汇总统计
- 维护『已知项』清单：历史已评估项自动关联，避免重复研判
- 区分『首次发现』与『最后发现』两个时间字段，趋势分析需要数据规范建议
数据规范建议
统一字段：asset_id / finding_type / cve_id / location / severity / status / first_seen / last_seen
工具输出经转换脚本入库，报表与工单从同一数据源生成
状态取值固定：新增 / 已确认 / 已派单 / 已修复 / 已验证 / 已豁免 / 已关闭常见去重维度与注意点
| 维度 | 合并条件 | 注意点 |
|---|---|---|
| 同一资产同一编号 | 资产 + CVE/规则编号 | 位置不同可能是两处独立缺陷 |
| 同一资产多规则命中 | 资产 + 位置 | 规则重复导致的重复上报可合并 |
| 跨工具同问题 | 资产 + 位置 + 漏洞语义 | 需人工确认映射，工具命名差异大 |
| 跨轮次同问题 | 资产 + 编号 + 位置 | 只更新最后发现时间，不新建条目 |
去重规则要有评审记录：错误合并会把两个独立问题揉成一条，修复时只看一处，另一处被永久遗漏。
按标题字符串去重是常见误区：不同资产上的同一问题会被合并成一条，修复进度失真，最终没人相信台账。