[
https://issues.apache.org/jira/browse/CASSANDRA-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419235#comment-17419235
]
Stefan Miklosovic commented on CASSANDRA-14612:
-----------------------------------------------
Jenkins will be placing data via ant -Ddependency-check.home=/tmp/somedir
dependency-check, if -D parameter is not set, it will be put into build dir
under Cassandra repo. By this way we can cache it for agents and it survives
builds.
NVD categorises vulnerabilities based on their score (1). I have set it to "9"
in ant target so it means that the build will fail only in case there are
critical vulnerabilities.
For 3.0, there are these CRITICAL vulnerabilities:
jackson-mapper-asl-1.9.13.jar: CVE-2017-17485, CVE-2017-7525, CVE-2017-15095,
CVE-2018-14718, CVE-2018-7489, CVE-2019-17267, CVE-2019-16335, CVE-2019-14893,
CVE-2019-14540
libthrift-0.9.2.jar: CVE-2016-5397
logback-core-1.1.3.jar: CVE-2017-5929
netty-all-4.0.44.Final.jar: CVE-2019-20445, CVE-2019-20444
jackson vulnerability is discused here:
https://issues.apache.org/jira/browse/CASSANDRA-15701, we were not able to tell
if we are affected and this is updated in 3.11+
https://issues.apache.org/jira/browse/CASSANDRA-15867
I would investigate if it makes sense to update jackson to 2.x for Cassandra
3.0 to get rid of this otherwise I would supress this.
libthrift-0.9.2 - there is some vulnerability in go client library, I would say
supress it, not applicable: https://nvd.nist.gov/vuln/detail/CVE-2016-5397
logback-core-1.1.3 - I would supress this -
https://nvd.nist.gov/vuln/detail/CVE-2017-5929, there is acutally a JIRA for
this we have never acted upon:
https://issues.apache.org/jira/browse/CASSANDRA-15829 (I closed this) and this
one where it is updated for 4.0+ only:
https://issues.apache.org/jira/browse/CASSANDRA-14183 and
https://github.com/apache/cassandra/commit/4bbd28a043f15dd6c19de157acb5950319e8c16c
so in result I would skip this.
netty-all - imo we will fight this a lot, this is so lowlevel that mere version
bump might break other stuff. I do not think we have any bandwidth to deal with
this.
(1) https://nvd.nist.gov/vuln-metrics/cvss
I will post 3.11 and 4.0 + 4.11 report after some time.
> Please add OWASP Dependency Check to the build (pom.xml)
> --------------------------------------------------------
>
> Key: CASSANDRA-14612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14612
> Project: Cassandra
> Issue Type: New Feature
> Components: Build
> Environment: All development, build, test, environments.
> Reporter: Albert Baker
> Assignee: Stefan Miklosovic
> Priority: Normal
> Labels: build, easyfix, security
> Fix For: 3.11.x, 4.x
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an
> outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to
> perform a lookup for each dependant .jar to list any/all known
> vulnerabilities for each jar. This step is needed because a manual MITRE CVE
> lookup/check on the main component does not include checking for
> vulnerabilities in components or in dependant libraries.
> OWASP Dependency check :
> https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most
> Java build/make types (ant, maven, ivy, gradle).
> Also, add the appropriate command to the nightly build to generate a report
> of all known vulnerabilities in any/all third party libraries/dependencies
> that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false
> clean aggregate
> Generating this report nightly/weekly will help inform the project's
> development team if any dependant libraries have a reported known
> vulnerailities. Project teams that keep up with removing vulnerabilities on a
> weekly basis will help protect businesses that rely on these open source
> componets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
