一、报告整体模块划分
打开 scan_result.html，页面分为 6 大核心板块，按从上到下顺序解读：
Scan Summary（扫描总览）
Component Breakdown（组件清单）
License Analysis（许可证合规分析）
Vulnerabilities（安全漏洞清单）
File Match Details（文件匹配详情）
Dependencies（依赖组件）
二、分模块详细解读
1. Scan Summary 扫描总览（快速定位风险）
这是最优先查看的汇总面板，核心指标：
- Scanned Files：本次扫描总文件数
- Matched Components：识别到的开源组件数量
- Unique Licenses：项目包含的不同开源许可证种类
- Vulnerabilities Count：漏洞总数（分高危 / 中危 / 低危）
- Risk Level 综合风险等级：Low/Medium/High/Critical
快速判断：只要出现 Critical/High 风险，必须优先修复。
2. Component Breakdown 开源组件清单（SBOM 物料清单）
罗列项目中所有识别出的第三方开源库，每条组件包含：
Component Name & Version：组件名 + 版本号（如 log4j 2.14.0）
Source Origin：组件来源（Maven/NPM/Pypi/Git 开源仓库）
License：该组件对应的开源协议（MIT/Apache/GPL/AGPL 等）
Risk Tag：风险标签（Vulnerable、Copyleft License、Unknown License）
Matched File Count：项目内匹配到该组件的文件数量
重点关注两类组件：
- 带 Vulnerable：存在安全漏洞
- 带 Copyleft License：强传染型开源协议（GPL/AGPL），商用场景有代码开源合规风险
3. License Analysis 许可证合规分析（法务 / 合规重点）
协议分级说明
Permissive 宽松协议（低风险）：MIT、Apache-2.0、BSD
Weak Copyleft 弱传染协议（中风险）：LGPL
- 动态链接无强制开源要求，静态链接需要开放修改部分代码
Strong Copyleft 强传染协议（高风险）：GPLv2/GPLv3/AGPL
- 若项目商用分发（软件 / SAAS 服务），整个项目代码必须开源
Unknown License 未知协议（极高风险）：无法确认组件授权范围，存在侵权诉讼风险
页面功能
页面会统计每种协议的组件数量，提供协议原文链接、合规约束说明、企业规避建议。
4. Vulnerabilities 安全漏洞（安全 / 开发修复重点）
所有带漏洞的组件完整列表，每条漏洞字段：
CVE ID：通用漏洞编号（如 CVE-2021-44228 log4j 远程代码执行）
Severity 危险等级：Critical (严重) > High (高危) > Medium (中危) > Low (低危)
CVSS Score：漏洞评分（0~10 分，≥7 分为高危）
Affected Component & Version：受影响组件及版本
Fixed Version：修复漏洞的安全版本（核心修复依据）
Vulnerability Description：漏洞原理、可利用场景
Remediation Suggestion：官方修复方案
修复优先级：Critical/High 漏洞 → 中危漏洞 → 低危漏洞
5. File Match Details 文件匹配详情（溯源定位）
定位项目内哪些文件匹配到开源组件，解决问题溯源：
- 本地文件路径（如 D:\\xxx\\src\\log4j-core.jar）
- 匹配的开源组件名称、版本
- 匹配类型：完整文件匹配 / 代码片段片段匹配 作用：确认漏洞 / 合规风险具体出现在项目哪个文件，精准定位修改位置。
6. Dependencies 依赖树
展示组件依赖层级：A 组件依赖 B 组件，B 组件存在漏洞 / 合规问题，会清晰展示传递依赖关系。 解决痛点：很多漏洞并非直接引入，而是第三方依赖间接带入，此模块可完整梳理依赖链路。
三、标准化分析流程（企业合规 + 安全标准步骤）
步骤 1：查看扫描总览 Summary，快速识别高风险
查看综合风险等级；
统计 Critical/High 漏洞数量；
查看是否存在 GPL/AGPL 未知许可证组件。
步骤 2：安全漏洞修复处理
筛选 Critical、High 等级漏洞；
对照 Fixed Version 将组件升级至安全版本；
升级后重新扫描，确认漏洞消失；
中低危漏洞评估业务场景是否可利用，无法规避再升级。
步骤 3：开源许可证合规梳理
强传染协议（GPL/AGPL）
- 场景 1：项目仅内部使用、不对外分发：无强制开源风险；
- 场景 2：商用售卖、对外提供 SAAS 服务：必须替换为 MIT/Apache 宽松协议组件，或公开全部业务源码。
LGPL 弱传染
- 动态链接引用：合规无风险；
- 静态打包进程序：需要开放该组件修改后的代码。
Unknown 未知协议
步骤 4：文件溯源确认风险位置
针对高风险组件，在 File Match 页面查找项目内对应文件，确认是直接引入 Jar/NPM 包，还是代码片段复制，针对性删除 / 升级。
步骤 5：依赖链路排查传递依赖漏洞
若漏洞来自间接依赖，可通过两种方式处理：
升级上层依赖组件，间接修复底层漏洞；
使用依赖管理工具（Maven exclude、NPM overrides）强制替换漏洞子组件版本。
四、常见风险处理示例
示例 1：Log4j CVE-2021-44228（Critical 严重漏洞）
漏洞等级：Critical，CVSS 10 分，远程代码执行，攻击者可完全控制服务器；
处理：将 log4j 升级至 2.16.0 及以上安全版本；
验证：重新扫描 HTML 报告，该 CVE 消失。
示例 2：项目引入 GPLv3 组件（强传染协议）
风险：软件商用分发时，整个业务代码强制开源；
处理：替换功能等效的 MIT/Apache 协议开源库。
示例 3：未知许可证组件
风险：无明确授权，存在版权起诉风险；
处理：更换为协议清晰的替代组件。
五、补充实用功能
页面搜索框：可搜索组件名、CVE 编号、许可证名称，快速定位目标风险；
导出功能：HTML 支持导出完整 SBOM 清单，用于企业合规归档；
过滤筛选：可按漏洞等级、许可证类型、组件风险标签筛选内容，简化排查。
