Dependency-Check 抑制 Swagger UI 漏洞时 XML 报错怎么办？

2026-11-04数据阿明

结论

同一个 <suppress> 中，<filePath> 和 <packageUrl> 只能选一个。保留用于定位依赖的条件，再列出要抑制的 <vulnerabilityName>。

两个条目报告的 PURL 都是 pkg:javascript/DOMPurify@3.2.6，可以先用 packageUrl 规则。但这条规则也会覆盖扫描范围内其他 PURL 相同的依赖条目。

为什么会报错？

题中使用的 suppression 1.3 XSD 将 filePath、sha1、gav 和 packageUrl 放在同一个 xs:choice 中，且 maxOccurs="1"，因此只能选择其中一个。后面才是 cpe、cve、vulnerabilityName 等抑制目标。官方 1.3 XSD

解析器读到 <filePath> 后，依赖选择条件已经结束，接着出现 <packageUrl> 就会报错。调换两者顺序也无法解决。

按 DOMPurify 的 PURL 抑制

如果接受对扫描范围内所有相同 PURL 的条目应用这三个漏洞抑制条件，可以使用：

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
    <suppress>
        <notes>Suppress the listed findings for DOMPurify 3.2.6.</notes>
        <packageUrl>pkg:javascript/DOMPurify@3.2.6</packageUrl>
        <vulnerabilityName>GHSA-h8r8-wccr-v5f2</vulnerabilityName>
        <vulnerabilityName>GHSA-cjmm-f4jc-qw8r</vulnerabilityName>
        <vulnerabilityName>GHSA-cj63-jhhr-wcxv</vulnerabilityName>
    </suppress>
</suppressions>

这里使用完整 PURL，无需开启正则匹配。规则能否命中，取决于报告中的实际 PURL 和漏洞名称是否与配置一致。packageUrl 匹配依赖的软件标识，具体值应从报告中核对。官方 suppression 文档

如果只想匹配两个 bundle

将上例中的 <packageUrl> 替换为 <filePath>，不要同时保留两者。如果实际路径使用 / 分隔，且以目标文件名结尾，可以写成：

<filePath regex="true">^.*/swagger-ui-(es-)?bundle\.js$</filePath>

这个表达式匹配以 swagger-ui-bundle.js 或 swagger-ui-es-bundle.js 结尾的路径，但不会限定外层必须是 swagger-ui-5.32.0.jar。如果还需要限定 WebJar 版本，应根据报告中的实际路径补充条件。

报告中显示的 swagger-ui-5.32.0.jar: swagger-ui-bundle.js 是依赖展示名称，不能直接认定为用于匹配的 filePath。官方文档说明，filePath 匹配依赖的操作系统绝对路径。先查看对应条目的实际路径，再调整表达式。官方路径匹配说明

也不要拆成两条规则来表达“路径和 PURL 同时满足”。两条独立的 <suppress> 会分别生效，无法形成跨规则的 AND 条件。

修改后如何确认？

核对构建配置加载的文件。描述中的 dependency-check-supressions.xml 与异常中的 dependency-check-suppressions.xml 拼写不同，应修改实际加载的文件。当前异常已经进入 XML 内容校验阶段，首先要解决规则结构问题。
重新运行扫描，确认 suppression 文件加载异常消失。
检查新报告，确认指定漏洞命中抑制规则，并确认其他依赖没有被意外覆盖。

XML 通过校验只能说明配置结构符合 schema，不能证明规则已经命中，也不能证明漏洞属于误报。现有材料不足以判断这三个 GHSA 在该项目中的实际可利用性；抑制规则不会修复 bundle 中的代码。