forked from codice/ddf
-
Notifications
You must be signed in to change notification settings - Fork 0
/
dependency-check-maven-config.xml
206 lines (176 loc) · 8.88 KB
/
dependency-check-maven-config.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
<!--
SUPPRESSION GUIDANCE:
====================
1. This is a global suppression file, meaning it is used when scanning all modules in DDF.
We decided to use a single suppression file since managing files for each module was
impractical. However, this approach has a notable downside: there is no way to suppress
vulnerabilities for a single module.
This is problematic because we would like to ignore vulnerabilities for certain modules -
docs & itest modules in particular. The dependency-check plugin skips test-scoped
dependencies, but docs and itests have compile-time dependencies and so they get reported
by the plugin, even though they don't matter at runtime (all we care about).
What this means:
When you go to suppress a vulnerability because it only affects the itests or the docs,
be very sure that it isn't used at runtime.
Real-world example:
JRuby 9.2.6.0 (used by docs only) depends on Bouncy Castle (BC) 1.59, which has known
vulnerabilities. But BC is used at runtime by other dependencies, so this vulnerability
can't be suppressed.
NOTE: If the dependency-check plugin aggregate goal supported skipping children or
overriding the suppression file, we could work around this. It currently doesn't. See
https://github.com/jeremylong/DependencyCheck/issues/2152
2. Due to how dependency-check identifies libraries false positives may occur
(i.e. a CPE was identified that is incorrect). Suppressing these false positives is fairly
easy using the HTML report. In the report next to each CPE identified (and on CVE entries)
there is a suppress button. Clicking the suppression button will create a dialogue box which
you can simple hit Control-C to copy the XML that you would place into a suppression XML
file.
3. In general, prefer fixing a vulnerability over suppressing it, even if DDF isn't
affected. Pulling on dependencies with no vulnerabilities is better than relying on
assumptions that DDF isn't affected (which may be subject to change - unfortunately this
file isn't checked for accuracy often).
If you do choose to suppress, consider adding guidance on how to address the vulnerability
in the future if others choose to do so.
4. If the dependency-check plugin reports a particular dependency version is used, it's
often right, even if it isn't an installed bundle at runtime. The OWASP report includes a
section "Referenced In Projects/Scopes" for each vulnerable dependency. Before calling
something a false positive, run `mvn dependency:tree` on those affected projects and inspect
the output.
-->
<suppress>
<notes>
A CVE against slf4j for the class "EventData", which is not used in DDF or pax-logging.
</notes>
<packageUrl regex="true">^pkg:maven/org\.slf4j/slf4j\-ext@.*$</packageUrl>
<cve>CVE-2018-8088</cve>
</suppress>
<suppress>
<notes>
These CVEs come from the Codice country code converter library, though it's a little
unclear why.
CVE-2015-6420 affects Apache Synapse, which it doesn't use.
CVE-2017-15708 affects a number of Cisco products, which it doesn't use.
Moreover, these vulnerabilities are only exploitable when using a version of Apache
Commons Collections before 3.2.2, and neither it nor DDF do.
</notes>
<packageUrl regex="true">^pkg:maven/org\.codice\.countrycode/converter@.*$</packageUrl>
<cve>CVE-2015-6420</cve>
<cve>CVE-2017-15708</cve>
</suppress>
<suppress>
<notes>
This is a SUSE-specific security issue related to file permissions in the tomcat
packaging. The vulnerable dependency is embedded the pax-web-jsp bundle, so file
permissions are not an issue.
</notes>
<packageUrl regex="true">^pkg:maven/org\.apache\.tomcat\.embed/tomcat\-embed\-jasper@.*$</packageUrl>
<cve>CVE-2020-8022</cve>
</suppress>
<suppress>
<notes>
file name: groovy-2.4.4.jar
file name: groovy-xml-2.4.4.jar
file name: groovy-json-2.4.4.jar
DDF uses an old version of REST Assured which pulls in these vulnerable Groovy
dependencies. Suppressing since REST Assured and Groovy are only used for testing.
</notes>
<packageUrl regex="true">^pkg:maven/org\.codehaus\.groovy/groovy.*@2\.4\.4$</packageUrl>
<cve>CVE-2016-6814</cve>
</suppress>
<suppress>
<notes>
Ignore all vulnerabilities reported against DDF artifacts. These are false positives.
Note: CVEs with a score of exactly 10.0 will need to be suppressed separately.
</notes>
<gav regex="true">ddf.*:.*</gav>
<cvssBelow>10</cvssBelow>
<cve>CVE-2006-6460</cve>
</suppress>
<suppress>
<notes>
Ignore all vulnerabilities reported against DDF artifacts. These are false positives.
Note: CVEs with a score of exactly 10.0 will need to be suppressed separately.
</notes>
<gav regex="true">org\.codice\.ddf.*:.*</gav>
<cvssBelow>10</cvssBelow>
<cve>CVE-2006-6460</cve>
</suppress>
<suppress>
<notes>
javax.websocket/javax.websocket-api is not the same dependency as
java-websocket_project:java-websocket. We use the former, the CVE is for the latter.
</notes>
<packageUrl regex="true">^pkg:maven/javax\.websocket/javax\.websocket\-api@.*$</packageUrl>
<cpe>cpe:/a:java-websocket_project:java-websocket</cpe>
</suppress>
<suppress>
<notes>
The CVE is for hazelcast, but is being reported against hazelcast-client-protocol,
which is a different project.
</notes>
<packageUrl regex="true">^pkg:maven/com\.hazelcast/hazelcast\-client\-protocol@.*$</packageUrl>
<cve>CVE-2016-10750</cve>
</suppress>
<suppress>
<notes>
These CVEs are for Karaf but are being reported against Karaf Decanter
</notes>
<packageUrl regex="true">^pkg:maven/org\.apache\.karaf\.decanter.*/org\.apache\.karaf\.decanter.*@.*$</packageUrl>
<cve>CVE-2014-0219</cve>
<cve>CVE-2016-8750</cve>
<cve>CVE-2018-11786</cve>
<cve>CVE-2018-11787</cve>
<cve>CVE-2018-11788</cve>
<cve>CVE-2019-0191</cve>
<cve>CVE-2019-0226</cve>
<cve>CVE-2020-11980</cve>
</suppress>
<suppress>
<notes>
Zookeeper is the only thing still using Log4J, and it has suppressions for both the
following CVEs.
CVE-2019-17571 https://issues.apache.org/jira/browse/ZOOKEEPER-3677 (Zookeeper not affected)
CVE-2020-9488 https://issues.apache.org/jira/browse/ZOOKEEPER-3817 (DDF not affected,
doesn't configure Zookeeper with an SMTPAppender)
Once Zookeeper migrates to Log4J2, we can remove this suppression. See
https://issues.apache.org/jira/browse/ZOOKEEPER-2342
</notes>
<packageUrl regex="true">^pkg:maven/log4j/log4j@.*$</packageUrl>
<cve>CVE-2019-17571</cve>
<cve>CVE-2020-9488</cve>
</suppress>
<suppress>
<notes>
httpd vulnerabilities do not apply to CXF
</notes>
<packageUrl regex="true">^pkg:maven/org\.apache\.cxf/cxf\-rt\-transports\-http\-netty\-server@.*$</packageUrl>
<cpe>cpe:/a:apache:http_server</cpe>
</suppress>
<suppress>
<notes>
Karaf vulnerabilities do not apply to CXF (the "org.apache.cxf.karaf" group is used by
CXF artifacts providing Karaf-specific functionality)
</notes>
<packageUrl regex="true">^pkg:maven/org\.apache\.cxf\.karaf/.*</packageUrl>
<cpe>cpe:/a:apache:karaf</cpe>
</suppress>
<suppress>
<notes>
Karaf vulnerabilities do not apply to Camel (the "org.apache.camel.karaf" group is used
by Camel artifacts providing Karaf-specific functionality)
</notes>
<packageUrl regex="true">^pkg:maven/org\.apache\.camel\.karaf/.*</packageUrl>
<cpe>cpe:/a:apache:karaf</cpe>
</suppress>
<suppress>
<notes>
Maintainers of the OAuth2 SDK confirmed these are false positives:
https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/issues/320/owasp-dependency-check-reports-false
</notes>
<packageUrl regex="true">^pkg:maven/com\.nimbusds/oauth2\-oidc\-sdk@.*$</packageUrl>
<cve>CVE-2007-1651</cve>
<cve>CVE-2007-1652</cve>
</suppress>
</suppressions>