[
https://issues.apache.org/jira/browse/NIFI-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16593927#comment-16593927
]
Joseph Witt commented on NIFI-5541:
-----------------------------------
[~ABakerIII] I do agree with and empathize with the spirit of your message and
I definitely want you to be able to leverage nifi and think it is great you're
going to help contribute.
Now, having said this I personally work with a lot of end users of NiFi that
represent a very large number of customers. I agree there is an increasingly
(and there should be) heightened focus on identifying and swatting down
vulnerable components. But it is also common that conversations about specific
dependencies and their vulnerabilities is easily accomplished to explain why
altering the version is not the right cost/benefit at the time. That said,
there are also cases where we dont use something in a way that is vulnerable
but that doesn't mean a user couldn't change the config to expose a
vulnerability. For an example some log4j under certain usages has a vulnerable
tcp server. We don't configure/use that. But a user technically could.
As Pierre points out it is sadly rarely as easy as upgrading a POM and calling
it good. We simply do not have enough tests to cover the massive array of
different configurations one might use a given component under so it is a far
more plodding exercise to do this.
I'm not saying let's not do this - i'm saying - lets do this carefully.
For a really good example of where this is harder than one might think - if you
want to do something like upgrade Jetty (which has some high severity CVEs)
often times we do this it requires some coding change(s). They, like many
projects, do not follow semantic versioning or just might not realize what
downstream users treat as part of their API. We're fortunate that much of what
breaks we see quickly in that case but when it comes to changing versions of
Avro or Jackson parsing libs it can be much tougher.
Anyway, you're in the right place here. We're a community that truly cares and
wants to do the right thing. I'm just trying to sensitize you to the road
ahead in getting there (and obviously this is never over - new vulns found in
dependent libs all the time).
To Pierres point sometimes we will require an upstream dependency to fix their
dependency chain because us changing what we pull transitively can break that
which we pull directly.
> Please add OWASP Dependency Check to the build (pom.xml)
> --------------------------------------------------------
>
> Key: NIFI-5541
> URL: https://issues.apache.org/jira/browse/NIFI-5541
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Tools and Build
> Affects Versions: 2.0.0, 1.8.0
> Environment: All development, build, test, environments.
> Reporter: Albert Baker
> Assignee: Pierre Villard
> Priority: Major
> Labels: build, easy-fix, security
> 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 that get pulled into the released product via
> dependant/third-party 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 newly discovered &
> reported (known) vulnerailities. Project teams that keep up with removing
> known vulnerabilities on a weekly basis will help protect businesses that
> rely on these open source componets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
