[
https://issues.apache.org/jira/browse/NIFI-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16593617#comment-16593617
]
Albert Baker edited comment on NIFI-5541 at 8/27/18 1:05 PM:
-------------------------------------------------------------
Joesph - True that the inclusion of a libraries that contain 78 high risk
vulnerabilities does not proove that any of them are reachable. However in my
case this distintion does not matter. I support medical and financial
institutions that have been hammered by cyber attacks for 20 yrs, have been
stolen from, records lost; sll of which drives up the cost of insurance to make
thier customers whole again. These companies and one service provider will not
allow any new componetent to be installed in thier infrastructure that has even
one high severity CVE. That trend is increasing. They are defaulting to "dont'
trust". Its not a hard effort to simply update the pom.xml with newer
versions of the libraies....is it ? I can author 78 more Jira tickets, one for
every high severity rating. Which is the better course fo action, fix the
stuff that we know is wrong, or hope that everything will be fine ? Id like to
youse NIFI for my project, but in its current state, I cant.
was (Author: abakeriii):
Joesph - True that the inclusion of a libray that contains 78 high risk
vulnerabilities does not proove that any of them are reachable. However in my
case this distintion does not matter. I support medical and finacial
institutions that have been hammered by cyber attacks for 20 yrs, have been
stolen from, records lost, drives the cost of insurance to make thier customers
whole again. These comapanies and one service provider will not allow any
componetent to be installed in thier infrastructure that has even one high
severity CVE. That trend is increasing. They are defaulting to "dont' trust".
Its not a hard effort to simply update the pom.xml with newer versions of the
libraies....is it ? I can author 78 more Jira tickets, obe for every high
severity rating. Whic is the better course fo action, fix the stuff that we
know is wrong, or hope that everything will be fine ?
> 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)
