双引擎依赖漏洞扫描：Dependency-Check与OSSIndex集成实战

每次给项目做安全体检，我都会问团队第一句话：你们的依赖漏洞扫描跑起来了吗？大部分团队都会点头，说自己接入了某个扫描工具。但再追问一句：这份扫描结果和你们上线时的依赖清单对得上吗？现场往往就沉默了。我在某项目的安全整改里遇到过最典型的情况——OWASP Dependency-Check 已经进了构建流程，NVD 漏洞库更新也很勤，结果发布前还是被一条来自 Sonatype 情报的漏洞记录拦了下来。原因倒不复杂：两个数据源的收录范围不一样，单靠其中任何一个都有视觉盲区。后来我把 Sonatype OSSIndex 作为第二道检测器接进同一套流水线，双份报告合并审计，漏报率肉眼可见地降了下来。这篇文章把我这段时间的集成思路、配置细节和踩过的坑一次讲清楚，适合正在做依赖安全治理、又不想被单一工具绑架的团队参考。

1. 为什么必须做双重检测：单一扫描器到底漏了什么

1.1 依赖漏洞是怎么钻进生产环境的

很多开发者对"依赖漏洞"的理解停留在"我引用的库有没有问题"。实际上，你项目里的依赖是一整棵树，根上是你直接引用的开源组件，枝枝叶叶里藏着大量传递依赖。真正出问题的，往往是那些没有出现在你 pom.xml 或 build.gradle 直接列表里的嵌套组件。

我接触过的某个模拟项目 X 就吃过这个亏。核心服务引用了某个日志组件，版本号很新，第一道扫描跑完没有报任何问题。但事实上，这个组件存在一个只在 Sonatype 漏洞情报里被收录、NVD 尚未同步的漏洞，导致扫描结果直接放行。等漏洞细节公开、利用代码扩散的时候，系统已经带病运行了两周。修的过程倒不难，升级版本就行，真正难受的是中间这段时间你完全不知道自己暴露了。

把这个场景放大到整个行业：依赖攻击已经成为供应链攻击最常见的入口，攻击者专门找那些"扫描器报不出来"的组件下手。你用的扫描器如果只有一个数据源，等于用一个人的视力去观察整个战场，总有死角。

1.2 两个数据源的建库逻辑天然不同

OWASP Dependency-Check 和 Sonatype OSSIndex 的核心差异，不在于扫描算法，而在于它们的"情报库"是怎么建起来的。

这里需要先解释一个背景。NVD（国家漏洞数据库）以 CVE 编号为入口，漏洞被厂商或研究员提交后，需要经过官方审核、补充 CPE 信息、同步到公开库。这个过程有明确的时间线，但也会有延迟。Dependency-Check 的主要数据来源就是 NVD，它拿 CVE 数据去匹配你项目里的组件，匹配方式包括组件包的哈希值、CPE 编号以及一些公开的漏洞指纹。

Sonatype OSSIndex 走的是另一条路。它的数据来自 Sonatype 对开源组件生态的持续分析，依赖 Maven 中央仓库、npm、PyPI 等多个生态的组件元数据，并整合了多家商业情报源的漏洞信息。查询方式也直接得多：直接把项目的组件坐标（groupId、artifactId、version，或者等价的包名和版本号）拿过去查，返回该组件版本是否存在已知漏洞、影响等级、修复版本等。

这两套体系各有侧重。NVD 是官方权威但收录有延迟；OSSIndex 对组件生态更敏感、更新更快，但也可能有极少数 CVE 因为匹配规则差异而漏报。它们不再互为替代，而是互为补充。单独用任何一个，都等于只带了一只眼睛出门。

1.3 双重检测真正解决的三类问题

第一类是"时间差造成的盲区"。一个漏洞从厂商公开到 NVD 收录，中间可能存在数天甚至数周的窗口期，而 Sonatype 这类商业情报源往往更早完成收录。双检测可以把这段窗口期尽量缩短。

第二类是"匹配机制造成的盲区"。NVD 的 CVE 记录依赖 CPE 信息，有些组件没有标准的 CPE 条目，Dependency-Check 只能靠哈希或名称去猜，容易漏。OSSIndex 直接用组件坐标查服务端数据库，命中逻辑更直接。两种机制各查一遍，覆盖面会明显变大。

第三类是"误报互证"。同一个漏洞，两个工具都报了，基本可以确认该修；只有一个工具报了，则值得人工确认一下这个组件的实际影响，而不是想当然地忽略。这种交叉验证在安全评审时非常有说服力，也能省去很多争论。

2. 工具能力拆解：两个扫描器各自的看家本领

2.1 OWASP Dependency-Check 的检测机制与数据链路

OWASP Dependency-Check 是一个开源工具，支持命令行、Maven 插件、Gradle 插件、Jenkins 插件等多种形态。它的检测链路大致分三步：先解析项目依赖树，识别出所有组件的名称、版本、哈希等信息；然后比对本地缓存的 NVD 数据，凡是能对应上的 CVE 全部捞出来；最后按 CVSS 风险等级生成报告。

这个工具有几个关键特性需要注意。第一，它默认会去 NVD 拉取数据，数据量不小，第一次跑可能极慢，后续因为有缓存会快很多。官方建议配置一个 NVD API Key 来提升下载速率，否则按经验来看，完整的数据库同步可能消耗大量时间，尤其是内网环境下。第二，它支持多种报告格式，包括 HTML、XML、JSON、SARIF、CSV 等，方便接入不同的展示和分析平台。第三，它的构建拦截能力很强，可以设定 CVSS 阈值，发现高危漏洞时直接让构建失败。

我最喜欢的是它的"哈希匹配"机制。有些组件没有官方 CPE 编号，但 NVD 记录里包含该组件的文件哈希，工具就能通过比对哈希找到对应漏洞。这种匹配方式在分析内网私有包时也有效，前提是你本地的 NVD 数据足够新。

需要注意一点：在 Windows 上运行 Dependency-Check 时，有可能会触发程序集分析器（Assembly Analyzer），拖慢扫描速度。如果你们的构建环境是 Windows，建议在配置里显式关掉它，能省不少时间。

2.2 Sonatype OSSIndex 的组件情报与 API 体系

Sonatype OSSIndex 是 Sonatype 提供的免费组件漏洞查询服务，用户可以通过 REST API 把项目坐标提交过去，拿到对应版本的漏洞清单。它的响应速度很快，针对 Maven 中央仓库的覆盖率尤其好，因为 Sonatype 本身深度参与开源组件生态的建设。

OSSIndex 的核验逻辑比哈希匹配更直接：你报上坐标，它查数据库，返回结果。没有本地数据同步，没有 CPE 模糊匹配，所以几乎没有因为"CPE 对不上"而漏报的情况。这一点在对比测试中给我留下很深的印象，不少 Dependency-Check 因为缺少 CPE 信息而放行的组件，在 OSSIndex 这边都能查出来。

同时它也有自己的评分体系，会把漏洞标为 critical、high、moderate、low 等不同级别，并尽量给出修复版本。这些信息对制定修复计划很有价值。

不过它也有短板。首先，它是在线 SaaS 服务，完全离线的内网环境基本用不了。其次，它依赖坐标查询，如果你的私有组件没有发布到公共仓库，OSSIndex 里自然没有对应记录。另外，个别非常新的 CVE 在收录时间上也可能滞后于 NVD。这些短板正好由 Dependency-Check 的本地哈希扫描来补。

2.3 核心能力对比表格

这张表能直观看出两个工具是互补的。Dependency-Check 强在本地全量扫描和离线可用，OSSIndex 强在在线情报更新快和坐标匹配精准。二者叠加，基本上把常见的数据源盲区堵住了。

2.4 为什么这对组合最划算

考虑过其他方案，也调研过商业级完整漏洞管理平台，但对于多数中小团队来说，Dependency-Check 加 OSSIndex 是性价比最高的组合。

商业平台确实体验好，界面漂亮、整合度高，但成本不低，而且要打通内部各种构建链路，往往需要专门的安全团队去维护。相比之下，这两个工具都能以插件形态直接嵌入 Maven 和 Gradle 构建生命周期，不需要额外部署服务端，也不需要购买许可证，唯一付出的就是配置时间和人力审计成本。

另一个原因是"渐进式落地"很平滑。你可以先只跑 Dependency-Check，等团队习惯看报告、有固定漏洞修复流程之后，再把 OSSIndex 加上。两个工具的产出格式不一致没关系，后面我会说怎么把两份报告合到一起用。

3. 集成实操：Maven 与 Gradle 工程的双通道配置

3.1 Maven 工程接入 Dependency-Check 的关键配置

先看 Maven 工程怎么接 Dependency-Check。在 pom.xml 的 build 节点里加入插件配置，正常绑定到 verify 阶段，让每次构建都自动做一次扫描。

<plugin> <groupId>org.owasp</groupId> <artifactId>dependency-check-maven</artifactId> <version>12.1.0</version> <configuration> <formats> <format>HTML</format> <format>JSON</format> <format>SARIF</format> </formats> <failBuildOnCVSS>7</failBuildOnCVSS> <suppressionFiles> <suppressionFile>suppressions.xml</suppressionFile> </suppressionFiles> <dataDirectory>${project.basedir}/.dependency-check-data</dataDirectory> <nvdApiKey>${env.NVD_API_KEY}</nvdApiKey> </configuration> <executions> <execution> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin>

几个参数逐个说明。

formats建议至少输出 HTML 和 JSON。HTML 给人工看，JSON 给后面的合并脚本和 CI 平台解析。SARIF 如果你用的是支持静态分析告警的代码平台，也建议加上。

failBuildOnCVSS是构建拦截阈值，我这边设的 7，也就是 CVSS 7 分及以上的漏洞直接中断构建。团队初期如果不想因为历史漏洞太多导致构建持续红，可以先设 9，等存量漏洞清完再逐步降到 7。

suppressionFiles是误报和白名单管理的关键，指向一个 suppression 配置文件。后面讲误报处理时再展开写法。

dataDirectory建议固定到项目本地目录，这样 NVD 数据缓存可以被多次构建复用，而不是每次从零拉取。

nvdApiKey强烈建议配。没有它，NVD 数据同步速度很慢，CI 里很容易超时。

注意版本差异：旧版本插件里构建拦截参数是failBuildOnCVSS，新版本也支持cvssScoreThresholdFailBuild。升级插件后如果发现参数不生效，优先查官方文档确认版本对应的参数名。

3.2 Maven 工程接入 OSSIndex 的几个核心参数

OSSIndex 的 Maven 插件是ossindex-maven-plugin，配置同样放在 pom.xml 里。

<plugin> <groupId>org.sonatype.ossindex.maven</groupId> <artifactId>ossindex-maven-plugin</artifactId> <version>3.2.0</version> <configuration> <failOnVulnerabilities>true</failOnVulnerabilities> <excludeVulnerabilityIds> <excludeVulnerabilityId>CVE-2023-12345</excludeVulnerabilityId> </excludeVulnerabilityIds> </configuration> <executions> <execution> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin>

failOnVulnerabilities含义很直接：只要查到任意漏洞就让构建失败。实际使用中，我建议团队初期先把它设成false，让插件只产出报告不做拦截，等团队的修复节奏跟上来再打开。因为 OSSIndex 的检出能力比 Dependency-Check 更激进，历史上积累的存量漏洞可能非常多，一上来就 fail 会让所有人都麻爪。

excludeVulnerabilityIds用于排除确认过的漏洞，比如某个 CVE 确实不影响你的使用方式，可以先排除，但要在备注里写清楚原因。

Maven 工程同时配上这两个插件后，构建时两个插件会先后执行，各自产出报告。这一步不需要额外脚本，纯粹靠插件本身的配置就能实现双通道扫描。

3.3 Gradle 工程两条扫描链路的配置示例

Gradle 工程的配置逻辑和 Maven 一致，只是语法不同。先看 dependency-check 插件。

plugins { id 'org.owasp.dependencycheck' version '12.1.0' } dependencyCheck { formats = ['HTML', 'JSON'] failBuildOnCVSS = 7 suppressionFiles = ['suppressions.xml'] dataDirectory = file('.dependency-check-data') }

再看 OSSIndex 插件。

plugins { id 'org.sonatype.ossindex.gradle' version '3.2.0' } ossindex { failOnVulnerabilities = false excludeVulnerabilityIds = ['CVE-2023-12345'] }

Gradle 插件市场里这两个插件的版本号更新节奏不太一样，具体版本以你接到的插件市场页面为准。配置完跑gradle dependencyCheck和gradle ossindex可以单独触发扫描，跑gradle build会按插件的任务依赖自动串联执行。

我在多个工程里实测下来，Gradle 工程的增量构建场景下，OSSIndex 插件默认会对所有配置的依赖都发起请求，如果依赖树很庞大，第一次跑可能偏慢。可以先用gradle ossindex --info观察它到底往 HTTP 接口发了多少请求，评估一下全量检查的耗时是否可接受。

3.4 阈值卡点与报告合并的统一设计

双通道跑起来之后，最要命的不是扫描，而是"两份报告怎么一起看"。各看各的一定会漏，我的做法是统一阈值和统一入口。

阈值设计上，我用了两档。CVSS 7 及以上，无论哪个工具报了，构建直接失败；CVSS 4 到 6.9，构建正常通过，但报告进入人工审计列表，由安全负责人按周复核；CVSS 4 以下，只记录不处理。OSSIndex 的等级映射到 CVSS 后，按同一套规则执行。

报告合并上，最简单实用的办法是把两个工具输出的 JSON 都收集到一个目录，然后用一个小脚本按组件坐标去重合并。不必引入复杂的安全平台，只要做到"同一个组件，两边结果并排一行"，就能大幅减少漏看。

合并脚本的核心逻辑其实很朴素：从 Dependency-Check 的 JSON 里提取组件坐标和 CVE 列表，从 OSSIndex 的 JSON 里提取同样字段，按groupId:artifactId:version做 key 合并，两边都有命中标记为"双确认"，只有单边命中的标记为"单边告警，需人工确认"。用 Python、Shell 甚至 Excel VBA 都能实现，关键看你们团队的日常工具链。

3.5 实操经验：版本兼容与参数陷阱

配置过程中我踩过几个比较典型的坑，列出来给大家做参考。

第一，Dependency-Check 新版本对 Java 版本有要求，老项目还在用 Java 8 的话，插件版本不能盲目升级，否则会直接构建失败。先看一眼官方支持的 Java 版本范围再决定升级，稳妥得多。

第二，Windows 构建机上如果没关 Assembly Analyzer，扫描耗时可能翻倍。Maven 配置里加一行：

<assemblyAnalyzerEnabled>false</assemblyAnalyzerEnabled>

Gradle 里对应的是：

dependencyCheck { assemblyAnalyzerEnabled = false }

第三，OSSIndex 插件对代理配置比较敏感。公司网络如果走的是 HTTP 代理，需要确保 Gradle 或 Maven 的代理设置对插件请求也生效，否则会遇到连接超时，而且报错信息不太直观。

4. Jenkins 流水线整合与定时扫描策略

4.1 双阶段扫描的 Jenkins Pipeline 示例

CI 里面最顺手的落地方式是 Jenkins Pipeline。我把双通道扫描拆成两个 stage，顺序是先本地扫描、后在线核验，这样即使 OSSIndex 因为网络问题挂掉，至少 Dependency-Check 的结果已经出来了。

pipeline { agent any stages { stage('Dependency-Check 安全扫描') { steps { sh 'mvn -B org.owasp:dependency-check-maven:check' } } stage('OSSIndex 在线核验') { steps { sh 'mvn -B org.sonatype.ossindex.maven:ossindex-maven-plugin:check' } } } post { always { archiveArtifacts artifacts: 'target/dependency-check-report.*,target/ossindex-report.*', allowEmptyArchive: true } } }

如果希望扫描结果不阻塞发布流程，而只是把风险暴露在报告里，可以把 fail 参数临时调低，或者在 stage 外面包一层catchError：

stage('OSSIndex 在线核验') { steps { catchError(buildResult: 'UNSTABLE', stageResult: 'FAILURE') { sh 'mvn -B org.sonatype.ossindex.maven:ossindex-maven-plugin:check' } } }

这样构建整体不会红，但每次扫描的结果会标记为不稳定，强制团队看到告警，又不会直接卡死交付流程。等漏洞清理得差不多了，再把这个兜底去掉，恢复硬卡点。

4.2 扫描性能优化：缓存、增量与数据更新节奏

Dependency-Check 最耗时的部分在 NVD 数据同步，而不是依赖解析。CI 场景下，我强烈建议把dataDirectory指向一个 Jenkins 工作区之外、可以持久复用的目录，比如统一的/opt/dependency-check-data。人数不多的团队，数据缓存目录甚至可以挂到共享存储上，流水线并行跑多个项目时，NVD 数据不用各自拉一遍。

NVD 目前支持增量数据更新，插件会自动处理，这个不用额外配置。但增量更新依赖上一次的本地快照，如果某个项目的dataDirectory指向临时目录，每次构建都从零开始，那性能就废了。所以这条必须优先确认。

升级节奏上，我的习惯是：发布流水线每次构建都跑 OSSIndex，因为它是在线查询，耗时可控；Dependency-Check 放在每日凌晨的定时构建里跑一次全量，或者每周跑两次。这样既保证日常发布的安全检查覆盖，又不会让每次构建都背上几分钟的数据同步开销。

OSSIndex 全量查询如果遇到超时，可以分模块扫描，而不是一次扫整个多模块工程。Maven 多模块工程中，逐个模块触发 OSSIndex 检查，请求量分摊开，成功率会高很多。

4.3 内网环境与私有仓库的离线扫描方案

完全离线内网是很多研发团队的真实处境。Dependency-Check 在这种情况下仍然可用：在能访问外网的机器上，提前执行一次完整的数据更新，把dataDirectory目录整个打包，拷贝到内网机器，再指定同样的dataDirectory路径离线运行即可。

# 外网机器上先执行 dependency-check.sh --updateonly # 把生成的 .dependency-check-data 目录拷到内网后 dependency-check.sh --scan /path/to/project --data /path/to/.dependency-check-data

OSSIndex 就麻烦了，它本质上依赖在线 API，内网环境基本用不了。如果你们的网络策略不允许开放外网，两套方案里只能保住 Dependency-Check 这一条线，OSSIndex 的部分改为人工定期在可联网的机器上导坐标表查询，再把结果带回内网登记。这个流程比较笨，但确实能运行。

如果你同时用 Nexus 或 Artifactory 管理依赖，可以把 OSSIndex 的查询请求走机器上的代理出去，只要运维放行特定的 HTTPS 域名即可。去申请出网权限的时候，记得把插件实际调用的接口域名和端口讲清楚，这样审批流程会顺利很多。

5. 常见问题与排查技巧实录

5.1 误报与漏报警告的处理思路

误报是跑安全扫描绕不开的话题。Dependency-Check 常被人诟病的是 CPE 匹配有时过于宽松，把不相关的组件匹配到了同一个 CPE 上；OSSIndex 相对好一些，但私有组件和自定义版本号偶尔也会查错。

处理误报的标准动作是写 suppression 文件，而不是在 Jenkins 配置里关掉整个扫描。Dependency-Check 的 suppression 文件长这样：

<?xml version="1.0" encoding="UTF-8"?> <suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd"> <suppress> <notes>误报：该私有组件未使用受影响代码路径</notes> <packageUrl>pkg:maven/com.example/demo-lib@1.0.0</packageUrl> <cve>CVE-2023-12345</cve> </suppress> </suppressions>

OSSIndex 插件里的excludeVulnerabilityIds是同样的目的，但需要注意，它只能按 CVE ID 排除，粒度不如 suppression 文件灵活。两个工具的排除名单都建议统一维护在仓库里，代码评审时可以看到，不要偷偷改。

真正的经验是：误报排除一定要写原因，要有日期和负责人。三个月后回头看，没有任何说明的排除记录基本等于埋雷，没人知道当初为什么排除，也不敢动它。

5.2 漏洞情报滞后怎么办

双通道扫描最常遇到的情况是同一个组件两边结果不一致。这时候不要急着认定谁对谁错，我先去两个数据源里分别查这个组件，重点看漏洞的收录时间。

如果 Sonatype 先收录、NVD 还没同步，一般以 Sonatype 的结果为准先做评估，同时留意 NVD 后续是否收录同一个 CVE 编号。反过来，如果 NVD 有、OSSIndex 没有，多半是组件坐标差异导致的漏匹配，可以手动把坐标换一个等价格式再查一次。两种情况下，修复版本优先看漏洞官方公告里的建议，不要只看单边的信息。

日常运营上，我建议每季度做一次存量漏洞复核，把两个工具的报告拉出来对一遍，确认哪些漏洞是已经修复了但从旧报告里遗漏的、哪些组件已经升级不需要再拦截的。扫完不治理，结果就是告警越来越多，最后谁都不看，这比不扫描更危险。

5.3 报告解读与修复优先级排序经验

拿到扫描报告，别急着只看 CVSS 分数。我团队现在排序时会被问三个问题：这个组件实际用在哪个模块，是否对公网暴露；有没有公开的利用代码；如果升级到修复版本，影响面有多大。

举个例子，两个 CVE 同样是 9.8 分，一个组件只在内网批处理任务里用到，一个组件是网关对外提供服务的核心依赖，那修复顺序完全不一样。前者可以排到版本迭代里，后者当天就得处理。CVSS 只代表漏洞本身的严重程度，不代表你系统的真实风险。

EPSS 也可以作为一个参考维度，它表示漏洞被实际利用的概率，数值越高越要优先处理。不过这类评分目前主要还是要到漏洞详情页去查，不能指望扫描器直接给你排好队列。

在排期上，我的习惯是每周固定一个时间段做"漏洞治理窗口"，不要求开发团队随时停下来处理安全问题，而是把修复任务当成常规迭代任务排期。安全不该是救火，它应该是流水线里的一个固定检查点。

5.4 高频问题速查表

这张表只覆盖了我实际遇到的高频问题。安全工具的报错信息往往比较隐晦，排查时多用--info或 debug 日志模式观察，能省很多时间。

最后再分享一个实操习惯。我把两份报告的合并脚本放在了 CI 的 post 阶段，每次构建都生成一张"依赖漏洞合并审计表"，同时输出到构建记录里。最开始团队成员都觉得多此一举，直到有一次合并表里发现某组件一边报 9.8 分、另一边完全没有记录，人工一查才发现是新漏洞刚刚进入其中一个数据源。双重检测的价值就体现在这种瞬间，它不保证绝对无漏，但至少把盲区的范围压到了你能看见的程度。