apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vlad Rozov <vro...@apache.org>
Subject Re: checking dependencies for known vulnerabilities
Date Sat, 09 Sep 2017 15:06:38 GMT
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,


[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 <pramod@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 <vrozov@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 <pramod@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.

View raw message