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
encouraged.
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,
Vlad
[1] https://nvd.nist.gov/vuln-metrics/cvss
[2] http://thehackernews.com/2017/09/apache-struts-vulnerability.html
On 9/8/17 16:42, Sanjay Pujare wrote:
I am with Pramod on this one.
Are there examples (Apache projects) where PRs are automatically rejected
based on builds flagging CVEs?
On Fri, Sep 8, 2017 at 4:21 PM, Pramod Immaneni <pra...@datatorrent.com>
wrote:
There are a couple of things here. You may be hard pressed to find software
with no CVE vulnerabilities as security issues are found all the time so we
should go with a guideline that is in the spirit of "let's discuss this
addition and weigh the pros and cons" rather than "don't add whatsoever if
you find a vulnerability". Almost every software out there has
vulnerabilities including your OS, hadoop and the various other
dependencies.
I am fine with the build failing for a PR that has a newly added dependency
which has CVEs as long as we don't penalize PRs that have nothing to do
with a dependency change, i.e., don't fail builds for PRs because a new CVE
was discovered in existing dependencies. Also, if there is a PR with a new
dependency that has CVEs, let it not be an automatic disqualifier but
should be discussed on the dev list.
Thanks
On Fri, Sep 8, 2017 at 3:51 PM, Vlad Rozov <vro...@apache.org> wrote:
+1 that PR with newly introduced vulnerability should not be merged.
Actually, my preference will be that such PR should not be even open.
Thank you,
Vlad
On 9/8/17 15:44, Thomas Weise wrote:
On Fri, Sep 8, 2017 at 3:36 PM, Pramod Immaneni <pra...@datatorrent.com
wrote:
Though I like the functionality of being able to detect if a new
dependency
being added has vulnerabilities and prompting the search for a better
version, I am wary of tying a build strongly to vulnerability detection
i.e., the build failing when vulnerabilities are discovered in
dependencies. This immediately blocks our project till those
vulnerabilities are addressed as nothing can go in because builds are
failing. If details are suppressed and we have a summary warning but
not
fail the build, that should be ok.
I think that if a new problem is introduced, then it should be
discovered
in the CI and the PR that causes it not be merged until it is addressed.
