一、报告整体模块划分
打开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 清单,用于企业合规归档;
- 过滤筛选:可按漏洞等级、许可证类型、组件风险标签筛选内容,简化排查。