我正在使用Eclipse version2022-06(4.24.0)中的依赖项检查来生成依赖项报告。这是一个高超的项目。
我在pom.xml文件所在的目录中创建了一个suppression.xml文件。然后,我修改了pom.xml文件,使其包含suppression.xml文件(见下文)。
<configuration>
<format>XML</format>
<suppressionFiles>
<suppressionFile>suppression.xml</suppressionFile>
</suppressionFiles>
</configuration>
然后,通过单击CVE旁边的每个抑制按钮,我复制并粘贴了依赖项检查报告中的所有抑制片段。下面是一个示例:
<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency
suppression.1.3.xsd">
<suppress>
<notes><![CDATA[
file name: logback-classic-1.2.3.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/ch\.qos\.logback/logback\-classic@.*$</packageUrl>
<cpe>cpe:/a:qos:logback</cpe>
</suppress>
</suppressions>
通过这种方式,我能够抑制93个依赖项。然而,正如您在下面看到的。尽管我已经将每个依赖项都输入到我的抑制文件中,但并不是所有的依赖项都被抑制。仍发现11个漏洞和3个易受攻击的依赖项。我的目的是找到0个易受攻击的依赖项和0个漏洞。
有谁知道为什么这三个特定的依赖项仍然保留在依赖项检查报告上,尽管它们的抑制片段出现在我的项目的suppression.xml文件中?我试着在网上搜索答案,但没有找到任何有效的解决方案。这是我最后的手段。
谢谢!
1条答案
按热度按时间mpbci0fu1#
也许漏洞与
<cpe>cpe:/a:qos:logback</cpe>
不匹配?尝试压制单个CVE。但是,正如@khmarbaise建议的那样,试着摆脱它们。更新依赖项或替换它们。他们有潜在的风险!
我是这样做的:
这为我提供了一个优势,即漏洞只被抑制到特定的日期,然后再次检查。所以我不会忘记每隔一段时间检查一下。
我还有一张小纸条,说明为什么我抑制了一个漏洞。有时你只是不受影响,你可以永远压抑它,有时你不知道该做什么。至少你不会忘记你为什么要压制它。
OWASP依赖关系-检查手册:Suppressing False Positives