CVE are classified by severity levels or CVSS scores [1]. Any CVE that
has a score above 9.0 is considered to be critical. I am OK with "let's
discuss this addition" and consider probability of a CVE in a dependency
leading to a security exploit in Apex when the severity of the CVE is
not critical. For critical and possibly high severity level CVE, the
approach should be reversed - reject the additional dependency
automatically and discuss if it is OK to accept the dependency with the
critical severity level. We may discuss what is a cut off level and my
recommendation is to use middle point of the high severity (8.0).

Without penalizing PRs that have nothing to do with a CI build failures
whether it is caused by a dependency check, change in a CI environment
or any other reason like unit test failure you promote the current
community no appetite for addressing non functional issues in Apex
(actually another example where the appetite is driven not by the
community but by the vendor). IMO, PRs must be automatically rejected
when build fails in CI (whether in Travis or Jenkins) and the burden
must be on the community to troubleshoot and resolve issues in the build
or unit test (including intermittent failures in the unit test). An
attitude of the majority of the current Apex community not to care for
CI builds (and other non functional issues like package names) unless an
issue is introduced directly in their PR at minimum should not be

I don't know if other Apache projects automatically reject dependencies
based on CVE. Every Apache community is independent and establishes it's
own process. What I know is that it would be better for Apex to avoid
mentions like [2].

Thank you,



On 9/8/17 16:42, Sanjay Pujare wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB