[
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:14 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; all 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 and re-run the tests....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 uuse NIFI for my projectd, but in its current state, I cant
deploy it.
was (Author: abakeriii):
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.
> 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)
