Dependency-Check报告深度解读：从HTML到SARIF的自动化安全实践

1. 项目概述：为什么我们需要解读Dependency-Check报告？

在软件开发的日常里，尤其是负责CI/CD流水线或者安全审计的工程师，对“依赖项安全检查”这个词一定不陌生。我们常常会运行一个扫描工具，比如OWASP Dependency-Check，然后生成一份报告，任务就算完成了。但很多时候，这份报告就像一个黑盒子——我们看到了红色的“高危”警告，却不知道它具体意味着什么，更不清楚该如何高效地处理。是直接升级版本？还是寻找替代库？或者这根本就是一个误报？这份报告，究竟是安全工作的终点，还是真正安全治理的起点？

OWASP Dependency-Check是一款强大的开源软件成分分析工具，它能扫描项目中的第三方依赖库，并与国家漏洞数据库等数据源进行比对，识别出已知的安全漏洞。它默认生成的HTML报告，界面友好，颜色醒目，非常适合人工快速浏览。然而，当我们需要将安全扫描集成到自动化流程中，或者需要将结果与其他工具（如代码质量平台、安全信息与事件管理系统）进行联动时，HTML格式就显得力不从心了。这时，SARIF格式就成为了关键。

SARIF，全称静态分析结果交换格式，是一种由微软主导制定的、用于在不同静态分析工具之间交换结果的标准化格式。它就像是安全扫描领域的“通用语言”。一份Dependency-Check的SARIF报告，不再是给人“看”的网页，而是给机器“读”的结构化数据。它能精确地描述漏洞的位置、严重等级、修复建议，甚至可以直接被GitHub Advanced Security、Azure DevOps等平台解析，自动创建问题工单或阻断流水线。

所以，仅仅运行dependency-check --scan . --format HTML生成报告是远远不够的。真正的价值在于“解读”——理解HTML报告中的每一个细节，并掌握如何将其转化为更强大、更自动化的SARIF数据流。这篇文章，我将结合自己多年在DevSecOps实践中踩过的坑，带你从零开始，深度拆解Dependency-Check的HTML报告，并详解如何将其转换为SARIF格式，以及如何利用SARIF实现安全左移和自动化治理。无论你是刚接触安全扫描的开发者，还是希望优化现有安全流程的运维工程师，都能从中找到可落地的实操方案。

2. HTML报告深度解析：从颜色警报到漏洞真相

默认情况下，Dependency-Check生成的HTML报告是我们接触最多的形式。它内容丰富，但信息密度也高，如果不了解其结构，很容易被满屏的红色和黄色搞得不知所措。我们首先来彻底拆解这份报告，看懂每一个数字和标签背后的含义。

2.1 报告首页：项目安全态势总览

运行扫描后，打开生成的dependency-check-report.html，首先映入眼帘的是报告首页。这里有几个关键模块需要你重点关注：

  1. 项目信息与扫描摘要：顶部会显示扫描的项目名称、报告生成日期，以及最重要的——扫描的依赖项总数和被发现存在漏洞的依赖项数量。这是对你项目安全状况最直观的“体检报告”。例如，“Scanned Dependencies: 152” 和 “Vulnerable Dependencies: 8” 意味着在152个依赖中，有8个被标记为有问题。

  2. 严重性分布饼图/条形图：通常以可视化图表展示漏洞按CVSS评分等级的分布情况。CVSS评分范围是0-10，一般分为：

    • 严重：9.0 - 10.0 （红色）
    • 高危：7.0 - 8.9 （橙色）
    • 中危：4.0 - 6.9 （黄色）
    • 低危：0.1 - 3.9 （蓝色）
    • 信息：0.0 （灰色） 这个图表让你一眼就能判断问题的严重程度集中在哪里。如果全是红色高危，那可能意味着依赖版本过于陈旧，需要立即安排升级。

  3. 依赖项列表：这是报告的核心。列表会展示所有被扫描的依赖，并突出显示有漏洞的项。每一行通常包含：

    • 依赖名称：如log4j-core
    • 文件路径：该依赖JAR包或文件在项目中的具体位置。
    • 证据：Dependency-Check是如何识别出这个依赖的（例如，通过META-INF/MANIFEST.MF中的Implementation-Title，或文件名匹配）。
    • 最高严重性：该依赖所有漏洞中的最高CVSS分数对应的等级标签。
    • CVE数量：该依赖关联的CVE漏洞总数。

注意：这里有一个常见的误解点。“CVE数量”多不一定代表风险更高。一个依赖可能关联了10个低危CVE，而另一个依赖只关联了1个严重CVE。决策时，必须结合最高严重性等级和CVSS分数来综合判断，优先处理严重和高危问题。

2.2 依赖项详情页：漏洞的完整上下文

点击有漏洞的依赖项名称，会进入该依赖的详情页。这里的信息才是我们进行漏洞分析和修复决策的依据。详情页通常分为几个部分：

  1. 依赖概览：再次显示依赖标识、文件路径和识别证据。这里要仔细核对“证据”，有时工具会误判（例如，将内部编写的、命名类似知名库的文件误识别为漏洞库）。这是判断是否为“误报”的第一道关卡。

  2. 漏洞列表：列出该依赖涉及的所有CVE漏洞。每个CVE条目会包含：

    • CVE编号：如 CVE-2021-44228。你可以复制此编号到NVD官网进行更详细的查询。
    • CVSS评分：基础评分，通常显示v2或v3版本。v3评分通常更严格。
    • 严重性：根据评分划分的等级。
    • 描述：漏洞的简要说明，包括攻击向量、影响等。
    • 受影响版本范围：明确指出哪个版本区间的该依赖存在此漏洞。这是修复的关键信息！格式通常为[2.0-beta9, 2.12.4)或(, 2.15.0)，表示漏洞在2.15.0版本之前的所有版本中存在。
    • 修复版本：如果已知，会给出修复了该漏洞的最低版本号。例如，“Upgrade to org.apache.logging.log4j:log4j-core version 2.16.0 or later.”

  3. 参考链接：提供指向NVD、MITRE CVE详情页、漏洞公告（如GitHub Advisory）的链接。在决定修复方案前，务必点开这些链接，了解漏洞的具体利用条件和实际影响。有些高危漏洞可能需要在非常特定的配置下才能被利用，实际风险可能低于评分。

2.3 关键指标与误报识别

在解读HTML报告时，除了看漏洞，还要学会看一些“隐藏”信息：

  • 证据可信度：Dependency-Check通过多种“证据”来识别一个依赖，包括文件名、文件内容中的哈希值、Manifest文件中的属性等。证据越多、越强，识别就越准确。如果某个依赖仅通过“文件名”识别，而该文件名又很通用（如utils.jar），那么误报的可能性就很大。
  • 漏洞匹配的精确度：工具会尝试将依赖的版本号与漏洞影响的版本范围进行匹配。如果无法确定依赖的确切版本（例如，只通过SHA1哈希识别），它可能会报告该依赖“可能”受多个漏洞影响，这时需要人工介入核实。
  • 已抑制的漏洞：如果你使用了--suppression参数提供了抑制文件，报告中会明确显示哪些漏洞被抑制了，并说明抑制原因。定期审查这些被抑制的条目，确保抑制仍然是合理的（例如，漏洞是否在新版本中已被修复？）。

实操心得：HTML报告人工审查流程我通常会按照以下步骤快速审查一份HTML报告：

  1. 看首页摘要：了解漏洞数量和严重性分布，对工作量有个预估。
  2. 筛选排序：在依赖列表页面，通常可以按“最高严重性”或“CVE数量”排序。优先查看“严重”和“高危”项。
  3. 深入详情：点击每个高危依赖，核心看两点：受影响版本范围和修复版本。确认当前项目使用的版本是否在受影响范围内。
  4. 评估风险：点击CVE参考链接，阅读漏洞描述。判断该漏洞在项目的实际运行环境中是否可被利用（例如，一个反序列化漏洞在仅内部使用的服务中，风险可能低于暴露在公网的服务）。
  5. 制定行动：根据风险高低和修复成本（升级版本是否会导致不兼容），决定立即修复、计划修复或申请误报抑制。

3. SARIF格式详解：机器可读的安全报告

当我们说“自动化安全”，核心就是让机器理解安全扫描的结果。HTML是给人看的富文本，而SARIF是为机器和自动化平台设计的结构化数据。Dependency-Check通过--format SARIF参数可以生成这种格式的报告（通常是一个.sarif或.json文件）。

3.1 SARIF文件结构剖析

一个典型的Dependency-Check SARIF输出文件是一个JSON对象，结构遵循SARIF标准。我们拆开看关键部分：

{ "$schema": "https://json-schema.org/sarif-2.1.0.json", "version": "2.1.0", "runs": [ { "tool": { "driver": { "name": "Dependency-Check", "fullName": "OWASP Dependency-Check", "version": "8.0.0", "informationUri": "https://owasp.org/www-project-dependency-check/" } }, "artifacts": [...], // 被扫描的文件列表 "results": [...], // 扫描发现的问题（漏洞） "taxonomies": [...], // 可能使用的分类法（如CWE） "invocations": [...] // 工具执行的具体信息 } ] }

对于安全结果集成，我们最关心的是results数组。里面的每一个对象都代表一个被发现的漏洞。Dependency-Check会将一个依赖的每个CVE都映射为一个独立的result。

3.2 关键字段映射：从CVE到SARIF

我们来看一个result对象的示例，理解Dependency-Check是如何将漏洞信息编码进去的：

{ "ruleId": "cve-2021-44228", "level": "error", "message": { "text": "Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j version 2.15.0, this behavior has been disabled by default. From version 2.16.0, this functionality has been completely removed. The simplest mitigation is to upgrade to log4j 2.16.0 or later." }, "locations": [ { "physicalLocation": { "artifactLocation": { "uri": "file:///project/target/lib/log4j-core-2.14.1.jar" }, "region": { "startLine": 1 } } } ], "properties": { "dependency-check": { "packageName": "org.apache.logging.log4j:log4j-core", "packageVersion": "2.14.1", "packagePath": "/project/target/lib/log4j-core-2.14.1.jar", "vulnerability": { "name": "CVE-2021-44228", "cvssv2": { "score": 10.0, "severity": "HIGH" }, "cvssv3": { "score": 10.0, "severity": "CRITICAL" }, "cwes": ["CWE-917"], "description": "...(详细描述)...", "references": [ {"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228"} ] } } } }
  • ruleId: 通常直接使用CVE编号。这是该类型问题的唯一标识符。
  • level: 表示严重级别，映射自CVSS分数。error对应严重/高危，warning对应中危，note对应低危/信息。这个字段被CI/CD平台用来决定是否失败。
  • message.text: 包含了漏洞的详细描述，通常是从NVD抓取的摘要。
  • locations: 指明了漏洞所在的物理位置。对于依赖扫描，uri指向包含漏洞的JAR、NPM包等文件。startLine对于二进制依赖通常为1，对于源码文件则有具体行号。
  • properties.dependency-check: 这是Dependency-Check自定义的扩展属性，包含了最丰富的上下文信息，是自动化处理的核心：
    • packageName&packageVersion: 漏洞组件的精确坐标。
    • vulnerability.cvssv3.score: 自动化决策最重要的依据。你可以写一个脚本，只处理分数高于某个阈值（如7.0）的问题。
    • vulnerability.references: 提供了权威信息来源链接。

3.3 SARIF的优势与自动化潜力

与HTML报告相比，SARIF格式在自动化场景下具有压倒性优势：

  1. 结构化与无歧义：每个字段都有明确含义和固定类型，方便程序解析。不再需要像解析HTML一样进行脆弱的文本抓取。
  2. 完整的漏洞上下文：将所有必要信息（包名、版本、CVE、CVSS、修复版本）打包在一个JSON对象里，下游系统无需二次查询。
  3. 与DevOps平台原生集成：
    • GitHub Advanced Security： 可以将SARIF文件上传至GitHub，自动在仓库的“Security”标签页下显示漏洞告警，并关联到具体的提交和依赖文件。
    • Azure Pipelines / GitLab CI： 有专门的SARIF结果发布任务，能将漏洞可视化为流水线报告，并可根据规则设置质量门禁。
    • Jenkins： 通过插件（如“Warnings Next Generation Plugin”）可以解析SARIF文件，生成趋势图表和详细问题列表。
  4. 自定义分析与聚合：你可以编写简单的脚本（Python、JavaScript等），对SARIF结果进行过滤、聚合、统计。例如，找出所有影响特定团队项目的严重漏洞，或者按周生成漏洞趋势报告。

注意：虽然SARIF强大，但Dependency-Check生成的SARIF报告可能不包含“修复版本”这个对自动化修复至关重要的信息。这个信息有时存在于HTML报告中，但在SARIF的message或properties字段里可能找不到。在构建自动化修复工作流时，可能需要额外调用NVD API或依赖其他工具（如Renovate, Dependabot）来获取准确的修复版本。

4. 从HTML到SARIF：生成、转换与集成实战

了解了两种格式的差异后，我们来实战如何生成并利用它们。通常，我们不会手动转换，而是直接生成SARIF格式，或者同时生成多种格式以备他用。

4.1 命令行生成与参数详解

最基本的生成命令如下：

# 生成HTML报告（默认） dependency-check.sh --project "MyApp" --scan ./path/to/your/project --out ./reports # 生成SARIF报告 dependency-check.sh --project "MyApp" --scan ./path/to/your/project --format SARIF --out ./reports # 同时生成HTML和SARIF报告 dependency-check.sh --project "MyApp" --scan ./path/to/your/project --format HTML --format SARIF --out ./reports

关键参数解析：

  • --project： 给本次扫描命名，会出现在报告标题中，便于区分。
  • --scan： 指定要扫描的路径。可以指定多个路径，也支持Ant风格的通配符（如**/*.jar）。
  • --format： 指定输出格式。可以多次指定以生成多种格式。
  • --out： 输出目录。如果只生成一种格式且未指定文件名，SARIF会默认命名为dependency-check-report.sarif。
  • --failOnCVSS：自动化流水线的关键参数。设置一个CVSS分数阈值（0-10），当扫描发现任何漏洞的分数等于或高于该阈值时，工具会以非零退出码结束。例如，--failOnCVSS 7表示发现高危及以上漏洞时，命令执行失败。这可以直接用于CI/CD流水线的质量门禁。

高级配置示例：一个更贴近生产环境的扫描命令可能长这样：

dependency-check.sh \ --project "MyApp-Production-Scan" \ --scan "./target/*.jar" \ --scan "./node_modules" \ --exclude "./target/*-tests.jar" \ # 排除测试依赖 --format HTML \ --format SARIF \ --format JSON \ # JSON格式便于自定义脚本处理 --out "./security-reports" \ --failOnCVSS 4 \ # 中危及以上即失败 --suppression "./security/dependency-check-suppressions.xml" \ # 误报抑制文件 --nvdApiKey "$NVD_API_KEY" \ # 使用NVD API Key提升数据更新速率和配额 --data "/opt/dependency-check-data" # 指定数据目录，避免每次下载

4.2 在CI/CD流水线中集成

将Dependency-Check与SARIF集成到CI/CD中，是实现安全左移的标准做法。以下是一个GitHub Actions工作流的示例：

name: Security Scan on: [push, pull_request] jobs: dependency-check: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Set up JDK uses: actions/setup-java@v3 with: java-version: '11' distribution: 'temurin' - name: Build project (generate dependencies) run: mvn compile -DskipTests # 假设是Maven项目，先编译出依赖包 - name: Run OWASP Dependency-Check uses: dependency-check/Dependency-Check_Action@main with: project: 'MyApp-GitHub-${{ github.ref_name }}' path: '.' format: 'SARIF' out: './reports' args: >- --failOnCVSS 7 --suppression "./.github/dependency-check-suppressions.xml" --nvdApiKey ${{ secrets.NVD_API_KEY }} - name: Upload SARIF results to GitHub Security uses: github/codeql-action/upload-sarif@v2 if: always() # 即使扫描失败也上传结果 with: sarif_file: './reports/dependency-check-report.sarif'

这个工作流做了几件事：

  1. 在代码推送或拉取请求时触发。
  2. 编译项目以确保依赖文件存在。
  3. 运行Dependency-Check，指定输出SARIF格式，并设置CVSS>=7时失败。
  4. 使用GitHub官方的upload-sarif动作将结果上传。上传后，漏洞会出现在仓库的“Security”->“Code scanning alerts”标签页下，与代码问题并列展示。

在Jenkins中的集成示例（使用声明式流水线）：

pipeline { agent any stages { stage('Dependency Check') { steps { script { // 1. 运行扫描 sh ''' dependency-check.sh \ --project "${env.JOB_NAME}-${env.BUILD_NUMBER}" \ --scan "**/*.jar" \ --format SARIF \ --format HTML \ --out "${WORKSPACE}/reports" \ --failOnCVSS 7 ''' // 2. 检查退出码，决定是否失败 // `--failOnCVSS` 已处理，此步可省略或做日志记录 } } post { always { // 3. 使用Warnings Next Generation Plugin发布报告 dependencyCheckPublisher pattern: 'reports/dependency-check-report.sarif' // 4. 归档HTML报告以便人工查看 archiveArtifacts artifacts: 'reports/*.html', fingerprint: true } } } } }

4.3 结果后处理与自定义分析

生成了SARIF文件后，你可以用脚本对其进行深度处理，生成定制化的洞察。以下是一个使用Python脚本的简单示例，用于提取严重漏洞并生成摘要：

import json import sys def analyze_sarif(sarif_file_path): with open(sarif_file_path, 'r') as f: data = json.load(f) critical_vulns = [] for run in data.get('runs', []): for result in run.get('results', []): # 从自定义属性中获取CVSSv3分数 props = result.get('properties', {}) dep_check = props.get('dependency-check', {}) vuln = dep_check.get('vulnerability', {}) cvssv3_score = vuln.get('cvssv3', {}).get('score', 0) if cvssv3_score >= 9.0: # 定义“严重”阈值 critical_vulns.append({ 'cve': vuln.get('name'), 'package': dep_check.get('packageName'), 'version': dep_check.get('packageVersion'), 'file': result['locations'][0]['physicalLocation']['artifactLocation']['uri'] if result.get('locations') else 'N/A', 'cvss_score': cvssv3_score, 'description': result['message']['text'][:200] + '...' # 截取部分描述 }) # 输出摘要 print(f"发现 {len(critical_vulns)} 个严重漏洞：") for vuln in critical_vulns: print(f"- CVE: {vuln['cve']}") print(f" 组件: {vuln['package']}@{vuln['version']}") print(f" 路径: {vuln['file']}") print(f" 评分: {vuln['cvss_score']}") print(f" 简述: {vuln['description']}\n") # 也可以输出为Markdown或JSON，方便集成到Wiki或通知系统 return critical_vulns if __name__ == '__main__': if len(sys.argv) != 2: print("Usage: python analyze_sarif.py <path_to_sarif_file>") sys.exit(1) analyze_sarif(sys.argv[1])

这个脚本展示了如何从SARIF中提取关键信息。你可以扩展它，比如将结果发送到Slack频道、生成JIRA工单，或者与资产管理系统关联，标记存在漏洞的服务。

5. 常见问题、误报处理与进阶技巧

在实际使用中，你一定会遇到各种问题。下面是我总结的一些典型场景和解决方案。

5.1 高频问题排查指南

问题现象可能原因解决方案
扫描速度极慢1. 首次运行需下载完整的NVD数据库（几百MB）。
2. 网络连接NVD或OSS Index不畅。
3. 扫描路径包含大量文件（如node_modules）。		1. 使用--nvdApiKey加速NVD数据获取。
2. 使用--noupdate跳过更新（仅限已存在本地数据库时）。
3. 使用--exclude排除**/node_modules/**等非必要目录。
4. 考虑设置本地NVD数据镜像。
报告大量误报1. 依赖通过弱证据（如文件名）被识别。
2. 扫描了包含依赖的测试包或源码包。
3. 漏洞数据库匹配错误。		1. 审查“证据”部分，确认依赖标识是否正确。
2. 使用--exclude排除测试包（如*-tests.jar）。
3. 创建并维护抑制文件，屏蔽确认为误报的条目。
--failOnCVSS未生效1. 命令语法错误或参数位置不对。
2. 工具版本过旧不支持该参数。
3. 扫描本身失败，未生成有效结果。		1. 确保参数格式正确，放在--scan参数之后。
2. 升级Dependency-Check到最新版本。
3. 检查扫描日志，确保依赖被正确识别和分析。
SARIF报告中缺少修复版本Dependency-Check的SARIF输出默认可能不包含修复版本信息。1. 检查HTML报告，修复版本信息通常在那里。
2. 考虑在后续流程中，结合SARIF中的CVE编号，调用NVD API或使用其他工具（如osv.devAPI）查询修复版本。
无法识别某些语言依赖对应语言的实验性分析器未启用。使用--enableExperimental启用所有实验性分析器，或使用特定启用参数，如--disablePyDist false。

5.2 误报抑制实战

误报是SCA工具的常态。Dependency-Check使用XML格式的抑制文件来忽略特定漏洞。学会编写抑制文件是高效使用该工具的关键技能。

一个基本的抑制文件suppressions.xml如下：

<?xml version="1.0" encoding="UTF-8"?> <suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd"> <!-- 1. 根据GAV坐标抑制特定组件的所有漏洞 --> <suppress> <notes><![CDATA[ 这是一个内部修改的库，虽然版本号在受影响范围内，但我们已打了补丁。 ]]></notes> <packageUrl regex="true">^pkg:maven/org\.example/internal-utils@.*$</packageUrl> <cve>CVE-2023-12345</cve> </suppress> <!-- 2. 抑制特定文件的所有漏洞（慎用） --> <suppress until="2024-12-31"> <notes><![CDATA[ 这个老旧的jar文件仅用于兼容性测试环境，无网络访问权限，风险可接受。 设置until日期，提醒到期后重新评估。 ]]></notes> <filePath regex="true">.*/legacy-compat-test\.jar$</filePath> </suppress> <!-- 3. 抑制基于弱证据（仅文件名）匹配的漏洞 --> <suppress> <notes><![CDATA[ 该文件名为common-utils.jar，但内容与公开漏洞库完全不同，是误报。 ]]></notes> <sha1>a1b2c3d4e5f6789012345678901234567890abcd</sha1> <!-- 实际文件的SHA1哈希 --> <cve>CVE-2021-XXXXX</cve> </suppress> <!-- 4. 抑制某个CVE在所有组件上的报告（更慎用） --> <suppress> <notes><![CDATA[ 该CVE影响的是Windows特定功能，我们的服务全部运行在Linux上。 ]]></notes> <cve>CVE-2022-XXXXX</cve> </suppress> </suppressions>

编写抑制文件的核心原则：

  1. 精确抑制：尽量使用最具体的标识符，如<sha1>（文件哈希）或完整的<packageUrl>，避免使用宽泛的<filePath>正则表达式。
  2. 注明原因：在<notes>中清晰记录抑制理由、负责人和评估日期。
  3. 设置有效期：使用until属性为临时抑制设置过期时间，强制定期复审。
  4. 版本控制：将抑制文件纳入代码仓库管理，方便审计和团队协作。

5.3 进阶技巧与优化建议

  1. 使用NVD API Key：从NVD官网免费申请API Key，并通过--nvdApiKey参数使用。这能大幅提高数据下载速度，并避免因频繁访问而被限流。
  2. 配置数据镜像：对于内网环境或需要稳定数据源的情况，可以搭建本地的NVD数据镜像，并通过--nvdDatafeed参数指向它。
  3. 分层扫描策略：
    • PR/合并请求检查：使用较严格的--failOnCVSS 4（中危即失败），快速反馈，防止新漏洞引入。
    • 主干/每日构建：使用--failOnCVSS 7（高危失败），并生成完整的HTML和SARIF报告，用于深度分析和历史跟踪。
    • 发布前审计：运行最全面的扫描，启用所有分析器，并人工审查所有中危及以上漏洞的抑制条目。
  4. 与其他工具互补：Dependency-Check擅长已知CVE漏洞。结合使用软件物料清单工具（如Syft, CycloneDX）来生成完整的SBOM，再结合许可证扫描工具（如ScanCode, FOSSA）来管理合规风险，形成完整的安全与合规流水线。
  5. SARIF结果聚合：如果你有多个微服务项目，可以为每个项目生成SARIF报告，然后编写脚本将所有SARIF文件合并，生成一个全局的安全态势视图，便于管理层查看。

解读Dependency-Check报告，从看懂HTML到驾驭SARIF，是一个从被动接受到主动治理的过程。HTML报告是你的“显微镜”，用于深入观察每一个漏洞细节；而SARIF报告则是你的“自动化流水线”，将安全洞察转化为可编程、可集成的行动。将两者结合，并建立起包含扫描、分析、抑制、修复、审计的完整闭环，才能真正让依赖项安全管控成为软件开发中坚实可靠的一环。