apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Priyanka Gugale <pri...@apache.org>
Subject Re: checking dependencies for known vulnerabilities
Date Mon, 11 Sep 2017 06:40:08 GMT
It's good idea to check for vulnerabilities, but as Pramod said all
softwares / libraries are going to have some or other vulnerability at any
time. I will go with approach of "let's discuss this addition" and we
should not affect PRs which are not adding any new dependencies (due to old

Also I also strongly feel, we need to be meticulous and think it through
before introducing such checks for reasons discussed before.


On Sat, Sep 9, 2017 at 8:36 PM, Vlad Rozov <vrozov@apache.org> wrote:

> 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 <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
>>>>>> failing. If details are suppressed and we have a summary warning
>>>>> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message